lkml.org 
[lkml]   [2007]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] Open Firmware device tree virtual filesystem
    Date
    >> Not single thread -- but a "global OF lock" yes.  Not that
    >> it matters too much, (almost) all property accesses are init
    >> time anyway (which is effectively single threaded).
    >
    > Not that true anymore. A lot of driver probe is being threaded
    > nowadays,
    > either bcs of the new multithread probing bits, or because they get
    > loaded by userland from some initramfs etc..

    The kernel doesn't care if one CPU is in OF land while the others
    are doing other stuff -- well you have to make sure the OF won't
    try to use a hardware device at the same time as the kernel, true.

    >>> Finally, you can't have something as simple as powerpc's
    >>> get_property()
    >>> (that just returns a pointer to the property content) with direct OF
    >>> access unless you use some magic static buffer or some crap around
    >>> those
    >>> lines, or add passing of a buffer in, so from a driver pointer of
    >>> view,
    >>> the interface provided by powerpc/sparc is nicer.
    >>
    >> But since you have a _put() function anyway, for your reference
    >> counting, having magic (automatically allocated, not static of
    >> course) buffers works just fine.
    >
    > You can maybe create an in-memory cache of all properties in a node
    > from
    > whatever function that returns a node pointer and dispose of them on
    > _put(), that would allow to keep the get_property semantics as-is with
    > a
    > "live" tree, but I still don't see the point

    I'm a bit concerned about the 100kB or so of data duplication
    (on a *quite big* device tree), and the extra code you need
    (all changes have to be done to both tree copies). Maybe
    I shouldn't be worried; still, it's obviously not a great
    idea to *require* any arch to get and keep a full copy of
    the tree -- it's wasteful and unnecessary.


    Segher

    -
    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-02 22:31    [W:4.798 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site