public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Booting a modular kernel through a multiple streams file
Date: 23 Dec 2001 14:24:36 -0700	[thread overview]
Message-ID: <m1heqhr5nv.fsf@frodo.biederman.org> (raw)
In-Reply-To: <59885C5E3098D511AD690002A5072D3C42D81C@orsmsx111.jf.intel.com> <m1r8pmqotz.fsf@frodo.biederman.org> <a04989$7n0$1@cesium.transmeta.com>
In-Reply-To: <a04989$7n0$1@cesium.transmeta.com>

"H. Peter Anvin" <hpa@zytor.com> writes:

> Very well said!!  I really think that an initramfs protocol which
> allows (but does not require!!) synthesis in the boot loader is the
> way to go.

Agreed.  Just one more thought before I take off on vacation.  

The concept of a generic boot protocol is something I like.  And it
seems the ability to include at least one and in general multiple
files with a kernel is highly desireable. 

In concepts that are well understood we have several potential
candidates.  We have the concept of a single file.  We have the
concept of multiple files.  And we have the concept of object files.

A single file works but it really doesn't offer much flexibility in
those cases where you really need it.  Modules don't need any support
by the loaded kernel at all because they are linked in transparently.
The downside with modules is that because the bootloader must include
a linker this requires a fair amount of work in the bootloader.  It
needs a very particular kernel setup.  Plus it has issues with binary
only modules and a GPL'd kernel.  A filesystem in a stream format
(tar/cpio/pax...) gets the job done.  You can use a relatively stupid
bootloader, so verification for correctness is easier.  Plus a
bootloader can inject files into the filesystem with the expectation
that they will meat with a reasonable interpretation.  Something not
possible with modules as they are code first data second.

So in the generic sense I agree that a bootloader loaded filesystem is
the way to go.  The attributes given by the GRUB filesystem are
inadequate, you can't even describe a device node.  And except for
permissions something running in userspace at kernel init time is
going to exercise the system to it's limit.  So we really need a
filesystem format that can handle extended attributes and all kinds of
other weird and strange things.  Which is basically a requirement for
simple extensibility.

So we have the choice now of being picky in the format we select or
long term needing to support multiple stream filesystems.  Given that
we would like bootloaders to have the ability to inject individual
files being picky now is probably a good idea.  Since it would be
silly to support multiple filesystems in the bootloader.  Everyone
except GRUB seems reluctant to do that sort of thing.

Eric

  reply	other threads:[~2001-12-23 21:26 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-23  7:20 Booting a modular kernel through a multiple streams file Grover, Andrew
2001-12-23  9:15 ` Eric W. Biederman
2001-12-23  9:47   ` H. Peter Anvin
2001-12-23 21:24     ` Eric W. Biederman [this message]
     [not found] <Pine.GSO.4.21.0112190313080.9963-100000@weyl.math.psu.edu>
2001-12-19  8:47 ` Eric W. Biederman
2001-12-19 14:55   ` Alexander Viro
2001-12-19 15:49     ` Eric W. Biederman
2001-12-19 17:03       ` Alexander Viro
2001-12-19 19:01         ` Eric W. Biederman
2001-12-20  3:30         ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2001-12-18 20:35 Torrey Hoffman
2001-12-18 19:50 Grover, Andrew
2001-12-18 20:26 ` Alexander Viro
2001-12-18 20:30 ` M. R. Brown
2001-12-18 20:35 ` H. Peter Anvin
2001-12-19  9:34 ` James A Sutherland
2001-12-23  1:02   ` Dave Cinege
2001-12-23  9:10     ` James A Sutherland
2001-12-19 14:13 ` Erik Mouw
2001-12-18 17:47 Grover, Andrew
2001-12-18 18:53 ` Alexander Viro
2001-12-18 19:43 ` David Weinehall
2001-12-18 17:43 Grover, Andrew
2001-12-18 18:45 ` Alexander Viro
2001-12-18 18:49 ` Greg KH
     [not found] <Pine.GSO.4.21.0112180350550.6100-100000@weyl.math.psu.edu>
2001-12-18 11:16 ` James A Sutherland
2001-12-18 19:10   ` H. Peter Anvin
2001-12-19  9:27     ` James A Sutherland
2001-12-19 10:11       ` Erik Andersen
2001-12-23  0:39     ` Dave Cinege
2001-12-23  0:42       ` H. Peter Anvin
2001-12-23  1:15         ` Dave Cinege
2001-12-23  1:35           ` H. Peter Anvin
2001-12-23  2:08             ` Alexander Viro
2001-12-17 22:10 Grover, Andrew
2001-12-18  2:31 ` Alexander Viro
2001-12-18  5:46   ` Craig Christophel
2001-12-23  0:28   ` Dave Cinege
2001-12-23  0:44   ` Dave Cinege
2001-12-23  1:39   ` H. Peter Anvin
2001-12-23  2:10     ` Alexander Viro
2001-12-23  3:00       ` Dave Cinege
2001-12-23  3:52         ` Alexander Viro
2001-12-23  4:41         ` Ryan Cumming
2001-12-23  5:52           ` Dave Cinege
2001-12-23  7:16             ` Bernd Eckenfels
2001-12-23  8:06               ` H. Peter Anvin
2001-12-23 12:22                 ` Kai Henningsen
2001-12-23 20:58                   ` Erik Mouw
2001-12-17 19:53 Grover, Andrew
2001-12-17 20:26 ` Alexander Viro
2001-12-16 20:37 Otto Wyss
2001-12-16 20:50 ` Alexander Viro
2001-12-17 18:49   ` Otto Wyss
2001-12-17 19:07     ` Andreas Dilger
2001-12-20 18:47       ` Otto Wyss
2001-12-16 21:06 ` H. Peter Anvin
2001-12-16 22:02   ` antirez
2001-12-16 22:18     ` H. Peter Anvin
2001-12-23  0:08 ` Dave Cinege
2001-12-23  6:26   ` Eric W. Biederman
2001-12-23 13:48   ` Alan Cox
2001-12-23 17:57     ` Dave Cinege
2001-12-23 23:05     ` Marcus Meissner
2001-12-24  2:38       ` Alan Cox
2001-12-27 10:58       ` Wilfried Weissmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1heqhr5nv.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox