Re: ktypes vs. devices classes (struct class)

> 
> Close.
> 
> "struct class" represents how userspace interacts with a device (tty /
> input / block / etc.)
> 
> "struct kobj_type" is needed to describe what "type" of struct kobject a
> specific kobject is.  It defines a number of operations that handle the
> lifespan of the kobject.

Oki

> 
>> 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?
> 
> ktype is "lower" than classes.  ktype is not used for things in the
> driver model, it's used for things "lower" than the driver model (and to
> implement the driver model itself.)

Ahhh

> 
> So no driver should ever be messing with a ktype.  If you want to have a
> different "type" of device on the same bus or class, use "struct
> device_type" as that's what that is for.
> 
>> Is it possible that one device belongs to several classes?
> 
> No.
> 
>> 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?
> 
> groups are used to define attributes (i.e. sysfs files).  sysfs_ops is
> much "lower" in the stack.
> 
> I think the description of how the driver model works in the book, Linux
> Device Drivers, 3rd edition, free online, should still represent how
> things work on this layer pretty well, although we have changed things
> in places over time since the book was written.  Try looking that first.

I looked it up and my understanding is that those attributes are 
actually all embedded in instances of "struct class_attribute" and since 
they all bring their own store() and show() functions it's not necesarry 
to contain them in directly in "struct class". The whole mechanic with 
container_of() makes sure in the end the right "subroutine" gets called.

Is this correct?

> 
>>> 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.
> 
> Change is good if it is needed, that's how code evolves, based on new
> ideas and use cases.  So that's fine if needed.
> 
> hope this helps,

It does, thank you

-- Richard
> 
> greg k-h