Re: Exporting array data in sysfs

[Rolf Eike Beer <eike-kernel@sf-tec.de>]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Am Montag, 18. September 2006 17:41 schrieb Dmitry Torokhov:
> On 9/18/06, Rolf Eike Beer <eike-kernel@sf-tec.de> wrote:
> > Dmitry Torokhov wrote:
> > > On 9/18/06, Rolf Eike Beer <eike-kernel@sf-tec.de> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]