From: Greg KH <greg@kroah.com>
To: Jay Aurabind <jay.aurabind@gmail.com>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: Using binary attributes for configuration sysfs entries
Date: Thu, 14 Mar 2019 07:57:49 -0700 [thread overview]
Message-ID: <20190314145749.GB12576@kroah.com> (raw)
In-Reply-To: <CAOsEZoi6iidke1Ussiz3rkjrXHQUaxH=H7rJ7g1Y1R_w8zCPnA@mail.gmail.com>
On Thu, Mar 14, 2019 at 04:17:13PM +0530, Jay Aurabind wrote:
> On Wed, 13 Mar 2019 at 19:55, Greg KH <greg@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
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2019-03-14 14:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 6:32 Using binary attributes for configuration sysfs entries Jay Aurabind
2019-03-13 6:56 ` valdis.kletnieks
2019-03-13 9:08 ` Jay Aurabind
2019-03-13 14:25 ` Greg KH
2019-03-14 10:47 ` Jay Aurabind
2019-03-14 14:57 ` Greg KH [this message]
2019-03-14 17:41 ` Jay Aurabind
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190314145749.GB12576@kroah.com \
--to=greg@kroah.com \
--cc=jay.aurabind@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.