> * 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. And I think that it's somehow where we are heading with configfs-configurable gadgets (which Andrzej has some work in progress code AFAIK). >> would that work ? > > Assume you get through with removal of module paramters. Do we end up > with two interfaces then? One for configfs and one for sysfs? If anyone cares about my opinion, I don't think that's a good idea. It will actually lead to three interfaces: new and shiny configfs, somehow new sysfs and deprecated and no longer supported module parameters. This will just add to confusion and user frustration. I think we should switch directly to configfs and provide some reasonable backward-compatibility via tiny modules which effectively load the configfs gadget and configure it simulating the old module parameter behaviour (and for some gadgets like those using f_mass_storage provide interfaces in sysfs if that is deemed feasible to maintain). -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz (o o) ooo +----<email/xmpp: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo--
Attachment:
pgpZylBZxCpD6.pgp
Description: PGP signature
