[lkml]   [2001]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Acpi] Re: ACPI fundamental locking problems
    Linus Torvalds <> 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

    > 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

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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:57    [W:0.035 / U:36.696 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site