On Saturday 01 November 2003 21:01, Svetoslav Slavtchev wrote:
> > On Saturday 01 November 2003 06:03, Svetoslav Slavtchev wrote:
> > > > > all FS's built in ? why that ?
> > > >
> > > > Oops, there is no reason to do that, I've now compiled ext3, jbd,
> > > > ReiserFS, jfs and xfs as modules in -2mdk.
> > > > ext2 is still built-in because our initrd image is ext2.
> > > > By the way, should we switch to ROM FS or Minix FS for initrd in
> > > > order to gain some space ?
> > > >
> > > > my -2mdk rpms are available here :
> > > > http://compil.mandrake.org/~blino/kernel-2.6/
> > >
> > > first we've to hack mkinitrd,
> > > and i'm not sure how much will we gain,
> >
> > Well, adding support for alternate FS to mkinitrd is trivial, it is
> > rather
> >
> > administrative consideration - you need utilities for this available i.e.
> > proper Requires: etc.
> >
> > > besides initramfs is always in,
> > > (but it's pretty experimental stuff yet,
> > > and i haven't heard of successfull initrd's using it)
> > > probably better wait for it
> >
> > initramfs as implemented currently must be done at kernel build time
> > which
> >
> > makes it rather useless. It basically appends compressed cpio archives to
> > kernel. Frankly speaking I do not see any advantage in using it - both
> > initrd
> > and initramfs are initialized at the same time.
> >
> > The only remote advantage would be that initramfs does not require chroot
> > as
> > everything is unpacked into (mini-)root and thus using various programs
> > like
> > hotplug or modprobe is easier. I guess one can add support for initramfs
> > in
> > initrd image if needed then.
>
> OK
> so what options do we have to reduce the kernel/ initrd size ?
>
Why exactly do you want to do it? There is nothing special with 2.6 as far as
I can tell:
{pts/1}% LC_ALL=C ll /boot/initrd-2.4.22-10mdk.img
/boot/initrd-2.6.0-test9.img
-rw-r--r-- 1 root root 357177 Oct 25 18:36
/boot/initrd-2.4.22-10mdk.img
-rw-r--r-- 1 root root 139356 Nov 4 21:19
/boot/initrd-2.6.0-test9.img
now when I turned debugging off ...
> > I'd
> >
> > like to enable PCI coldplug but it apparently requires initscripts tuning
> > (at
> > least ALSA, possibly others, USB is not actually an issue with hotplug).
>
> i don't think enabling PCI cold pug is a good idea
> it might try to load the correct fb driver (which might currently be broken
>
> :(
>
> also it'll load the drivers for any hardware found (do you mentioned alsa
> for that reason?)
> but do we need this, we already have modprobe.[conf, preload, devfs?]
>
exactly to remove any need for static configuration. I still dream about
loading kernel and picking automatically correct drivers without user
intervention.
Now really. What we have is
- kernel is expected to provide aliases for device numbers, protocol numbers
etc. This obviates need to have manual configuration as in modutils
- we have hotplug and device IDs for most subsystems. That allows to match
driver and load it automatically.
What do we have now? We have exactly the same deviceID-to-module but as static
static table (ldetect-lst) that is used to create static configuration. But
all of this information is already available so it looks rather redundant ...
Sure there are open issues. Alternative drivers need to be handled (OSS vs
ALSA is the most obvious example). Possibly broken drivers need to be
handled. Some sort of "safe mode" with hotplug disabled need to exist. Sure
there will remain legacy devices that cannot be hotplugged.
not that I suggest doing all of this in next release. But as remote goal ...
-andrey
