RE: Re: Re: DSDT in initrd

RE: Re: Re: DSDT in initrd

[Grover, Andrew]

If I may step on my soapbox...

I think the whole notion of initrd is a hack to work around the fact
that Linux traditionally has not relied on the fact that the boot loader
can load individual modules. The limitations of lilo should not be taken
to be the limitations of all boot loaders. lilo is the lowest common
denominator loader, and while we want Linux to work with it, Linux could
work *better* if we took advantage of grub's additional capabilities.

What this enables is not only an elimination of the hassle of initrd, it
enables previously unmodularizable things like ACPI, or PCI, or all the
special code needed for x86 subarchs, or whatever other code that one
machine needs (highmem?) but that most do not to now be modularized.
Linux distributions seem to need more and more kernel images for all
these weird cases that initrd doesn't solve, and this could allow them
to have *one* smaller kernel with the stuff that everyone needs, and the
installer configures the loader to load the additional pieces that the
system happens to need.

Having the modules specified individually to the bootloader makes things
simpler.
Having an in-kernel linker lets previously unmodularizable code be
modularized.

(This is only tangentially related to ACPI, but I mention it because I
see ACPI worsening the problem. What if I'm not installing on an ACPI
system? Now either a) My distro has an ACPI and non-ACPI kernel image
and installed the right one or b) I've got unused code sitting in RAM,
useless. But it's not just ACPI. I can think of a ton of different
kernel options that may cause distros to generate a combinatorial number
of kernel images. Yuck.)

OK I'm done...

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Re: Re: DSDT in initrd

[Mark Santcroos]

Linux people might want to look at how FreeBSD does this.
However, as Andy states, this is not ACPI specific, it means an overhaul
for the whole Linux booting process.

Mark

-- 
Mark Santcroos                    RIPE Network Coordination Centre
http://www.ripe.net/home/mark/    New Projects Group/TTM


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Re: Re: DSDT in initrd

[M. Warner Losh]

In message: <20030522080420.GA634-ScjxTogt4I4lGuH5DXb43w@public.gmane.org>
            Mark Santcroos <marks-h3GR0owD+wQ@public.gmane.org> writes:
: Linux people might want to look at how FreeBSD does this.
: However, as Andy states, this is not ACPI specific, it means an overhaul
: for the whole Linux booting process.

Basically, for those unfamiliar, FreeBSD has a three stage boot.
First stage know just enough to load the second stage.  Second stage
knows enough about file systems to load a third stage.  Third stage
can load kernels, modules and pass information to the kernels.  Very
handy for thoese sorts of situations.  While the first two stages very
from arch to arch, the third stage is basically the same on all
architectures (although there is a md component to is that handles
processor specific relocation goo, etc).

Loading DSDT tables in FreeBSD is just another thing that the loader
can load before transferring control to the kernel.

Warner


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

RE: Re: Re: DSDT in initrd

[Alan Cox]

On Iau, 2003-05-22 at 08:48, Grover, Andrew wrote:
> can load individual modules. The limitations of lilo should not be taken
> to be the limitations of all boot loaders. lilo is the lowest common
> denominator loader, and while we want Linux to work with it, Linux could
> work *better* if we took advantage of grub's additional capabilities.

On a lot of non x86 platforms Lilo is considerably more featureful.
Initrd basically exists as a way to take an arbitary bootloader and feed
it stuff. In some cases the tools even nail the initrd onto the end of
the binary because the boot loader isnt smart enough to load.

> What this enables is not only an elimination of the hassle of initrd, it
> enables previously unmodularizable things like ACPI, or PCI, or all the
> special code needed for x86 subarchs, or whatever other code that one
> machine needs (highmem?) but that most do not to now be modularized.

I'm not sure it does. A lot of the stuff like handling multiple system
variants requires you are able to handle all of them until you reach a 
point where you know the one you want. 

Modularisation is the key but I suspect we actually want to turn the
problem inside out. If for example all the ACPI stuff was linked into an
acpi.text and acpi.data section then we can boot, having established we
don't need acpi we can eject acpi just like we eject __init code.

> Having the modules specified individually to the bootloader makes things
> simpler.

Whats the difference between feedling the list to the bootloader or to
mkinitrd ?

> Having an in-kernel linker lets previously unmodularizable code be
> modularized.

Definitely - and Rusty has done that for 2.5.x

> see ACPI worsening the problem. What if I'm not installing on an ACPI
> system? Now either a) My distro has an ACPI and non-ACPI kernel image
> and installed the right one or b) I've got unused code sitting in RAM,
> useless. But it's not just ACPI. I can think of a ton of different
> kernel options that may cause distros to generate a combinatorial number
> of kernel images. Yuck.)


The big causes are SMP and CPU specific optimisation stuff. Those are
much harder to handle than the ACPI one.



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Re: Re: DSDT in initrd

[Ducrot Bruno]

On Thu, May 22, 2003 at 12:40:52PM +0100, Alan Cox wrote:
> On Iau, 2003-05-22 at 08:48, Grover, Andrew wrote:
> > can load individual modules. The limitations of lilo should not be taken
> > to be the limitations of all boot loaders. lilo is the lowest common
> > denominator loader, and while we want Linux to work with it, Linux could
> > work *better* if we took advantage of grub's additional capabilities.
> 
> On a lot of non x86 platforms Lilo is considerably more featureful.
> Initrd basically exists as a way to take an arbitary bootloader and feed
> it stuff. In some cases the tools even nail the initrd onto the end of
> the binary because the boot loader isnt smart enough to load.

I don't understand.  On a lot of non x86 lilo do not even exist (PPC <- quick
or yaboot, SPARC <- silo) etc.

> 
> > What this enables is not only an elimination of the hassle of initrd, it
> > enables previously unmodularizable things like ACPI, or PCI, or all the
> > special code needed for x86 subarchs, or whatever other code that one
> > machine needs (highmem?) but that most do not to now be modularized.
> 
> I'm not sure it does. A lot of the stuff like handling multiple system
> variants requires you are able to handle all of them until you reach a 
> point where you know the one you want. 
> 
> Modularisation is the key but I suspect we actually want to turn the
> problem inside out. If for example all the ACPI stuff was linked into an
> acpi.text and acpi.data section then we can boot, having established we
> don't need acpi we can eject acpi just like we eject __init code.
> 
> > Having the modules specified individually to the bootloader makes things
> > simpler.
> 
> Whats the difference between feedling the list to the bootloader or to
> mkinitrd ?

You can retrieve most hardware configuration (PnP, ACPI, etc) via a module
at boot loader stage, even if kernel is not launched, not after you have
access to the fs inside the initrd image.

> 
> > Having an in-kernel linker lets previously unmodularizable code be
> > modularized.
> 
> Definitely - and Rusty has done that for 2.5.x

Just a question (I have not looked).  Can you preload modules or
discharge them before booting kernel with 2.5 (as in FreeBSD) ?

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Re: Re: DSDT in initrd

[Russell Coker]

On Thu, 22 May 2003 23:31, Ducrot Bruno wrote:
> > On a lot of non x86 platforms Lilo is considerably more featureful.
> > Initrd basically exists as a way to take an arbitary bootloader and feed
> > it stuff. In some cases the tools even nail the initrd onto the end of
> > the binary because the boot loader isnt smart enough to load.
>
> I don't understand.  On a lot of non x86 lilo do not even exist (PPC <-
> quick or yaboot, SPARC <- silo) etc.

To be more precise, LILO only exists on i386.  Large amounts of LILO code are 
x86 assembler.  Most of the code in the main /usr/bin/lilo program is 
designed to guess what the BIOS expects and put things in the right place 
(determining IBM PC BIOS codes from Linux device nodes, etc).

Of course you could probably port LILO to a non-x86 platform, but then it 
probably wouldn't be recognisable.  Half the options in /etc/lilo.conf would 
need to be changed or removed.

I'm not sure what Alan means.  But on x86 LILO has many desirable features 
that other boot loaders lack.  LILO supports serial consoles, graphical 
splash screens, and isn't really painful to install.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Re: Re: DSDT in initrd

[Pavel Machek]

Hi!

> What this enables is not only an elimination of the hassle of initrd, it
> enables previously unmodularizable things like ACPI, or PCI, or all the
> special code needed for x86 subarchs, or whatever other code that one

subarchs are different issue. They can't
be modularized without runtime overhead.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

RE: Re: Re: DSDT in initrd

[Grover, Andrew]

> From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org] 
> > What this enables is not only an elimination of the hassle 
> of initrd, it
> > enables previously unmodularizable things like ACPI, or 
> PCI, or all the
> > special code needed for x86 subarchs, or whatever other 
> code that one
> 
> subarchs are different issue. They can't
> be modularized without runtime overhead.

How much runtime overhead?

-- Andy


-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge

Re: Re: Re: DSDT in initrd

[Pavel Machek]

Hi!

> > > What this enables is not only an elimination of the hassle 
> > of initrd, it
> > > enables previously unmodularizable things like ACPI, or 
> > PCI, or all the
> > > special code needed for x86 subarchs, or whatever other 
> > code that one
> > 
> > subarchs are different issue. They can't
> > be modularized without runtime overhead.
> 
> How much runtime overhead?

Hard to tell... It might be 10% in heavy-interrupt-load situation...

							Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

RE: Re: Re: DSDT in initrd

[Grover, Andrew]

> From: Pavel Machek [mailto:pavel-+ZI9xUNit7I@public.gmane.org] 
> > > > What this enables is not only an elimination of the hassle 
> > > of initrd, it
> > > > enables previously unmodularizable things like ACPI, or 
> > > PCI, or all the
> > > > special code needed for x86 subarchs, or whatever other 
> > > code that one
> > > 
> > > subarchs are different issue. They can't
> > > be modularized without runtime overhead.
> > 
> > How much runtime overhead?
> 
> Hard to tell... It might be 10% in heavy-interrupt-load situation...

Can you help me understand more about why this might be? Why would
modularized code be a performance hit over statically linked? I was
assuming there would be another pointer dereference perhaps but that
certainly is not going to be noticed. We already have drivers in
modules, I'm trying to understand how for example a hi-perf nic driver
performs the same when modularized but subarch stuff wouldn't, when I'm
assuming it would just be like a "driver" for the particular
peculiarities of the platform.

Thanks -- Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Re: Re: DSDT in initrd

[Pavel Machek]

Hi!

> > > > > What this enables is not only an elimination of the hassle 
> > > > of initrd, it
> > > > > enables previously unmodularizable things like ACPI, or 
> > > > PCI, or all the
> > > > > special code needed for x86 subarchs, or whatever other 
> > > > code that one
> > > > 
> > > > subarchs are different issue. They can't
> > > > be modularized without runtime overhead.
> > > 
> > > How much runtime overhead?
> > 
> > Hard to tell... It might be 10% in heavy-interrupt-load situation...
> 
> Can you help me understand more about why this might be? Why would
> modularized code be a performance hit over statically linked? 

There's a *lot* of small inline functions, look at mach_apic.h. You probably
don't want them to be called using function pointer.

Note note note: I'm not 100% convinced the pointer dereference is
going to be noticable. I guess you have to talk to NUMAQ people to get
the answers...

> I was
> assuming there would be another pointer dereference perhaps but that
> certainly is not going to be noticed. We already have drivers in
> modules, I'm trying to understand how for example a hi-perf nic driver
> performs the same when modularized but subarch stuff wouldn't, when I'm
> assuming it would just be like a "driver" for the particular
> peculiarities of the platform.

Because in each interrupt NIC has to be talked to once, but apic has
to be talked to few times?
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

Re: Re: Re: DSDT in initrd

[Matthew Wilcox]

On Wed, May 28, 2003 at 01:27:40PM -0700, Grover, Andrew wrote:
> I'm trying to understand how for example a hi-perf nic driver
> performs the same when modularized but subarch stuff wouldn't, when I'm
> assuming it would just be like a "driver" for the particular
> peculiarities of the platform.

A common fallacy.  There's a noticable performance loss when a driver
is compiled as a module, and it mostly has to do with the fact that
drivers are loaded into vmalloc space so they consume TLBs (rather than
being part of the kernel's 4MB mapping).

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5