From: Jay Aurabind <jay.aurabind@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: Using binary attributes for configuration sysfs entries
Date: Thu, 14 Mar 2019 16:17:13 +0530 [thread overview]
Message-ID: <CAOsEZoi6iidke1Ussiz3rkjrXHQUaxH=H7rJ7g1Y1R_w8zCPnA@mail.gmail.com> (raw)
In-Reply-To: <20190313142529.GA5715@kroah.com>
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 ?
>
> hope this helps,
>
> greg k-h
--
Thanks and Regards,
Jay
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2019-03-14 10:48 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 [this message]
2019-03-14 14:57 ` Greg KH
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='CAOsEZoi6iidke1Ussiz3rkjrXHQUaxH=H7rJ7g1Y1R_w8zCPnA@mail.gmail.com' \
--to=jay.aurabind@gmail.com \
--cc=greg@kroah.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).