> 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 ...
>  

2.4 with debuging (CONFIG_KSYMS=yes)
 1337954 Aug 25 17:47 /boot/vmlinuz-2.4.22-1mdk

2.4 without KSYMS (~ kernel tmb here)
 1035464 Nov  9 04:04 /boot/vmlinuz-2.4.22-21br.1mdk

2.6 without debuging
 1532105 Oct 29 19:37 /boot/vmlinuz-2.6.0-test9-bk2
 1560749 Nov  4 04:42 /boot/vmlinuz-2.6.0-test9-bk8
 1555036 Nov  5 13:11 /boot/vmlinuz-2.6.0-test9-bk9

isn't this a bit special :(

> > > 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

IMO static configuration will be needed always

what happens if you have 2-3 NIC's, or soundcards
and want them in a certain order?

so why change the current static configuration with other 
static configuration using hotplug, when the second won't work
with kernels < 2.6 
IIRC mandrake still ships 2.2 kernel

svetljo

-- 
NEU F�R ALLE - GMX MediaCenter - f�r Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gru�, GMX FotoService

Jetzt kostenlos anmelden unter http://www.gmx.net

+++ GMX - die erste Adresse f�r Mail, Message, More! +++


Reply via email to