lkml.org 
[lkml]   [2006]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Exporting array data in sysfs
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-09-18 17:59    [W:0.042 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site