syfs question

[Sadanand Warrier]

On Fri, 28 Feb 2020 at 07:37, Greg KH <greg at kroah.com> wrote:

> If you are using devices, then think about device parents, not kobject
> parents please.
I meant the device parent not kobject.


>
> > For e.g.
> > I create a device "xx" in
> > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/xx
>
> So this is a child of a pci device, ok.
>
> > cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/xx/dev
> > 243:0
>
> Ok, so you created this device with what call, to device_create*()
> passing in the dev_t value?

Actually device_register()
>
> > 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
>
> Note, cdev_* doesn't do anything in /dev/, that was done by the
> device_create* call.  cdev_* is there to handle things internally (and
> you should have done that call _before_ the call to device_create*()).

Again got things mixed up. The cdev_init/add was done before calling
device_register.
I just used the same devno and put that in dev->devt.

> Don't get 'struct device' confused with dev_t which is needed by cdev
> functions please.  They are totally different things, but do need to
> interact in some small ways in order for everything to show up properly
> in userspace.

Didn't quite follow what you meant about confusing the two because to me
they are distinct but is there something that I should avoid?

> Huh?  What attributes?  sysfs attributes can not be touched through a
> device node, that's a totally different interface.
Yes I wasn't talking about the device node but the actual sysfs entry.
>
> > Is that frowned upon? Is a virtual device considered necessary for user space
> >  access?
>
> No, but don't go hanging random character devices off of a PCI device
> for no good reason :)

I agree.
>
> Use the misc device interface if all you need is a simple char device
> node, that should handle all of the needed logic for you, and put things
> in the correct location.
>
> And please don't try to create new ioctls if at all possible, that's
> just mean to everyone involved :)

Oh this particular device is a beast and needs to be manipulated from user space
and there are only two options use sysfs attributes or ioctls. The
ioctl approach has been
voted the most desirable for certain reasons by those involved. :-)

Thanks a lot for the help.

S