Re: [RFC 0/6] Backing Store for sysfs
From: Nick Piggin
Date: Tue Oct 07 2003 - 00:27:39 EST
Maneesh Soni wrote:
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
queue and iosched might not be good examples as they are somewhat broken
wrt the block device scheme. Possibly they will be put in their own kset,
with /sys/block/hda/queue symlinked to them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/