lkml.org 
[lkml]   [2002]   [Jan]   [15]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    FromDavid Garfield <>
    DateTue, 15 Jan 2002 19:33:17 -0500
    SubjectRe: Query about initramfs and modules
    Greg KH writes:
     > But how do you always know what is "needed"?  Wouldn't it be nice to
     > just select "compile all SCSI PCI and IEEE1394 and USB drivers as
     > modules" and then have your "real" root partition's controller be
     > automatically found before you try to mount your "real" root partition?
    
    One knows what is needed because one knows or determines what it takes
    to access ones real root partition.
    
     > Say your SCSI PCI controller dies, and you buy a new one.  Plop it in,
     > reboot, and everything works.  No having to build a new initrd, or build
     > in _all possible_ SCSI PCI drivers.
    
    Except that what you have just proposed requires that you "build in
    _all possible_ SCSI PCI drivers" as modules in the initramfs.  Little
    gain, except that some things won't be retained.
    
    Further, I don't thing I would expect a system with a changed SCSI PCI
    controller to boot on a kernel specifically built for the previous
    controller.  I don't think I would even want it to boot.  Better I
    think to get out a rescue disk of some sort, boot from that,
    reconfigure a built kernel for the new hardware (in the new case,
    simply reconstructing the initramfs), and reboot from that.
    
    
    
     > Right now you can't have your "real" root partition on a USB drive,
     > without a horrible "let's wait forever" patch to your kernel.
     > 
     > This also solves the "coldplug" problem, where you need to load
     > pci/usb/foobus drivers _after_ init has started.  To do this you need to
     > rely on scanning the busses from userspace and loading the needed
     > drivers.  Why reimplement this scanning logic, as the kernel already did
     > all of this (and usually did a much better job at it) during the boot
     > process before init started.
     > 
     > And this allows lots of horrible "boot over NFS" and other network
     > code/hacks in the kernel to be moved out of kernel space, and into
     > userspace, where it really belongs.
    
    Well, I agree that the new solution does solve some problems.
    
    
    What I am worried about is not *allowing* user mode code in the
    initramfs, but *requiring* it.
    
    
    --David Garfield
    -
    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/
    
    
    \
     
     \ /
      Last update: 2005-03-22 12:23    [from the cache]
    ©2003-2008