Re: firmware separation filesystem (fwfs)

Manuel Estrada Sainz (ranty@debian.org)
Sat, 19 Apr 2003 22:41:38 +0200


On Thu, Apr 17, 2003 at 02:12:03PM +0100, Alan Cox wrote:
> On Iau, 2003-04-17 at 02:23, David Gibson wrote:
> > > But so would loading it from hotplug via ioctl. It might be we want
> > > a clean hotplug way to ask for 'firmare for xyz'.
> >
> > True, but ioctl()s are horrid. And the driver needs to set up a
> > suitable device to which the ioctl() is applied, and deal with binding
> > the right image to the right instance, which can get messy in some
>
> You are ignoring the main issue of discussion. I don't care if its
> ioctl, tcp/ip over carrier pigeon or a pipe.
>
> fwfs is a broken idea because it leaves the data in kernel space. On
> a giant IBM monster maybe nobody cares about a few hundred K of cached
> firmware in the kernel, but the rest of us happen to run real world
> computers.

Many drivers currently include this same data in kernel space, in in
headers, what I am trying to do is make it easy for them to support
fwfs (or whatever it becomes in the end). This way, they may be able to
support it with little effort (which increases the chances of them
actualy supporting it) and people worried about memory usage can easly
free up that memory with a simple unlink.

> Catting the firmware to a device node also works fine for me as an
> API, but keep the firmware in userspace.

When sysfs binary support is integrated I'll try to do something on top
of it, and in any case, I'll at the minimum make sure that in-kernel
data is optional.

Have a nice day

Manuel

-- 
--- Manuel Estrada Sainz <ranty@debian.org>
                         <ranty@bigfoot.com>
			 <ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/