Re: [Acpi] Re: ACPI fundamental locking problems

[ebiederm@xmission.com (Eric W. Biederman)]

Linus Torvalds <torvalds@transmeta.com> writes:

> On Wed, 4 Jul 2001, Alan Cox wrote:

> We migth want to just make initrd a built-in thing in the kernel,
> something that you simply cannot avoid. A lot of these things (ie dhcp for
> NFS root etc) are right now done in kernel space, simply because we don't
> want to depend on initrd, and people want to use old loaders.

That and the linux tools for making small binaries are relatively
immature.

> I don't like the current initrd very much myself, I have to admit. I'm not
> going to accept a "you have to have a ramdisk" approach - I think the
> ramdisks are really broken.
> 
> But I've seen a "populate ramfs from a tar-file built into 'bzImage'"
> patch somewhere, and that would be a whole lot more palatable to me.

To some extent I'd prefer to build the tar-file into vmlinux as that
makes it a multi architecture solution.  I don't like the fact that
rdev only works on x86.
 
> If anybody were to send me a patch that just unconditionally does this, I
> would probably not be adverse to putting it into 2.5.x. We have all the
> infrastructure to make all this a lot cleaner than it used to be (ie the
> "pivot_root()" stuff etc means that we can _truly_ do things from user
> mode, with no magic kernel flags).
>
> But if we do this, then we should _truly_ get rid of all the root device
> etc setup crap (and the "search for init" etc stuff - it _is_ going to be
> there, and THAT process is the one that should then search for the real
> init once it has booted).

A list of issues I can see with doing this right now.

- umounting the initial fs after you have called pivot_root is
  tricky, can we run a program from an internal mount only?
  (We can remove all of the files on the initial fs with rm -rf /
   assuming we are running on ramfs)

- The version of ``preinit'' cannot use glibc, there is too much
  bloat.  uclibc is o.k. but a little immature.  We can probably use
  the infrastructure we have in linux/unistd.h for doing system calls
  from the kernel to remove any dependieces on other packages.  But
  using kernel headers from user space has been outlawed... 

- In the case of console=tty0 console=ttyS0 /dev/console does not
  output to the same locations as printk.

- We must be architecture netural.  Do this only for x86 is
  unacceptable.

- The _init stuff that allows us to throw code after device
  initialization would need to be disabled to some extent because it
  would now depends on code in user space.

> That, together with reasonable interfaces to let ACPI set irq data for the
> kernel etc, might make moving ACPI back into user space possible in
> _practice_ and not just in theory.

Irq tables.  A corrected system memory map.  Builtin ISA devices.
Long term we need is an interface to feed a pre intialized 
``struct device'' (the renamed struct pci_device) tree into the kernel.

Eric