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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
