On Fri, Jan 23, 2015 at 05:56:22PM +0100, Krzysztof Opasiak wrote: > > > > -----Original Message----- > > From: Felipe Balbi [mailto:balbi@xxxxxx] > > Sent: Friday, January 23, 2015 5:27 PM > > To: Krzysztof Opasiak > > Cc: balbi@xxxxxx; linux-usb@xxxxxxxxxxxxxxx; > > gregkh@xxxxxxxxxxxxxxxxxxx; bigeasy@xxxxxxxxxxxxx; > > s.wadas@xxxxxxxxxxx; k.lewandowsk@xxxxxxxxxxx; > > m.szyprowski@xxxxxxxxxxx; andrzej.p@xxxxxxxxxxx > > Subject: Re: [PATCH] usb: gadget: composite: Provide list of > > registered functions > > > > On Fri, Jan 23, 2015 at 05:09:07PM +0100, Krzysztof Opasiak wrote: > > > > > > > > > > -----Original Message----- > > > > From: Felipe Balbi [mailto:balbi@xxxxxx] > > > > Sent: Monday, January 19, 2015 7:59 PM > > > > To: Krzysztof Opasiak > > > > Cc: balbi@xxxxxx; linux-usb@xxxxxxxxxxxxxxx; > > > > gregkh@xxxxxxxxxxxxxxxxxxx; bigeasy@xxxxxxxxxxxxx; > > > > s.wadas@xxxxxxxxxxx; k.lewandowsk@xxxxxxxxxxx; > > > > m.szyprowski@xxxxxxxxxxx; andrzej.p@xxxxxxxxxxx > > > > Subject: Re: [PATCH] usb: gadget: composite: Provide list of > > > > registered functions > > > > > > > > On Mon, Jan 19, 2015 at 02:17:19PM +0100, Krzysztof Opasiak > > wrote: > > > > > Driver which provides implementation of some USB functions > > > > registers > > > > > usb_function_driver structure in composite framework. > > > > > Function drivers are identifed using registered name. > > > > > > > > > > When gadget is composed using configfs user must know what > > names > > > > has > > > > > been registered. If function is compiled as a module this > > > > information > > > > > can be found in modules.alias file. If function is compiled- > > in, > > > > there > > > > > is no way to discover what usb functions are available in > > > > currently > > > > > running kernel. > > > > > > > > > > Such situation is nothing new for linux kernel. > > > > > Similar situation is with file systems. While mounting user > > can > > > > > provide an fs type argument using -t option in mount. > > > > > Those type names are registered by drivers. To make those > > names > > > > > discoverable there is a /proc/filesystems which exports the > > list > > > > of > > > > > currently registered file systems. > > > > > > > > > > This patch adds /proc/usb-functions attribute which exports > > the > > > > list > > > > > of currently registered function drivers. > > > > > This allows user to discover list of both compiled-in > > functions > > > > and > > > > > from loaded kernel modules. > > > > > > > > > > Signed-off-by: Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx> > > > > > > > > you need to document the new file under Documentation/ABI/ > > > > > > > > > > I have just sent v2 version with documentation. > > > > > > I have done some more research and it looks like /sys/kernel > > could be > > > a good alternative if you find that proc usage is not a good > > idea. > > > What do you thing? Should we continue with /proc/usb-functions or > > > replace this patch with /sys/kernel/usb-functions or maybe > > > > why don't we place the file at the same directory as our configfs > > has been mounted ? > > Default place for mounting configfs is /sys/kernel/config. > It is created in init function of configfs module. For example > systemd mounts there configfs on system startup. > > So summing up, desired location should be /sys/kernel/usb-functions? shouldn't this be /sys/kernel/config/usb-functions ? in fact, thinking about absolute paths isn't really the best. I can decide to mount configfs anywhere. What we want is for the file to be available on the root directory of our usb-functions configfs interface :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
