lkml.org 
[lkml]   [2003]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 0/6] Backing Store for sysfs
    On Mon, Oct 06, 2003 at 01:29:20PM -0700, Patrick Mochel wrote:
    >
    > Uh, that's about the same thing I suggested, though probably not as
    > concisely:
    >
    > "As I said before, I don't know the right solution, but the directions to
    > look in are related to attribute groups. Attributes definitely consume the
    > most amount of memory (as opposed to the kobject hierachy), so delaying
    > their creation would help, hopefully without making the interface too
    > awkward.

    Ok.. attributes do consume maximum in sysfs. In the system I mentioned
    leaf dentries are about 65% of the total.

    > You can also use the assumption that an attribute group exists for all the
    > kobjects in a kset, and that a kobject knows what kset it belongs to. And

    That's not correct... kobject corresponding to /sys/block/hda/queue
    doesnot know which kset it belongs to and what are its attributes. Same
    for /sys/block/hda/queue/iosched.

    > that eventually, all attributes should be added as part of an attribute
    > group.."
    >
    > Attributes are the leaf entries, and they don't need to always exist. But,
    > you have easy access to them via the attribute groups of the ksets the
    > kobjects belong to.
    >

    Having backing store just for leaf dentries should be fine. But there is
    _no_ easy access for attributes. For this also I see some data change required
    as of now. The reasons are
    - not all kobjects belong to a kset. For example, /sys/block/hda/queue
    - not all ksets have attribute groups

    I don't see any generic rule for finding attributes or attribute group
    of a kobject. Such random-ness forced me to add new fields to kobject. The
    sysfs picture doesnot show the kset-kobject relationship. For example
    kobject corresponding /sys/devices/system does not belong to devices_subsystem.
    and it is not in the devices_subsys->list. There was no other way except to
    build new hierarchy info in the kobject.

    What are people's opinion about the way I have linked attributes and
    attributes_group to the kobject. I could not link "struct attribute" and
    "struct attriubte_group" directly to kobject because these are generally
    statically alocated and many kobjects will have the same attribute structure.
    and are asigned to multiple kobjects

    Thanks
    Maneesh
    --
    Maneesh Soni
    Linux Technology Center,
    IBM Software Lab, Bangalore, India
    email: maneesh@in.ibm.com
    Phone: 91-80-5044999 Fax: 91-80-5268553
    T/L : 9243696
    -
    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: 2005-03-22 13:49    [W:0.024 / U:29.820 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site