Using binary attributes for configuration sysfs entries
Greg KH
greg at kroah.com
Thu Mar 14 10:57:49 EDT 2019
On Thu, Mar 14, 2019 at 04:17:13PM +0530, Jay Aurabind wrote:
> On Wed, 13 Mar 2019 at 19:55, Greg KH <greg at kroah.com> wrote:
> >
> > On Wed, Mar 13, 2019 at 12:02:02PM +0530, Jay Aurabind wrote:
> > > Hi,
> > >
> > > Before I send this patch to actual mailing list, I'd appreciate if
> > > someone could tell me if this is a bad idea!
> > >
> > > The driver in staging for pi433 (a wireless transceiver) uses IOCTLs
> > > at the moment. I wish to add a sysfs interface to it that control the
> > > various transmission and reception parameters. In the ioctl interface,
> > > it uses two structs that have about 40 parameters in total.
> > >
> > > For the corresponding sysfs interface, since there are a lot of
> > > parameters, would it be justified to use the same binary format though
> > > sysfs_create_binary_file() ? The rationale is that it would be easier
> > > to simply pack all the config options in the struct and send it in
> > > once rather than individually write 40 files. This is what the
> > > attached patch follows. Interface is added only for reception
> > > parameters as of now.
> >
> > binary sysfs files are only allowed for "pass through" data, where the
> > kernel does not touch the information at all and only passes it from the
> > hardware, to userspace directly (or the other way around). It can not
> > be used for data that the kernel actually knows about and modifies /
> > acts on.
> >
> > An example of valid binary sysfs files are USB and PCI device
> > configuration information (read directly from the hardware), or firmware
> > files that are send from userspace directly to the hardware without the
> > kernel knowing what the data is.
> >
> > You can't use a binary sysfs file for ioctl-like data, that's not
> > allowed, just use an ioctl for that. Or better yet, use a common api
> > interface for it, to match the other types of devices.
>
> Thank you for the explanation. What API would the most appropriate for
> such a wireless transceiver ? If I could make it as a networking
> driver, I could probably use setsockopt to pass in these
> configuration. Is this recommended ?
No, try looking at how v4l2 works, odds are they already have the
correct api for this type of device there for you to use.
thanks,
greg k-h
More information about the Kernelnewbies
mailing list