> -----Original Message----- > From: Felipe Balbi [mailto:balbi@xxxxxx] > Sent: Friday, January 23, 2015 6:01 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: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 > :-) > So I must have misunderstood something. I'm not sure if this is a good idea. Some userspace depends on assumption that sys/kernel/config directory is empty and it's default place for mounting configfs. So why place there any attribute if we will mount there filesystem and we won't see it? I have prepared list of options related to your proposition: 1) Add a sysfs entry in config directory. This is easy but from userspace point of view It looks a little bit weird to place an attribute In "canonical" location for mounting some filesystem. Moreover config directory is maintained by configfs module and adding our subsystem specific file to this generic configfs location doesn't look good. 2) Add a file in configfs: 2a) In configfs root (next to usb-gadget subdir) I don't think that it is not a good idea. ConfigFS is generic filesystem and its root directory is reserved only for subsystem dirs. Adding there a file which is specific for only one of subsystems doesn't sound good to me. Moreover, as far as I know, it is currently impossible or at least requires changes in configfs. 2b) In usb-gadget directory There is usb-gadget subdirectory in configfs root. From technical point of view we could easily add There a file to expose the list of available functions. Technically yes but... There are some problems. First of all I'm not sure if it follows the main idea of userspace-driven nature of configfs. This file system should be used for managing objects in linux kernel rather than exporting information about kernel abilities. Next one is the usb-gadget ABI. I'm not sure if adding there a file won't be and ABI break. As described in Documentation/ABI/configfs-usb-gadget: What: /config/usb-gadget Date: Jun 2013 KernelVersion: 3.11 Description: This group contains sub-groups corresponding to created USB gadgets. So there is nothing about skipping any files by userspace tools. This means that there could be some userspace which depends on assumption that usb-gadget contains only gadget directories and nothing more. Just like it is described in ABI documentation. Summing up, in my opinion configfs is not a good place for exposing Kernel abilities and details about what is available inside. For such purpouse there are filesystems like procfs and sysfs. While procfs should be more related to process itself there is a lot of attributes which are related to current kernel state (list of registered file systems, list of loaded kernel modules etc). If we should follow the way how things has been done in history we should create /proc/usb-functions file. If extending procfs is prohibited we should consider placing this file somewhere in sysfs hierarchy. I don't have strong opinion where exactly it should be placed, but let's find quickly some reasonable location;) Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
