Re: ipw2200 [was Re: RFC: Starting a stable kernel series off the 2.6 kernel]

On Saturday 10 December 2005 02:35, Pavel Machek wrote:
> On Wed 07-12-05 12:14:25, Rob Landley wrote:
> > On Tuesday 06 December 2005 12:51, Bill Davidsen wrote:
> > > Just so we're all on the same page, I think there are two sets of
> > > unhappy people here... one is the group who want new stuff fast and
> > > stable. For the most part that's not me, although I was in the "if
> > > you're going to add ipw2200 support, why not something that works?"
> > > group. But new stuff is going in faster than most people can assimilate
> > > it if they have a real job, so I don't see too much problem there.
> >
> > My laptop has an ipw2200 but I can't get it to work in any kernel I built
> > because the kernels I build aren't modular. I hope to be able to work
> > around this someday with a clever enough initramfs (if necessary, moving
> > the initramfs initialization earlier in the boot sequence), but it hasn't
> > made it far enough up my todo list yet.
>
> Well, building modular kernel for a test is not *that* much work.
> Anyway, if you are going to fix it, fix it properly (by
> delayed firmware loading) -- initrd hacks are good for you
> but unusable for anyone else.

I don't see why that's any less usable than using udev from initramfs to find
your root partition.

There is an interesting licensing issue, creating a linux kernel image that
contains an initramfs that contains binary only firmware. I can happily
generate one here and not care, but does distributing such a kernel violate
the GPL?

It's probable that the "early userspace" mechanism is a clearly defined API.
We documented the heck out of the format, it cpio was already a standard
anyway. The binaries that are in there call the normal userspace API
(syscall/ioctl/procfs etc) that is an established strong barrier to being a
derived work. So it's possible that putting those binaries in initramfs
counts as "mere aggregation". (If you had the kernel and the firmware in an
ISO image, that's the same as being different files on the same CD, and
definitely mere aggregation. As separate files in the same tarball, it's
closer but functionally equivalent and probably still just aggregation.
Probably. Different elf sections in the same binary is one more step, but
depending on the intent the analogy could still hold...)

I can see distributors shying the heck away from it anyway, and wanting to
keep things in _seperate_files_. And I can entirely understand that. This
means if initramfs is going to contain firmware, the option of having it be a
separate file like initrd for legal reasons is a darn good idea.

Query: if you tell lilo or grub that it has an initrd but feed it a gzipped
cpio image, will the kernel figure everything out and initialize initramfs
from that appropriately?

> Pavel

Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
    ... at least not in the current kernel. ... normal userspace is good enough for me. ... The real question seems to be if we want to keep the firmware inside the ... reason enough to create an initramfs. ...
    (Linux-Kernel)
  • Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
    ... as was mentioned earlier in this thread the ipw2200 needs the firmware at initialization, but some others don't need it until open. ... normal userspace is good enough for me. ... reason enough to create an initramfs. ... my understanding is that the kernel fully initializes all built-in drivers, then loads userspace and starts running it. ...
    (Linux-Kernel)
  • Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
    ... reason enough to create an initramfs. ... initialize it earlier, which made firmware loading possible. ... is not much choice than putting the firmware in the driver or in the kernel ...
    (Linux-Kernel)
  • Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
    ... Your approach is just fine if the things that will need firmware are compiled as modules but some people prefer to build monolithic kernel images, and in those cases there is no way for the kernel to get the firmware as there is no filesystem available yet. ... There is already support in the kconfig for specifying the initramfs source, why culdn't we have the build process fetch any firmware needed by the non-modular portions and store them at the end of the kernel image so that they can be found during boot. ... request_firmware in order to pull in binary firmware blobs from userland ...
    (Linux-Kernel)
  • Re: klibc and whats the next step?
    ... Well, we already have an initramfs, and it can do quite some stuff the ... current kernel doesn't do. ... Latest suse doesn't use klibc any more. ... After adding the "fsck rootfs" feature we had glibc ...
    (Linux-Kernel)