sadanandwarrier at gmail.com
Thu Feb 27 09:41:21 EST 2020
On Wed, 26 Feb 2020 at 12:54, Greg KH <greg at kroah.com> wrote:
> > Using device_add I could populate the parent of the device and leave
> > the class empty or provide a class and get the device to be created in
> > the parent directory.
> I don't understand what you mean here.
Umm sorry was a bit dense there what I meant to say was that if the
device kobj was set up to point to the parent it would appear in that
Additionally if the link to the parent was there and it also belonged
to a class it would
appear under the class directory in the parent hierarchy. Like so for
an ethernet interface
belonging to the class "net" if I am in the sys directory.
-bash-4.2$ find . -name "eth*" -print
> > What exactly is the significance of the" /sys/devices/virtual" directory?
> > Is this meant to carry devices of a specific type say something that is
> > divorced from actual hardware?
> Yes. These are devices that do not have a "real" device backing them,
> they are "virtual" devices in that the kernel creates them usually
> because it needs a way for userspace to interact with the device.
> A good example of this are tty "devices". They are attached to a "real"
> device in the system (pci, usb, platform, etc.) but the tty device
> itself is just there to provide the common interaction with userspace
> that userspace expects.
So would it be considered indecent to create a device under a parent directory
with a specific value of devno which we place in dev->devt value and then
create a character device with cdev_init/add and the same devno so
that the user
can access ioctl operations through the entry in /dev.
I create a device "xx" in
and set up a character device xx like this using cdev_add/init
crw-------. 1 root root 243, 0 Jun 22 07:52 /dev/xx
In this case there is no device under /sys/devices/virtual but I could
open "/dev/xx" from user space and do ioctls etc. Of course I would be
limited to accessing sysfs attributes etc. through the real hardware device.
Is that frowned upon? Is a virtual device considered necessary for user space
> The uevent file is not written to (well, it can, but that does something
> different), it is read from to show what the attributes that are set
> when the uevent happens for that device. It is populated by the
> bus or class for that device by a bus/class specific callback to that
> Have you read the LDD3 chapter on the driver model for the kernel? It's
> a bit out of date (well, really out of date), but the basics should
> still be semi-relevant and might answer some of your questions here.
> hope this helps,
Not in detail and I will do so but you have answered my question I
think. I'll check
the newer kernel code to see how the bus/class specific callback works.
More information about the Kernelnewbies