Hi, On Mon, Dec 03, 2012 at 12:34:44PM +0100, Sebastian Andrzej Siewior wrote: > On Fri, Nov 30, 2012 at 04:51:16PM +0200, Felipe Balbi wrote: > > On Tue, Nov 20, 2012 at 11:53:02PM +0100, Michal Nazarewicz wrote: > > > > * Felipe Balbi | 2012-11-20 14:14:47 [+0200]: > > > >> now this looks awfully wrong. Why don't you just expose the modules to > > > >> userland (in fact they already are) and if user wants to change > > > >> something it needs to do it via sysfs before enabling the function ? > > > > > > On Tue, Nov 20 2012, Sebastian Andrzej Siewior wrote: > > > > This isn't that easy. buflen & qlen here are used for memory allocation. > > > > A change here would require to purge all usb_requests and re-allocate > > > > them. > > > > > > I think that what Felipe means is to let user set the values in sysfs > > > before the function is enabled. Once the function is added to some > > > gadget, the values become read only. > > > > spot on. > > Okay, just make this crystel clear: > You want a sysfs interface to set _all_ parameters and not use the function I > introduced here. yeah, except that it already exists: /sys/module/$module/$parameter > If so: > - what will happen with backwards compatibility of the module interface? > Since the bare function has no module parameters any more, the parameters > which are offered by g_zero have no meaning anymore. they do, you can still change them via the path above. > - does this apply to _all_ modules/gadgets or just this one? yes, all of them > - what will happen once configfs shows up? Do we have two interfaces then? > If we are going to ditch the sysfs interface and the modprobe interface then > the user will user the use the modprobe interface for kernels a…b, sysfs > interface for kernels c…d and configfs for kernels e…f where the version > (a-f) may overlap. This does not look very friendly. no no, the sysfs module parameter interface has been there for ages ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
