Hi,
I would like to put the contents of an array in sysfs files. I found no simple
way to do this, so here are my thoughts in hope someone can hand me a light.
-simple array (array of simple type like int, char* and so on)
needs:
.name, .read, .write, .num, .writenum
When exported a directory "name" is created, containing num()+1 entries. There
is one entry for each array entry plus the special entry "n". "cat n" gives
you the result of num, writing to num calls writenum to change the number of
array members. If writenum is NULL the array has fixed size.
read is read(struct whatever *, int, char *). The second argument gives the
array number, the last one the buffer to print to (as usual). write looks
similar, just as in existing sysfs interface (e.g. device_create_file()).
-complex array (array of struct)
This is even more tricky. You can't do this now if you don't know the number
of entries. If you do you can create a struct device_attribute (or similar)
for every entry and have different access functions that "know" their index.
This is horribly inefficient and ugly.
Sort of access struct could be:
.name is fmt-string containing %i (or %lli or something like this)
.members is an array of structs looking similar to what I described above for
the simple array. Now the index gives the index of the struct.
.num, .writenum as above
Nesting them is probably not worth it at all as it would look horrible. :)
Thoughts?
On Mon, Sep 18, 2006 at 01:59:17PM +0200, Rolf Eike Beer wrote:
> Hi,
>
> I would like to put the contents of an array in sysfs files. I found no simple
> way to do this, so here are my thoughts in hope someone can hand me a light.
What is wrong with using an attribute group for this kind of
information?
And do you have an example of a place in the kernel where this would be
necessary?
thanks,
greg k-h
Greg KH wrote:
> On Mon, Sep 18, 2006 at 01:59:17PM +0200, Rolf Eike Beer wrote:
> > Hi,
> >
> > I would like to put the contents of an array in sysfs files. I found no
> > simple way to do this, so here are my thoughts in hope someone can hand
> > me a light.
>
> What is wrong with using an attribute group for this kind of
> information?
Missing documentation. Yes, this looks like I could use this at least for the
simple interfaces (which would be enough).
Eike
On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> Greg KH wrote:
> > On Mon, Sep 18, 2006 at 01:59:17PM +0200, Rolf Eike Beer wrote:
> > > Hi,
> > >
> > > I would like to put the contents of an array in sysfs files. I found no
> > > simple way to do this, so here are my thoughts in hope someone can hand
> > > me a light.
> >
> > What is wrong with using an attribute group for this kind of
> > information?
>
> Missing documentation. Yes, this looks like I could use this at least for the
> simple interfaces (which would be enough).
>
I imoplemented sysfs arrays and array groups once:
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1155.html
Not sure if it still appliers. Maybe Greg will consider taking it in
if there is a user of this code.
--
Dmitry
Dmitry Torokhov wrote:
> On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> > Greg KH wrote:
> > > On Mon, Sep 18, 2006 at 01:59:17PM +0200, Rolf Eike Beer wrote:
> > > > Hi,
> > > >
> > > > I would like to put the contents of an array in sysfs files. I found
> > > > no simple way to do this, so here are my thoughts in hope someone can
> > > > hand me a light.
> > >
> > > What is wrong with using an attribute group for this kind of
> > > information?
> >
> > Missing documentation. Yes, this looks like I could use this at least for
> > the simple interfaces (which would be enough).
>
> I imoplemented sysfs arrays and array groups once:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1155.html
>
> Not sure if it still appliers. Maybe Greg will consider taking it in
> if there is a user of this code.
I guess we can add some once it is in :)
It looks good, but I would change some minor things. If there is no read
function given I would return -EIO instead of 0, this is how other places do
it. The limitation to 999 entries should go. But otherwise it looks very
similar to what I had in mind.
Thanks.
Eike
On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> Dmitry Torokhov wrote:
> > On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> > > Greg KH wrote:
> > > > On Mon, Sep 18, 2006 at 01:59:17PM +0200, Rolf Eike Beer wrote:
> > > > > Hi,
> > > > >
> > > > > I would like to put the contents of an array in sysfs files. I found
> > > > > no simple way to do this, so here are my thoughts in hope someone can
> > > > > hand me a light.
> > > >
> > > > What is wrong with using an attribute group for this kind of
> > > > information?
> > >
> > > Missing documentation. Yes, this looks like I could use this at least for
> > > the simple interfaces (which would be enough).
> >
> > I imoplemented sysfs arrays and array groups once:
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1155.html
> >
> > Not sure if it still appliers. Maybe Greg will consider taking it in
> > if there is a user of this code.
>
> I guess we can add some once it is in :)
>
> It looks good, but I would change some minor things. If there is no read
> function given I would return -EIO instead of 0, this is how other places do
> it.
Yes, the patch was done when everyone returned 0 instead of -EIO. Also
there is kmalloc->kzalloc conversion, etc.
> The limitation to 999 entries should go.
It is not really a limitation but rather a safeguard. Do you really
expect to have arrays with that many attributes?
> But otherwise it looks very
> similar to what I had in mind.
>
> Thanks.
>
> Eike
>
>
>
--
Dmitry
Dmitry Torokhov wrote:
> On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
>>Dmitry Torokhov wrote:
>>> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1155.html
>> The limitation to 999 entries should go.
>
> It is not really a limitation but rather a safeguard. Do you really
> expect to have arrays with that many attributes?
At least I don't know how much they will be. If the user wants to do crazy
things... :) I'm currently hacking on a store_n implementation, perhaps I'll
be able to show some code tomorrow.
Eike
On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> Dmitry Torokhov wrote:
> > On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> >>Dmitry Torokhov wrote:
>
> >>> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1155.html
>
> >> The limitation to 999 entries should go.
> >
> > It is not really a limitation but rather a safeguard. Do you really
> > expect to have arrays with that many attributes?
>
> At least I don't know how much they will be. If the user wants to do crazy
> things... :) I'm currently hacking on a store_n implementation, perhaps I'll
> be able to show some code tomorrow.
>
I do not think you shoudl allow user do crazy things. The memory is
kmalloced so there naturally a limit on number of attrinutes that can
be created. And I am not sure abot usefulness of resizing form
usespace.
Could you give me an example of a user who needs dynamic attribute arrays?
--
Dmitry
Am Montag, 18. September 2006 17:41 schrieb Dmitry Torokhov:
> On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> > Dmitry Torokhov wrote:
> > > On 9/18/06, Rolf Eike Beer <[email protected]> wrote:
> > >>Dmitry Torokhov wrote:
> > >>> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.2/1155.html
> > >>
> > >> The limitation to 999 entries should go.
> > >
> > > It is not really a limitation but rather a safeguard. Do you really
> > > expect to have arrays with that many attributes?
> >
> > At least I don't know how much they will be. If the user wants to do
> > crazy things... :) I'm currently hacking on a store_n implementation,
> > perhaps I'll be able to show some code tomorrow.
>
> I do not think you shoudl allow user do crazy things. The memory is
> kmalloced so there naturally a limit on number of attrinutes that can
> be created. And I am not sure abot usefulness of resizing form
> usespace.
> Could you give me an example of a user who needs dynamic attribute arrays?
FPGA device, number of buffers for DMA transfers. 1000 buffers should be
enough, but you'll never know what $user will do with his bigmem machine.
They will be able to resize anyway. If I don't get it done with 'n' it will
be an ioctl. For the moment it fails anyway since sysfs_get_dentry() got
removed.
This resizing stuff is purely optional. A 'n' giving me the number of entries
would at least help coding since you can easily find out how much space you
need for reading everything in the directory. Giving a dynamic n this is
racy, but that's another story.
Eike