On Tue, Feb 21, 2006 at 05:06:48PM -0800, Linus Torvalds wrote:
>
> To some degree, /initrd was supposed to do things like that, and in
> theory, it still could. However, realistically, 99% of any /initrd is more
> about the distribution than the kernel, so right now we have to count
> /initrd as a distribution thing, not a kernel thing.
... and if we're truly going to be pouring more and more complexity
into initrd (such as userspace swsusp), then (a) we probably should
make it more of a kernel-specific thing, and not a distro-specific
thing, since without that you can be pretty much guaranteed that more
and more people will be using and testing swsusp2, and not uswsusp,
and (b) we need to add _way_ better debugging provisions so that if
something dies in early boot, you don't go pulling out your hair
trying to figure out what went wrong, and having to spend a good 20
minutes or so between each try-to-fix the initrd, watch the boot fail,
reboot into a working setup, cursing Red Hat's nash, modifying the
initrd, and trying again.
Usually I break the loop by giving up, and ripping out whatever kernel
feature requires initrd, such as dm, and installing on hard partitions
with all of the kernel modules I need compiled into the kernel. I
still have no idea why mptscsi fails to detect SCSI disks when loaded
as a module via initrd on various bits of IBM hardware (including the
e326 and ls-20 blade), but works fine when compiled directly into the
kernel....
If we want more and more stuff to be poured into initrd, it's got to
be made easier to debug and consistent across distributions, such that
more people can test initrd configurations, and flush out the bugs,
never mind the question of programs like udev randomly breaking
between kernel releases. Maybe it's time to consider moving all of
that into the kernel source; if they wanted to be treated as part of
the kernel, then let them liteally become part of the kernel from a
source code and release management perspective.
- Ted
-
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]
