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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]