[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    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean