From: Rolf Eike Beer <eike-kernel@sf-tec.de>
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: "Greg KH" <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: Exporting array data in sysfs
Date: Mon, 18 Sep 2006 17:57:25 +0200 [thread overview]
Message-ID: <200609181757.31043.eike-kernel@sf-tec.de> (raw)
In-Reply-To: <d120d5000609180841v436f7a32l78b26fc72f48f92a@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2006-09-18 15:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-18 11:59 Exporting array data in sysfs Rolf Eike Beer
2006-09-18 12:44 ` Greg KH
2006-09-18 13:41 ` Rolf Eike Beer
2006-09-18 13:56 ` Dmitry Torokhov
2006-09-18 14:22 ` Rolf Eike Beer
2006-09-18 14:59 ` Dmitry Torokhov
2006-09-18 15:18 ` Rolf Eike Beer
2006-09-18 15:41 ` Dmitry Torokhov
2006-09-18 15:57 ` Rolf Eike Beer [this message]
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=200609181757.31043.eike-kernel@sf-tec.de \
--to=eike-kernel@sf-tec.de \
--cc=dmitry.torokhov@gmail.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.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