Re: Whys and hows of initrds

Re: Whys and hows of initrds

[Robert Hancock]

grfgguvf@gmail.com wrote:
> Hi,
> I don't know if the LKML is a technical kernel development list or a
> newbie support list (or both?) so maybe I'm posting to the wrong
> place.

You likely are.. and this is also quite distribution specific so a 
distribution support forum would likely be a better place to ask.

Whether or not you need an initrd depends on whether or not drivers 
needed to mount the root filesystem are compiled as modules or built 
into the kernel. If they are all built in then you shouldn't really need 
an initrd. However distributions usually use it so that the kernel can 
be the same for all systems and simply load the correct modules.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Whys and hows of initrds

[grfgguvf]

Hi,
I don't know if the LKML is a technical kernel development list or a
newbie support list (or both?) so maybe I'm posting to the wrong
place.

Questions:
* Why is an initrd needed?
* What does it do?
* What are the differences between an initrd and an initramdisk (if
any)? And an initramfs?
* Why cannot the task of initrds be done more easily?
* Why don't other operating systems need an equivalent? Or do they?

Opinions and technical explanations welcome. Please, no excessive flames!

I have searched the FAQs, HOWTOs and guides on tldp.org, but it seems
to me there is no "initrd FAQ". If I just didn't find it then I
welcome any pointers and sorry for wasting time...

Re: Whys and hows of initrds

[grfgguvf]

On 11/6/05, Jeffrey Hundstad wrote:
> boot process to continue.  It MAY also mount a network file system and
> boot from that.

But the kernel can do that without an initrd as well.

> >* What are the differences between an initrd and an initramdisk (if
> >any)? And an initramfs?
> >
> There is a nice read post not that long ago comparing some of them, you
> may want to scan lat months archives.  It was a documentation patch...

I will look around. Thanks!

> Other OSes just load everything; which isn't very efficient.

FreeBSD (for example) has a bootloader that can load arbitrary modules
in addition to the kernel.
Is there anything preventing that to be done with Linux? Or is it just
not powerful enough?

Re: Whys and hows of initrds

[Andreas Schwab]

<grfgguvf@gmail.com> writes:

> FreeBSD (for example) has a bootloader that can load arbitrary modules
> in addition to the kernel.
> Is there anything preventing that to be done with Linux? Or is it just
> not powerful enough?

Implementing the module loading in the boot loader means duplicating the
functionality there, making the boot loader more complex and dependent on
the loaded kernel.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Whys and hows of initrds

[Alistair John Strachan]

On Sunday 06 November 2005 17:24, grfgguvf@gmail.com wrote:
> Hi,
> I don't know if the LKML is a technical kernel development list or a
> newbie support list (or both?) so maybe I'm posting to the wrong
> place.
>
> Questions:
> * Why is an initrd needed?
> * What does it do?

Though there are reasons beyond this, ultimately an initrd is useful primarily 
to distributors, who provide too many drivers to build them all in (the 
resulting kernel image would be too large to boot).

In particular, filesystem, RAID and SCSI drivers (required for rootfs to exist 
before calling onto init), are put into such an image.

> * What are the differences between an initrd and an initramdisk (if
> any)? And an initramfs?
> * Why cannot the task of initrds be done more easily?

> * Why don't other operating systems need an equivalent? Or do they?
>
> Opinions and technical explanations welcome. Please, no excessive flames!

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: Whys and hows of initrds

[Neil Brown]

On Sunday November 6, grfgguvf@gmail.com wrote:
> Hi,
> I don't know if the LKML is a technical kernel development list or a
> newbie support list (or both?) so maybe I'm posting to the wrong
> place.
> 
> Questions:
> * Why is an initrd needed?

Because it is the best way to do the things that it does.  See next
question.

> * What does it do?

It allows various system configuration to be written as user-space code
rather than kernel-space code.  This is a *good thing* as user-space
is more forgiving, and somethings fits there more naturally.
This includes:
  module loading
  device discovery
  device configuration (e.g. raid arrays etc).
  network configuration
  root-device mounting

With an initrd, all this can be done with just memory and a processor.
Things - arbitrary things - can be done before any IO devices have
been initialised.

I heard a talk at LCA about the development of the Power5 architecture
and first getting Linux running on it.  They used debug hardware load a
kernel and an initrd image into memory, and then said 'go'.  They could
get it doing things like exercising memory and such before it even
bothered to detect and configure the PCI buss.  This isn't the sort of
thing that initrd was originally intended for (I think), but it shows
that it does give a great deal of flexibility.


> * What are the differences between an initrd and an initramdisk (if
> any)? And an initramfs?

I think initrd and initramdisk are different names for the same thing.
initramfs is different in detail but similar in purpose.

An initrd is an image of a filesystem - often cramfs or similar.  It
is loaded into a ramdisk and then the ramdisk is mounted as a
filesystem.

An initramfs works differently.  The image is a compressed CPIO
archive.  The kernel creates a 'tmpfs' - which is an internal
filesystem with no backing store - and explodes the archive into the
filesystem.

This has the advantage that the filesystem can grow in size - there
are no arbitrary limits like there have to be when you create an
initrd image.


> * Why cannot the task of initrds be done more easily?

How hard is it?  Distributions provide scripts that build them for you
with little or no effort.

Some of the tasks that an initrd can be done directly by the kernel,
but this is sub-optimal.  
It leads to code duplication as many of the tasks need to be do-able
from userspace anyway, so there is already userspace code to do it -
why bother duplicating such code in the kernel.

Also, where device discovery/configuration has to be done in the
kernel, there is a desire to keep the kernel-code minimal which tends
to reduce functionality.  It is best to do the job properly with
user-space code.

To be fair - I do agree that it could be easier than it is.  I think
that it probably just needs someone to take it on as a project, and
find out what all the disparate needs are, and put together some
infrastructure that makes it "just work" for everyone.

> * Why don't other operating systems need an equivalent? Or do they?

You would need to ask the other operating systems people that.

NeilBrown

Re: Whys and hows of initrds

[grfgguvf]

Thank you for the useful explanations/rationale.