On Wed, 26 Feb 2020 at 12:54, Greg KH <greg@xxxxxxxxx> 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 parent's directory. 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 ./class/net/eth1 ./devices/pci0000:00/0000:00:02.2/0000:03:00.3/net/eth1 > > > 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. For e.g. I create a device "xx" in /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/xx cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/xx/dev 243:0 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 access? > 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 > driver. > > 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. Thanks S _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
