Re: sysfs: Add an 'events' class. (was: Re: [RFC][PATCH] perf: sysfstype id)

[Kay Sievers]

On Wed, Nov 10, 2010 at 14:36, Ingo Molnar <mingo@xxxxxxx> wrote:
> * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
>> On Tue, 2010-11-09 at 14:13 -0800, Greg KH wrote:
>>
>> > You missed the embedded track at Plumbers where we talked about never
>> > adding another class to the kernel. ÂPlease use bus_id instead for this.
>>
>> I did, it was early and I wasn't aware this all comes under the heading
>> of embedded.
>>
>> Anyway, anybody got a good example of bus_type I can 'borrow' ?
>>
>> Also, it would be really nice if you (plural) could make this subsystem thing
>> happen, calling tihngs a bus that aren't a bus just makes me upset ;-)
>
> Same here - calling events a 'bus' is like totally brain-dead IMHO. It implies
> something hardware, while many events are not related to any hardware component but
> are pure software abstractions: such as context-switches, or syscall entries, or VM
> events.

Please use a bus, regardless of the name, class is dead and you will
need stuff tha can only happen at bus. We'll fix the name later.

> So i'd rather have 'events' or 'event_source' as a 'class' temporarily, than have it
> as a 'bus' temporarily - and we get the real fix whenever the sysfs unification
> happens.

Nope, that can not work.

> I also have a question about this future plan mentioned in
> Documentation/sysfs-rules.txt:
>
> Â- Hierarchy in a single device tree
> Â There is only one valid place in sysfs where hierarchy can be examined
> Â and this is below: /sys/devices.
> Â It is planned that all device directories will end up in the tree
> Â below this directory.
>
> So did i get it right, sysfs is going to convert from a VFS hiearchy/enumeration to
> a flat enumeration of entities, all listed in /dev/devices/?

I guess you mean /sys. No, /sys/devices/ is and stays as a hierarchy
and will not be flat.

> Why is that done? I think it's quite nice that the actual topology is represented
> right now via the sysfs VFS structure - so that we have things like:
>
> Â /sys/devices/system/ioapic/ioapic0/

That does not change at all.

> Where there's is a proper hierarchy showing that we have a 'system', which has an
> 'ioapic', which has an ioapic numbered '0'. That entity could then grow 'events' and
> have:
>
> Â /sys/devices/system/ioapic/ioapic0/events/
>
> And could show various IO-APIC events, such as (future, possible events):
>
> Â /sys/devices/system/ioapic/ioapic0/events/irq/
> Â /sys/devices/system/ioapic/ioapic0/events/register-read/
> Â /sys/devices/system/ioapic/ioapic0/events/register-write/
> Â /sys/devices/system/ioapic/ioapic0/events/affinity/
> Â [...]
>
> So is the plan to get rid of such rich hiearchies and just use a flat store of
> everything in /sys/devices/?

No. Where do you get that idea from?

> My hope would be to _increase_ the depth of sysfs in the future, to express every
> meaningful hiearchy that exists in the system (be that hw hierarchy or some sw
> abstraction hierarchy). But maybe i got it all wrong so please advise.

Yeah, seems all wrong. :)

/sys/device is the hierarchy (ans will stay as it is), /sys/class,bus
(later /sys/subsystem/) is the flat list of devices per subsystem (to
find all devices of a specific subsystem). The list _points_ to
devices in /sys/devices, it does never contain any devices. You might
want re-read the last mail in this thread, where I explained the
difference between hierarchy and classification in more details.

Kay
--
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/