[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: ACPI fundamental locking problems
    > We're depending on vendors (aka the BIOS) for all the ACPI tables, as well
    > as every other piece of a priori data we need to boot the OS.

    They have had enough problems getting simpler API's right. The ACPI spec is
    bloated, complex, and very hard to follow - and its written in my native
    language. I really do not envy a random BIOS writers task.

    > Could I please ask that you at least show me a system where this is a
    > problem before throwing out all the work we've done on ACPI because of this
    > technical nit?

    The goal isnt a technical nit, its to avoid loading 300Kbytes of crud (which
    should mostly be in user space anyway) on the 99.9% of machines where we dont
    need it.

    The user space thing isnt an idle comment btw, its something that I think we
    should actively pursue for 2.5. By making better use of initrd and the clean
    ramfsroot stuff Al wants to do we can push a lot of stuff (bootp, dhcp,
    dmi based configuration fixups, acpi) almost entirely into user space.
    That makes me a lot lot happier.

    The fact that it takes more code to parse and interpret ACPI than it does to
    route traffic on the internet backbones should be a hint something is badly
    wrong either in ACPI the spec, ACPI the implenentation or both.

    Reading the code I can find some examples of pointless code bloat, but not
    enough to convince me the broken part isnt the spec.


    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 13:17    [W:0.020 / U:32.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site