From: Greg KH <greg@kroah.com>
To: Richard <richard_siegfried@systemli.org>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: ktypes vs. devices classes (struct class)
Date: Sun, 1 Oct 2023 12:28:32 +0200 [thread overview]
Message-ID: <2023100159-tapered-fragment-7f9d@gregkh> (raw)
In-Reply-To: <2023100146-storm-unsmooth-d18c@gregkh>
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
next prev parent reply other threads:[~2023-10-01 10:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-30 0:12 ktypes vs. devices classes (struct class) Richard
2023-09-30 6:30 ` Greg KH
2023-09-30 18:17 ` Richard
2023-10-01 9:50 ` Greg KH
2023-10-01 10:28 ` Greg KH [this message]
2023-10-01 21:22 ` Richard
2023-10-01 21:15 ` Richard
2023-10-02 9:00 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023100159-tapered-fragment-7f9d@gregkh \
--to=greg@kroah.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=richard_siegfried@systemli.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox