Messages in this thread | | | From | Rolf Eike Beer <> | Subject | Re: Exporting array data in sysfs | Date | Mon, 18 Sep 2006 17:57:25 +0200 |
| |
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] | |