Re: [Maxlinux-devel] [RFC] precompiled kernels, initrd, and driver disks

[Michael L. <inc...@my...>]

Kelledin,

Even though some of what you say is already laid out for us, why not
contact some of the other distros and see how they do it, in that way
we could use some of their ideas in doing our kernel.

Michael


On Tue, 3 Sep 2002 10:22:34 -0500, "Kelledin"
<kel...@sk...> said:
> Sooner or later, we need to decide how to manage precompiled=20
> kernels and precompiled drivers.  So far, the basics of doing=20
> this are laid out for us already; we will have almost all=20
> drivers compiled as modules, and we will place modules needed at=20
> boot-time in an initial RAMdisk image (initrd).  The initial=20
> RAMdisk image will contain drivers and applications necessary=20
> for loading those drivers and mounting the "real" root FS.
>=20
> So far, here's what I'm thinking of doing within the initrd:
>=20
> 1) Have a statically compiled binary installed as /sbin/init on=20
>    the initrd.  Also have /sbin/modprobe on the initrd as well=20
>    (also statically compiled).
>=20
> 2) The initrd's /sbin/init will be responsible for the following:
>=20
>    - Looking in /etc/modules.rc to determine what modules to=20
>      load.
>=20
>    - Calling /sbin/modprobe to load those modules.
>=20
>    - Looking in /etc/mount.rc to determine what device to mount=20
>      as the "real" root FS, what FS type is on that device, and
>      what options to use when mounting it.  "/bin/mount" will
>      not be included in the initrd; the initrd's /sbin/init will
>      call the mount() syscall directly instead to save space.
>=20
>    - Mounting the specified device and calling pivot_root() to
>      change to the new root FS.
>=20
>    - Executing the "real" /sbin/init to take over booting.
>=20
> 3) During future versions of the installation program, we should=20
>    have a precompiled kernel available, as well as modular=20
>    drivers for various driver and filesystem types.  These=20
>    modular drivers should be avaliable as compressed packages
>    on a separate "driver disk" during install.  The installation
>    program should include options for auto-probing drivers,
>    configuring which drivers get auto-probed, and specifying
>    custom modprobe options for each driver.  There should also
>    be a specified format for supplemental driver disks provided
>    by third parties (such as hardware manufacturers).
>=20
> The part we need to decide on together is the format of a=20
> compressed "driver pack".  The driver pack should include kernel=20
> modules to be loaded, a list of those modules and human-readable=20
> one-line comments for each one, and a human-readable one-line=20
> description of the driver pack and what it supports.  An=20
> optional comprehensive README for the driver should be supported=20
> as well.  I have other features in mind, but they can wait.
>=20
> --=20
> Kelledin
> "If a server crashes in a server farm and no one pings it, does=20
> it still cost four figures to fix?"
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> Maxlinux-devel mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxlinux-devel
>=20

--
Michael Lauzon
Founder & Lead Project Manager
InceptionOS Project
http://www.inceptionos.org/
mi...@in...

--=20
http://fastmail.fm
 - Ever wonder why we aren't named snailmail.sm?=20