Hello!
I'm writing a Linux device driver for a device that requires non-free
firmware in order to function. The firmware can be easily extracted from
the Windows driver for that device. The device is a PCMCIA wireless card.
The firmware is about 60k in size, and it mostly consists of executable
code for ARM processor. Reimplementing it is out of question for me.
What would be the best approach to handle this situation:
1) Register a file on procfs and use "cat" to load the firmware into the
kernel.
2) Register a device for the same purpose.
3) Register a device, but use ioctl().
4) Open a network socket and use ioctl() on it (like ifconfig does).
5) Use one of the the above ways to send the filename to the module and
let the module load the firmware from file using do_generic_file_read().
6) Provide a script to wrap firmware into a module and load it using
modprobe.
7) Encode the firmware into a header file, add it to the driver and
pretend that the copyright issue doesn't exist (like it's done in the
Keyspan USB driver).
Better ideas?
--
Regards,
Pavel Roskin
On Tue, Mar 25, 2003 at 08:32:50PM -0500, Pavel Roskin wrote:
>
> 1) Register a file on procfs and use "cat" to load the firmware into the
> kernel.
That would work.
> 2) Register a device for the same purpose.
>
> 3) Register a device, but use ioctl().
>
> 4) Open a network socket and use ioctl() on it (like ifconfig does).
That's a nice way, as you don't need to register a device.
> 5) Use one of the the above ways to send the filename to the module and
> let the module load the firmware from file using do_generic_file_read().
Ick, I wouldn't recommend having the kernel do this, it's nicer to have
userspace do the firmware send.
> 6) Provide a script to wrap firmware into a module and load it using
> modprobe.
I don't think that this would be accepted into the main kernel tree, and
vendors might have a problem with it.
> 7) Encode the firmware into a header file, add it to the driver and
> pretend that the copyright issue doesn't exist (like it's done in the
> Keyspan USB driver).
Hey, that's the way I like doing this stuff :)
Almost any of the above would probably work well, and I think all except
#5 and #6 are currently done in the main kernel tree.
Good luck,
greg k-h
On Tue, Mar 25, 2003 at 08:11:46PM -0800, Greg KH wrote:
> > 7) Encode the firmware into a header file, add it to the driver and
> > pretend that the copyright issue doesn't exist (like it's done in the
> > Keyspan USB driver).
>
> Hey, that's the way I like doing this stuff :)
If you do this the Debian kernel mainainers will mercilessly rip your
non-free driver firmware from the standard Debian kernel. At least
that is what happened with the Keyspan :-(
--
Nick Craig-Wood
[email protected]
Pavel Roskin ([email protected]) wrote:
> 7) Encode the firmware into a header file, add it to the driver and
> pretend that the copyright issue doesn't exist (like it's done in the
> Keyspan USB driver).
It doesn't exist. At lost, not on the part of Linux. The license of the
firmware may prohibit it.
The way I interpret the GPL you may link _any_ _data_ into a GPL'ed
program. Since this firmware is _data_ from the point of view of the kernel
(eg. the stream of execution never enters the firmware and it isn't mapped
to a text segment) there shouldn't be any problem.
It may still be preferable to choose another option, but linking the
firmware into a module has the advantage of the user being able to do
module autoloading without further configuration (eg. post-install lines in
modules.conf).
--
Erik Hensema <[email protected]>
Am Mittwoch, 26. M?rz 2003 11:48 schrieb Nick Craig-Wood:
> On Tue, Mar 25, 2003 at 08:11:46PM -0800, Greg KH wrote:
> > > 7) Encode the firmware into a header file, add it to the driver and
> > > pretend that the copyright issue doesn't exist (like it's done in the
> > > Keyspan USB driver).
> >
> > Hey, that's the way I like doing this stuff :)
>
> If you do this the Debian kernel mainainers will mercilessly rip your
> non-free driver firmware from the standard Debian kernel. At least
> that is what happened with the Keyspan :-(
That's their problem then. Or rather their users.
IMHO a maintainer's responsibility ends at kernel.org.
>From a technical point of view the firmware needs to be
in ram when you resume from sleep. If you don't care about
updating it, having it in the kernel image uses somewhat less
resources. So I'd say go for it.
Regards
Oliver
Check the list archive, there was someone telling about support they
added for binary blobs in /proc (or was it sysfs?) for this (among
others) very purpose.
Please don't make the situation any worse. I'd like to have some hope
that Debian my publish their kernel-source package with a
linux-x.x.x.tar.bz2 that matches the md5sum of the one on kernel.org
some day.
Regards,
Jeremy
On Wed, 2003-03-26 at 07:47, Oliver Neukum wrote:
> Am Mittwoch, 26. März 2003 11:48 schrieb Nick Craig-Wood:
> > On Tue, Mar 25, 2003 at 08:11:46PM -0800, Greg KH wrote:
> > > > 7) Encode the firmware into a header file, add it to the driver and
> > > > pretend that the copyright issue doesn't exist (like it's done in the
> > > > Keyspan USB driver).
> > >
> > > Hey, that's the way I like doing this stuff :)
> >
> > If you do this the Debian kernel mainainers will mercilessly rip your
> > non-free driver firmware from the standard Debian kernel. At least
> > that is what happened with the Keyspan :-(
>
> That's their problem then. Or rather their users.
> IMHO a maintainer's responsibility ends at kernel.org.
> >From a technical point of view the firmware needs to be
> in ram when you resume from sleep. If you don't care about
> updating it, having it in the kernel image uses somewhat less
> resources. So I'd say go for it.
>
> Regards
> Oliver
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Am Mittwoch, 26. März 2003 14:52 schrieb Jeremy Jackson:
> Check the list archive, there was someone telling about support they
> added for binary blobs in /proc (or was it sysfs?) for this (among
> others) very purpose.
>
> Please don't make the situation any worse. I'd like to have some hope
> that Debian my publish their kernel-source package with a
> linux-x.x.x.tar.bz2 that matches the md5sum of the one on kernel.org
> some day.
I am sure such a patch, if the Debian people would get it into the
mainline kernel, would find its use.
But failing that I see no reason why any coder should jump through
hoops for the nontechnical concerns of any distribution, including Debian.
Using procfs for this is messier than including it in a header file.
Regards
Oliver
At 05:32 PM 3/25/2003, Pavel Roskin wrote:
>Hello!
>
>I'm writing a Linux device driver for a device that requires non-free
>firmware in order to function. The firmware can be easily extracted from
>the Windows driver for that device. The device is a PCMCIA wireless card.
>
>The firmware is about 60k in size, and it mostly consists of executable
>code for ARM processor. Reimplementing it is out of question for me.
>
>What would be the best approach to handle this situation:
>
>1) Register a file on procfs and use "cat" to load the firmware into the
>kernel.
>
>2) Register a device for the same purpose.
>
>3) Register a device, but use ioctl().
>
>4) Open a network socket and use ioctl() on it (like ifconfig does).
>
>5) Use one of the the above ways to send the filename to the module and
>let the module load the firmware from file using do_generic_file_read().
>
>6) Provide a script to wrap firmware into a module and load it using
>modprobe.
>
>7) Encode the firmware into a header file, add it to the driver and
>pretend that the copyright issue doesn't exist (like it's done in the
>Keyspan USB driver).
>
>Better ideas?
8) Have the driver call external user-space firmware loader that uses
either iopl/outb/inb or mmap(/dev/mem) and loads firmware directly.
Max