Re: [systemd-devel] udev_device_get_driver implementation
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Apr 24, 2019 at 11:58:08AM -0700, Sayeed hyder wrote: > ll > /sys/devices/LNXSYSTM:00/device:00/ACPI0012:00/ndbus0/region1/pfn1.1/block/pmem1/ > total 0 > -r--r--r-- 1 root root 4096 Apr 19 09:38 alignment_offset > -rw-r--r-- 1 root root 4096 Apr 19 09:38 badblocks > lrwxrwxrwx 1 root root0 Apr 19 09:38 bdi -> > ../../../../../../../../virtual/bdi/259:3 > -r--r--r-- 1 root root 4096 Apr 19 09:38 capability > drwxr-xr-x 2 root root0 Apr 19 09:38 dax > -r--r--r-- 1 root root 4096 Apr 19 09:38 dev > lrwxrwxrwx 1 root root0 Apr 19 09:38 device -> ../../../pfn1.1 > -r--r--r-- 1 root root 4096 Apr 19 09:38 discard_alignment > -r--r--r-- 1 root root 4096 Apr 19 09:38 ext_range > drwxr-xr-x 2 root root0 Apr 19 09:38 holders > -r--r--r-- 1 root root 4096 Apr 19 09:38 inflight > drwxr-xr-x 2 root root0 Apr 19 09:38 power > drwxr-xr-x 2 root root0 Apr 19 09:38 queue > -r--r--r-- 1 root root 4096 Apr 19 09:38 range > -r--r--r-- 1 root root 4096 Apr 19 09:38 removable > -r--r--r-- 1 root root 4096 Apr 19 09:38 ro > -r--r--r-- 1 root root 4096 Apr 19 09:38 size > drwxr-xr-x 2 root root0 Apr 19 09:38 slaves > -r--r--r-- 1 root root 4096 Apr 19 09:38 stat > lrwxrwxrwx 1 root root0 Apr 19 09:38 subsystem -> > ../../../../../../../../../class/block > drwxr-xr-x 2 root root0 Apr 19 09:38 trace > -rw-r--r-- 1 root root 4096 Apr 19 09:38 uevent As suspected, that is a class device (it is a block device), and a class device does not have a direct "driver" bound to it. If you want to find the "real" driver for the device, go to 'device' and find it, right? Ah, but this might be a mess, with a child device. DAX stuff is odd, I would recommend going and asking those kernel developers what they were thinking when they added a sub-device here :( good luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev_device_get_driver implementation
ll /sys/devices/LNXSYSTM:00/device:00/ACPI0012:00/ndbus0/region1/pfn1.1/block/pmem1/ total 0 -r--r--r-- 1 root root 4096 Apr 19 09:38 alignment_offset -rw-r--r-- 1 root root 4096 Apr 19 09:38 badblocks lrwxrwxrwx 1 root root0 Apr 19 09:38 bdi -> ../../../../../../../../virtual/bdi/259:3 -r--r--r-- 1 root root 4096 Apr 19 09:38 capability drwxr-xr-x 2 root root0 Apr 19 09:38 dax -r--r--r-- 1 root root 4096 Apr 19 09:38 dev lrwxrwxrwx 1 root root0 Apr 19 09:38 device -> ../../../pfn1.1 -r--r--r-- 1 root root 4096 Apr 19 09:38 discard_alignment -r--r--r-- 1 root root 4096 Apr 19 09:38 ext_range drwxr-xr-x 2 root root0 Apr 19 09:38 holders -r--r--r-- 1 root root 4096 Apr 19 09:38 inflight drwxr-xr-x 2 root root0 Apr 19 09:38 power drwxr-xr-x 2 root root0 Apr 19 09:38 queue -r--r--r-- 1 root root 4096 Apr 19 09:38 range -r--r--r-- 1 root root 4096 Apr 19 09:38 removable -r--r--r-- 1 root root 4096 Apr 19 09:38 ro -r--r--r-- 1 root root 4096 Apr 19 09:38 size drwxr-xr-x 2 root root0 Apr 19 09:38 slaves -r--r--r-- 1 root root 4096 Apr 19 09:38 stat lrwxrwxrwx 1 root root0 Apr 19 09:38 subsystem -> ../../../../../../../../../class/block drwxr-xr-x 2 root root0 Apr 19 09:38 trace -rw-r--r-- 1 root root 4096 Apr 19 09:38 uevent On Wed, Apr 24, 2019 at 11:53 AM Greg KH wrote: > On Wed, Apr 24, 2019 at 10:10:08AM -0700, Sayeed hyder wrote: > > Forgot to hit "reply all" > > > > On Wed, Apr 24, 2019 at 9:52 AM Sayeed hyder wrote: > > > > > Hi Greg, > > > > > > Sure, this is what I get if I use the syspath from > > > udev_device_get_syspath. As you can see, it is showing a symlink to a > > > device, and there is no driver. If it helps, it is a DAX mounted > persistent > > > memory device. > > > > > > [image: image.png] > > Sorry, can't see images from a text email client :( > > Anyway, if this is a DAX device, are you _SURE_ you are dealing with a > real device that is controlled by a driver, and not just a class device? > Class devices do not have drivers. How is the DAX device being exposed > to userspace? > > Can you provide a text version of your image? It's just sysfs, which is > text... > > thanks, > > greg k-h > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev_device_get_driver implementation
On Wed, Apr 24, 2019 at 10:10:08AM -0700, Sayeed hyder wrote: > Forgot to hit "reply all" > > On Wed, Apr 24, 2019 at 9:52 AM Sayeed hyder wrote: > > > Hi Greg, > > > > Sure, this is what I get if I use the syspath from > > udev_device_get_syspath. As you can see, it is showing a symlink to a > > device, and there is no driver. If it helps, it is a DAX mounted persistent > > memory device. > > > > [image: image.png] Sorry, can't see images from a text email client :( Anyway, if this is a DAX device, are you _SURE_ you are dealing with a real device that is controlled by a driver, and not just a class device? Class devices do not have drivers. How is the DAX device being exposed to userspace? Can you provide a text version of your image? It's just sysfs, which is text... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev_device_get_driver implementation
Forgot to hit "reply all" On Wed, Apr 24, 2019 at 9:52 AM Sayeed hyder wrote: > Hi Greg, > > Sure, this is what I get if I use the syspath from > udev_device_get_syspath. As you can see, it is showing a symlink to a > device, and there is no driver. If it helps, it is a DAX mounted persistent > memory device. > > [image: image.png] > > Thanks, > > On Wed, Apr 24, 2019 at 9:38 AM Greg KH > wrote: > >> On Wed, Apr 24, 2019 at 08:38:02AM -0700, Sayeed hyder wrote: >> > Hi, >> > >> > I was looking at the udev_device_get_driver implementation. It first >> gets >> > the sys path and then appends "driver", and calls readlink to get the >> > driver information. Does it work for all cases? While working on a >> project, >> > I found that following the sys path, there is no "driver", but it >> should be >> > "device/driver" i.e. if I append "device/driver" instead of "driver" >> only, >> > I can use readlink to get the driver information. >> >> What in-kernel driver causes an odd sysfs tree like this? Can you show >> me the full path of it? >> >> thanks, >> >> greg k-h >> > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev_device_get_driver implementation
On Wed, Apr 24, 2019 at 08:38:02AM -0700, Sayeed hyder wrote: > Hi, > > I was looking at the udev_device_get_driver implementation. It first gets > the sys path and then appends "driver", and calls readlink to get the > driver information. Does it work for all cases? While working on a project, > I found that following the sys path, there is no "driver", but it should be > "device/driver" i.e. if I append "device/driver" instead of "driver" only, > I can use readlink to get the driver information. What in-kernel driver causes an odd sysfs tree like this? Can you show me the full path of it? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udev_device_get_driver implementation
Hi, I was looking at the udev_device_get_driver implementation. It first gets the sys path and then appends "driver", and calls readlink to get the driver information. Does it work for all cases? While working on a project, I found that following the sys path, there is no "driver", but it should be "device/driver" i.e. if I append "device/driver" instead of "driver" only, I can use readlink to get the driver information. Can anybody explain whether this was missing in the implementation or am I missing something? thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
