Hearing all this talk about initramfs and eliminating hardwired
drivers, it occurs to me to ask:
Can/will the initramfs mechanism be made to implicitly load into the
kernel the modules (or some of the modules) in the image?
Doing so would allow the initramfs image to be composed solely of the
modules to be loaded, which would reduce the need for the "klibc". It
would also eliminate the need for any sort of control script to be in
the image.
The only difficulty that I perceive in doing this is that the modules
in question might need to be appropriately resolved and relocated
before being put into the file image. I think this is a solvable
problem, given that the kernel and its System.map should be available
when building the image.
--David Garfield
On Tue, Jan 15, 2002 at 06:15:02PM -0500, David Garfield wrote:
>
> Can/will the initramfs mechanism be made to implicitly load into the
> kernel the modules (or some of the modules) in the image?
Most of the mechanism for loading modules for physical devices will be
the /sbin/hotplug interface:
- when the pci core code scans the pci bus, and finds a new
device, it calls out to /sbin/hotplug the pci device
information.
- /sbin/hotplug looks up the pci device info and tries to match
it up with a driver that will work for this device (see the
linux-hotplug.sf.net site for more info on how this works.)
- if it finds a module for the device, it calls modprobe on the
module, and now that pci device has a module loaded.
Repeat this process for the USB, IEEE1394, and other busses that support
MODULE_DEVICE_TABLE in the kernel tree.
> Doing so would allow the initramfs image to be composed solely of the
> modules to be loaded, which would reduce the need for the "klibc". It
> would also eliminate the need for any sort of control script to be in
> the image.
klibc (or some libc) is needed to build /sbin/hotplug, and modprobe in
this scenario.
greg k-h
Greg KH writes:
> On Tue, Jan 15, 2002 at 06:15:02PM -0500, David Garfield wrote:
> >
> > Can/will the initramfs mechanism be made to implicitly load into the
> > kernel the modules (or some of the modules) in the image?
>
> Most of the mechanism for loading modules for physical devices will be
> the /sbin/hotplug interface:
> - when the pci core code scans the pci bus, and finds a new
> device, it calls out to /sbin/hotplug the pci device
> information.
> - /sbin/hotplug looks up the pci device info and tries to match
> it up with a driver that will work for this device (see the
> linux-hotplug.sf.net site for more info on how this works.)
> - if it finds a module for the device, it calls modprobe on the
> module, and now that pci device has a module loaded.
>
> Repeat this process for the USB, IEEE1394, and other busses that support
> MODULE_DEVICE_TABLE in the kernel tree.
Seems like a great idea *after* the system is fully running (or the
root partition is at least mounted).
Seems like overkill to boot most systems.
As I understand it, all that should need to go into the initramfs is
enough to mount the root partition. Normally, this would probably be
a handful of drivers that are unconditionally known to be needed. So
why go through several user-mode programs to make a decision that can
be made once and built in?
--David Garfield
On Tue, Jan 15, 2002 at 06:47:44PM -0500, David Garfield wrote:
> Greg KH writes:
> > On Tue, Jan 15, 2002 at 06:15:02PM -0500, David Garfield wrote:
> > >
> > > Can/will the initramfs mechanism be made to implicitly load into the
> > > kernel the modules (or some of the modules) in the image?
> >
> > Most of the mechanism for loading modules for physical devices will be
> > the /sbin/hotplug interface:
> > - when the pci core code scans the pci bus, and finds a new
> > device, it calls out to /sbin/hotplug the pci device
> > information.
> > - /sbin/hotplug looks up the pci device info and tries to match
> > it up with a driver that will work for this device (see the
> > linux-hotplug.sf.net site for more info on how this works.)
> > - if it finds a module for the device, it calls modprobe on the
> > module, and now that pci device has a module loaded.
> >
> > Repeat this process for the USB, IEEE1394, and other busses that support
> > MODULE_DEVICE_TABLE in the kernel tree.
>
> Seems like a great idea *after* the system is fully running (or the
> root partition is at least mounted).
The initramfs is the initial root partition.
> Seems like overkill to boot most systems.
>
> As I understand it, all that should need to go into the initramfs is
> enough to mount the root partition. Normally, this would probably be
> a handful of drivers that are unconditionally known to be needed. So
> why go through several user-mode programs to make a decision that can
> be made once and built in?
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?
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.
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.
thanks,
greg k-h
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
On Tue, Jan 15, 2002 at 07:33:17PM -0500, David Garfield wrote:
>
> 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.
Little gain? You don't waste kernel space for SCSI drivers that are not
being used.
> 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.
Each to their own.
> What I am worried about is not *allowing* user mode code in the
> initramfs, but *requiring* it.
Why? What are you afraid of? :)
If you want the boot process to be just like it is today, and you don't
require any network boot stuff, I think no userspace code will be
needed. But I can't guess the future...
greg k-h
Followup to: <[email protected]>
By author: David Garfield <[email protected]>
In newsgroup: linux.dev.kernel
>
> Hearing all this talk about initramfs and eliminating hardwired
> drivers, it occurs to me to ask:
>
> Can/will the initramfs mechanism be made to implicitly load into the
> kernel the modules (or some of the modules) in the image?
>
No. The bulk of the work of module loading is the job for insmod.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Tue, 15 Jan 2002, David Garfield wrote:
> Hearing all this talk about initramfs and eliminating hardwired
> drivers, it occurs to me to ask:
>
>
>
> Can/will the initramfs mechanism be made to implicitly load into the
> kernel the modules (or some of the modules) in the image?
No. The point of initramfs is to remove crap from kernel and switch
to using normal code paths for late-boot stuff. _Adding_ insmod
analog into the kernel? No, thanks.
H. Peter Anvin writes:
> Followup to: <[email protected]>
> By author: David Garfield <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Hearing all this talk about initramfs and eliminating hardwired
> > drivers, it occurs to me to ask:
> >
> > Can/will the initramfs mechanism be made to implicitly load into the
> > kernel the modules (or some of the modules) in the image?
> >
>
> No. The bulk of the work of module loading is the job for insmod.
Agreed. However, this work could easily be performed by an insmod
variant that takes a module, a "System.map", and a kernel image, and
produces a cpio file as output instead of passing the data to the
kernel for immediate processing. The kernel mechanism would then only
need to unpack the pieces, relocate, and make the system calls.
Followup to: <[email protected]>
By author: David Garfield <[email protected]>
In newsgroup: linux.dev.kernel
>
> Agreed. However, this work could easily be performed by an insmod
> variant that takes a module, a "System.map", and a kernel image, and
> produces a cpio file as output instead of passing the data to the
> kernel for immediate processing. The kernel mechanism would then only
> need to unpack the pieces, relocate, and make the system calls.
>
How do you know where the running kernel will be allocating address
space for the module?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
H. Peter Anvin writes:
> Followup to: <[email protected]>
> By author: David Garfield <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Agreed. However, this work could easily be performed by an insmod
> > variant that takes a module, a "System.map", and a kernel image, and
> > produces a cpio file as output instead of passing the data to the
> > kernel for immediate processing. The kernel mechanism would then only
> > need to unpack the pieces, relocate, and make the system calls.
> >
>
> How do you know where the running kernel will be allocating address
> space for the module?
I did say "relocate". OK, so maybe the correct order is: partial
unpack, first system call, remaining unpack, relocate, second system
call.
Actually, the hard part is intermodule dependencies. For that, the
issue becomes where the running kernel allocated address space for the
previous modules. I suppose the insmod variant could process a stream
of modules for loading, but then relocation starts including
double-relocation for a pair of modules... OK, maybe it is too
complex for the kernel.
--David Garfield
On Tue, Jan 15, 2002 at 04:01:17PM -0800, Greg KH wrote:
>
> 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.
Hmm. AFAICS this also implies that one would have to put /all/ drivers
for /any/ hardware possibly plugged in at boot time on the initramfs.
Or will /sbin/hotplug provide the ability to just put requests it
can't resolve with the modules on the initramfs into some sort of
queue file, which is read by /sbin/coldplug (or whatever) later on in
the boot process to load drivers for those from the real root fs?
> 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.
Having to put all drivers for all PCI/USB/whatever stuff on the
initramfs will likely be a problem (regarding disk space) for people
who need to boot the kernel from a floppy disk without having to
change disks during boot (think of nfsroot without etherboot).
Andreas
--
Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
---------------------------------------------------------
+49 521 1365800 - [email protected] - http://www.devcon.net
On Tue Jan 15, 2002 at 10:29:12PM -0500, Alexander Viro wrote:
> > Can/will the initramfs mechanism be made to implicitly load into the
> > kernel the modules (or some of the modules) in the image?
>
> No. The point of initramfs is to remove crap from kernel and switch
> to using normal code paths for late-boot stuff. _Adding_ insmod
> analog into the kernel? No, thanks.
Keep in mind that insmod current needs to incorporate a full ELF
interpreter in userspace (and the source code needs to know about
all the types of relocations and jump for each arch and for 32
and 64 bit ELF. Horrible stuff really. If we could cleanup the
kernel's insmod implementation to require merely a syscall
passing a filename to the kernel, it would sure make the
initramfs smaller and simpler. I believe Rusty made a patch to
do this sort of thing....
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Wed, Jan 16, 2002 at 08:29:58PM +0100, Andreas Ferber wrote:
>
> Hmm. AFAICS this also implies that one would have to put /all/ drivers
> for /any/ hardware possibly plugged in at boot time on the initramfs.
> Or will /sbin/hotplug provide the ability to just put requests it
> can't resolve with the modules on the initramfs into some sort of
> queue file, which is read by /sbin/coldplug (or whatever) later on in
> the boot process to load drivers for those from the real root fs?
No, I hadn't thought of doing this. If someone wants to knock out a
patch, I'd be glad to take a look at it.
> > 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.
>
> Having to put all drivers for all PCI/USB/whatever stuff on the
> initramfs will likely be a problem (regarding disk space) for people
> who need to boot the kernel from a floppy disk without having to
> change disks during boot (think of nfsroot without etherboot).
I agree. It's a lot of drivers (and it's growing.) It will help out
people booting from a hard disk the most (which happen to be the
majority of people :)
thanks,
greg k-h
> I agree. It's a lot of drivers (and it's growing.) It will help out
> people booting from a hard disk the most (which happen to be the
> majority of people :)
And yet, I see the greatest potential for initramfs coming from devices that
*don't* boot from a hard drive. I know tons of embedded devices that have
very evil looking init scripts just to boot something other than a hard
drive. Man, if the initramfs could handle all those cases uniformly, it
would be a huge advantage for the embedded world.
Jordan
Followup to: <[email protected]>
By author: Erik Andersen <[email protected]>
In newsgroup: linux.dev.kernel
>
> Keep in mind that insmod current needs to incorporate a full ELF
> interpreter in userspace (and the source code needs to know about
> all the types of relocations and jump for each arch and for 32
> and 64 bit ELF. Horrible stuff really. If we could cleanup the
> kernel's insmod implementation to require merely a syscall
> passing a filename to the kernel, it would sure make the
> initramfs smaller and simpler. I believe Rusty made a patch to
> do this sort of thing....
>
Yeah! Let's put all this crap in KERNEL SPACE! *NOT!*
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
On Wed Jan 16, 2002 at 11:56:59AM -0800, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Erik Andersen <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > Keep in mind that insmod current needs to incorporate a full ELF
> > interpreter in userspace (and the source code needs to know about
> > all the types of relocations and jump for each arch and for 32
> > and 64 bit ELF. Horrible stuff really. If we could cleanup the
> > kernel's insmod implementation to require merely a syscall
> > passing a filename to the kernel, it would sure make the
> > initramfs smaller and simpler. I believe Rusty made a patch to
> > do this sort of thing....
> >
>
> Yeah! Let's put all this crap in KERNEL SPACE! *NOT!*
Good point. We surely wouldn't want to have an ELF interpreter
in kernel space. That would be evil!
rm linux/fs/binfmt_elf.c
There, thats better, now userspace can load everything. If we
can figure out how to get userspace loaded....
The kernel already knows how to load ELF files, and _has_ to do
that job to get userspace running anyways. So why not use that
mechanism for modules?
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Erik Andersen wrote:
>>>
>>Yeah! Let's put all this crap in KERNEL SPACE! *NOT!*
>>
>
> Good point. We surely wouldn't want to have an ELF interpreter
> in kernel space. That would be evil!
> rm linux/fs/binfmt_elf.c
> There, thats better, now userspace can load everything. If we
> can figure out how to get userspace loaded....
>
> The kernel already knows how to load ELF files, and _has_ to do
> that job to get userspace running anyways. So why not use that
> mechanism for modules?
>
Because it's not the same mechanism at all. insmod is an ELF *LINKER*,
not just a loader for executable-format ELF files. There is a huge
difference between a linkable and an executable ELF file; a module is the
former, a binary executable is the latter.
-hpa