lkml.org 
[lkml]   [2007]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Open Firmware device tree virtual filesystem
    * ron minnich <rminnich@gmail.com> [070111 18:39]:
    > I'd like to put in my $.02 in favor of having a way to pass the OF
    > device tree to the kernel, in much the same way we pass stuff like
    > ACPI and PIRQ and MP tables now.

    This works fine for just passing the device tree, but it will fail for
    the next step of being able to use the firmware in the OS, and returning
    sanely to the firmware.

    > But any mechanism that depends on a callback to OFW is way too
    > limiting. As soon as you put that callback in, you lock out
    > - uBoot

    People in the uBoot project have been discussing adding OFW
    functionality because it is so useful.

    > - LinuxBIOS

    With some of the payloads, especially those you list below anyways.


    > - Bochs BIOS as used in Xen and other hypervisors and emulators

    You dont need it there. Think compatible. We are not going to get _rid_
    of legacy bios traces for another 10 years anyways.

    > - any path that uses kexec (since the first kernel probably shut down
    > OF)

    No, that path works fine. The first kernel uses OFW, so it wont shut it
    down. Only thing is you need to pass the callback to the loaded kernel.

    1 line of code.

    > - etherboot

    ok, well.

    > - GNUFI

    Reading UEFI.

    There you have a large number of callbacks anyways which will be
    supported anyways unless large parts of the industry stop their
    "Cuius regio, eius religio" behavior and do sane solutions rather than
    (U)EFI.

    This is a completely different path, and out of reach for us anyways.

    With GNUFI we support EFI callbacks, the same way as we support 16bit
    legacy callbacks with ADLO, and OFW callbacks with OFW.

    > So, while the idea of the OF tree is very general, and IMHO very
    > desirable, the idea of the callback is very specific to one firmware
    > implementation on one CPU architecture on one platform -- the OLPC --
    > and is hence not desirable at all.

    SUN, IBM, APPLE, ... lots of vendors have been using OFW for their
    machines. It is by no means a local phenomenon. This way of doing things
    has been working since about two decades now with nearly no changes.
    And it covers at least Sparc, Sparc64, PPC, PPC64, Mips, Arm, X86,
    X86-64. That's 8 CPU architectures. Far more successful than any other
    approach.

    > An idea that is potentially applicable and usable on all BIOSes
    > becomes usable on only one.

    The idea is to only have one in the end, and that is flexible enough to
    customize it. That's why it is open and we can look at the source.

    Some PowerPC systems use a flat tree without callback interface. Sure,
    if the machine is too slow to do the real thing, why not. But why throw
    away flexibility otherwise? It is not like we have to rely on some evil
    patented closed source crap that vendors hail and court as IP.

    > OFW is open source now. I think it's time to reexamine the basic
    > assumptions about the need for a callback, and see if something better
    > can't be done.

    I fully agree. And I believe there are very good things that can be done
    with callbacks. The reasons callbacks are evil is that you dont know
    what you call into. This is not at all the case here. It's a mere
    function call that calls some highly board specific code, not unlike all
    the calls we do in LinuxBIOS already today. Since we're 100% open
    source, we don't "cross a border" anymore.

    > Also, as others mentioned, callback into any sort of
    > firmware on SMP can and does get messy. I've seen this in practice on
    > EFI-based machines.

    Yes, executing closed source half undocumented binary blobs from your
    software might have undocumented harmful side effects. But that is a
    different story, no?

    > Otherwise, this is just too limited to be of any use to those of us
    > doing more than just OFW.

    Yes, the patch was specific to Open Firmware. It is just another
    interface next to

    - 16bit legacy callbacks
    - (u)efi legacy callbacks
    - existing openfirmware support code for non-x86 platforms.

    But: It is a first step that, as a mid-term goal, allows us to unify OFW
    support on all platforms to some extent. Of course. There will always be
    quirks. We have quirks in about every subsystem of Linux today, so that
    is not more scary.

    So what we need is one in-kernel interface that allows us to plug-in
    support code for each of the supported firmware interfaces. The attempt
    to use the same firmware interface on more than one platform helps that
    path.

    > Mitch, is there some way to get OF device tree to the kernel without
    > involving a callback? That would be quite nice.

    That is a nice idea, but unless there is any LinuxBIOS version that
    creates such a device tree and exports it as a data structure to the OS,
    why would we want to add such support to the Linux kernel?

    Stefan


    --
    coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
    Tel.: +49 761 7668825 • Fax: +49 761 7664613
    Email: info@coresystems.de • http://www.coresystems.de/
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-01-11 20:09    [W:3.763 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site