ktypes vs. devices classes (struct class)

ktypes vs. devices classes (struct class)

[Richard]

Hi all,

Why do we have ktypes (struct kobj_type) AND device classes (struct class)?

Don't they serve the same purpose (more or less) and it would be 
simpler, clearer and more KISS to only have one? Is this a historically 
grown thing or by design?

Thanks,
-- Richard

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sat, Sep 30, 2023 at 02:12:41AM +0200, Richard wrote:
> Hi all,
> 
> Why do we have ktypes (struct kobj_type) AND device classes (struct class)?

Because they are two totally different things.

> Don't they serve the same purpose (more or less) and it would be simpler,
> clearer and more KISS to only have one? Is this a historically grown thing
> or by design?

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?

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!

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: 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

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sat, Sep 30, 2023 at 08:17:26PM +0200, Richard wrote:
> 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.

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.

> 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.)

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.

> > 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,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sun, Oct 01, 2023 at 11:50:46AM +0200, Greg KH wrote:
> On Sat, Sep 30, 2023 at 08:17:26PM +0200, Richard wrote:
> > 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.
> 
> 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.
> 
> > 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.)
> 
> 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.

Oops, well yes.  Depends on what you are thinking is a "device" here.

In the kernel, yes, a 'struct device' on a bus can then register itself
with multiple subsystems that handle different classes, and then
individual 'struct device' are created for those classes that have a
parent of the original 'struct device' on the bus.

But within a 'struct class', there can only be one "struct device" for
that class for that specific class type (we used to call them "struct
class_device" but that got removed a long time ago as the objects really
all did the same thing.)

It's a bit confusing, yes, sorry, but creating a unified object model of
all devices in the system turns out to be complex due to the huge range
of devices that an operating system needs to manage, which is probably
why most other operating systems have never attempted to do such a
thing.

When Pat and I created it, we were young and naive and thought "this
should be simple!"  Famous last words...

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ktypes vs. devices classes (struct class)

[Richard]

>>
>>> Is it possible that one device belongs to several classes?
>>
>> No.
> 
> Oops, well yes.  Depends on what you are thinking is a "device" here.
> 
> In the kernel, yes, a 'struct device' on a bus can then register itself
> with multiple subsystems that handle different classes, and then
> individual 'struct device' are created for those classes that have a
> parent of the original 'struct device' on the bus.
> 
> But within a 'struct class', there can only be one "struct device" for
> that class for that specific class type (we used to call them "struct
> class_device" but that got removed a long time ago as the objects really
> all did the same thing.)

Oki, thanks for explaining

> 
> It's a bit confusing, yes, sorry, but creating a unified object model of
> all devices in the system turns out to be complex due to the huge range
> of devices that an operating system needs to manage, which is probably
> why most other operating systems have never attempted to do such a
> thing.

 From what I've heard Windows has tried the same with WDF but it's so 
abstract and elegant it only plays with the "nice" devices so only 
around 50%, for all other devices you still need the old device model. 
So in the end every driver developer has to learn both models :D

> 
> When Pat and I created it, we were young and naive and thought "this
> should be simple!"  Famous last words...

:D

> 
> thanks,
> 
> greg k-h

Thank you!,
Richard

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ktypes vs. devices classes (struct class)

[Richard]

> 
> 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@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: ktypes vs. devices classes (struct class)

[Greg KH]

On Sun, Oct 01, 2023 at 11:15:12PM +0200, Richard wrote:
> > > 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?

Close enough, yes :)

The "fun" with attributes and sysfs files is a very tricky one, relying
entirely on the location of the callbacks in memory to match up properly
with some other structures and to pass around pointers like crazy.  It
has played havoc on some tools like CFI and will be very "interesting"
to see how it every works in languages other than C (i.e. rust.)

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies