[lkml]   [2003]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    Maneesh Soni
    Linux Technology Center,
    IBM Software Lab, Bangalore, India
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:49    [W:0.023 / U:21.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site