ktypes vs. devices classes (struct class)

[Richard]

Hi,

I appreciate your answer, thank you for your time.

> 
> Look closer.  Tell me what "struct class" is for vs. what "struct
> kobj_type" is for and see if they both could be used for the same thing?

I've looked at the definitions in include/linux and thought a bit about 
the semantics.

struct kobj_type defines behaviour (sysfs_ops and default_attrs) that is 
common for multiple kobjects. But those kobjects could be embedded in 
drivers, devices or a bus.

I think one core difference is that "struct class" is strictly for 
devices so it's more specific and contains a lot of members that are 
only relevant for devices.

Additionally (this was my theory before which I hoped to hear verified 
before) "struct class" is more "user oriented" and might contain 
attributes and APIs that are relevant for users, but not as relevant 
internally.

Are those two theories/reasons correct?

My digging however has brought me to a few new questions:

Do all devices (their kobjects to be more precise) in one class (e.g. 
/sys/class/net ) belong to the same ktype?

Is it possible that one device belongs to several classes?

I've seen struct class defines **class_groups, but (contrary to struct 
kobj_type) not the corresponding struct sysfs_ops, why? Where is it then?

> 
> When we implemented them, we didn't think so but maybe something has
> changed to now allow this?  If so, great, please send us patches to do
> so!

Oh please don't misunderstand me, even if we had come to an agreement 
that this architecture was unelegent (which it isn't I see the point 
now), I don't think that would have been reason enough to change it.

I think it's very important to be able to discuss kernel design (and 
such fundemntals) freely and critically, to understand them but also the 
philosophy behind them.
However changing something so fundamental just because of an 
(hypothetical) agreement on design elegance is not enough in my oppinion.

Thanks,
-- Richard