[PATCH] usb: gadget: composite: Provide a list of available functions

[Andrzej Pietrasiewicz]

When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.

This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p-***@public.gmane.org>
---
drivers/usb/gadget/configfs.c | 24 ++++++++++++++++++++++++
drivers/usb/gadget/functions.c | 19 +++++++++++++++++++
drivers/usb/gadget/u_f.h | 2 ++
3 files changed, 45 insertions(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..352571b 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,36 @@ void unregister_gadget_item(struct config_item *item)
}
EXPORT_SYMBOL_GPL(unregister_gadget_item);

+static ssize_t sysfs_func_list_show(struct module_attribute *ma,
+ struct module_kobject *ko, char *buf)
+{
+ return usb_function_list_functions(buf, PAGE_SIZE);
+}
+
+static struct module_attribute sysfs_func_list = {
+ .attr = {
+ .name = "func_list",
+ .mode = S_IRUGO,
+ },
+ .show = sysfs_func_list_show,
+};
+
static int __init gadget_cfs_init(void)
{
int ret;

config_group_init(&gadget_subsys.su_group);

+ ret = sysfs_create_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);
+ if (ret)
+ return ret;
+
ret = configfs_register_subsystem(&gadget_subsys);
+ if (ret)
+ sysfs_remove_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);
+
return ret;
}
module_init(gadget_cfs_init);
@@ -1567,5 +1590,6 @@ module_init(gadget_cfs_init);
static void __exit gadget_cfs_exit(void)
{
configfs_unregister_subsystem(&gadget_subsys);
+ sysfs_remove_file(&THIS_MODULE->mkobj.kobj, &sysfs_func_list.attr);
}
module_exit(gadget_cfs_exit);
diff --git a/drivers/usb/gadget/functions.c b/drivers/usb/gadget/functions.c
index b13f839..46b2f60 100644
--- a/drivers/usb/gadget/functions.c
+++ b/drivers/usb/gadget/functions.c
@@ -114,3 +114,22 @@ void usb_function_unregister(struct usb_function_driver *fd)
mutex_unlock(&func_lock);
}
EXPORT_SYMBOL_GPL(usb_function_unregister);
+
+size_t usb_function_list_functions(char *buf, size_t len)
+{
+ struct usb_function_driver *fd;
+ char *_buf = buf;
+
+ mutex_lock(&func_lock);
+ list_for_each_entry(fd, &func_list, list) {
+ sprintf(_buf, "%s\n", fd->name);
+ _buf += strlen(fd->name) + 1;
+ if (_buf - buf > len) {
+ mutex_unlock(&func_lock);
+ return -ENOMEM;
+ }
+ }
+ mutex_unlock(&func_lock);
+
+ return _buf - buf;
+}
diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
index 1d5f0eb..f1a8dff 100644
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,6 +47,8 @@ struct usb_request;

struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);

+size_t usb_function_list_functions(char *buf, size_t len);
+
#endif /* __U_F_H__ */

[Andrzej Pietrasiewicz]

Please disregard this patch.

It contains a bug: function names are copied to the destination buffer first,
and only after that the buffer overrun check is performed, which effectively
means that in the pessimistic scenario the buffer overflow happens first,
and then it is detected. Should be the other way round.
I will post a corrected version soon.

AP

Post by Andrzej Pietrasiewicz
When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.
This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.
---
drivers/usb/gadget/configfs.c | 24 ++++++++++++++++++++++++
drivers/usb/gadget/functions.c | 19 +++++++++++++++++++
drivers/usb/gadget/u_f.h | 2 ++
3 files changed, 45 insertions(+)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..352571b 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,36 @@ void unregister_gadget_item(struct config_item *item)
}
EXPORT_SYMBOL_GPL(unregister_gadget_item);
+static ssize_t sysfs_func_list_show(struct module_attribute *ma,
+ struct module_kobject *ko, char *buf)
+{
+ return usb_function_list_functions(buf, PAGE_SIZE);
+}
+
+static struct module_attribute sysfs_func_list = {
+ .attr = {
+ .name = "func_list",
+ .mode = S_IRUGO,
+ },
+ .show = sysfs_func_list_show,
+};
+
static int __init gadget_cfs_init(void)
{
int ret;
config_group_init(&gadget_subsys.su_group);
+ ret = sysfs_create_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);
+ if (ret)
+ return ret;
+
ret = configfs_register_subsystem(&gadget_subsys);
+ if (ret)
+ sysfs_remove_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);
+
return ret;
}
module_init(gadget_cfs_init);
@@ -1567,5 +1590,6 @@ module_init(gadget_cfs_init);
static void __exit gadget_cfs_exit(void)
{
configfs_unregister_subsystem(&gadget_subsys);
+ sysfs_remove_file(&THIS_MODULE->mkobj.kobj, &sysfs_func_list.attr);
}
module_exit(gadget_cfs_exit);
diff --git a/drivers/usb/gadget/functions.c b/drivers/usb/gadget/functions.c
index b13f839..46b2f60 100644
--- a/drivers/usb/gadget/functions.c
+++ b/drivers/usb/gadget/functions.c
@@ -114,3 +114,22 @@ void usb_function_unregister(struct usb_function_driver *fd)
mutex_unlock(&func_lock);
}
EXPORT_SYMBOL_GPL(usb_function_unregister);
+
+size_t usb_function_list_functions(char *buf, size_t len)
+{
+ struct usb_function_driver *fd;
+ char *_buf = buf;
+
+ mutex_lock(&func_lock);
+ list_for_each_entry(fd, &func_list, list) {
+ sprintf(_buf, "%s\n", fd->name);
+ _buf += strlen(fd->name) + 1;
+ if (_buf - buf > len) {
+ mutex_unlock(&func_lock);
+ return -ENOMEM;
+ }
+ }
+ mutex_unlock(&func_lock);
+
+ return _buf - buf;
+}
diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
index 1d5f0eb..f1a8dff 100644
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,6 +47,8 @@ struct usb_request;
struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);
+size_t usb_function_list_functions(char *buf, size_t len);
+
#endif /* __U_F_H__ */

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrzej Pietrasiewicz]

When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.

This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p-***@public.gmane.org>
---
This time snprintf is used and its return value is examined.
snprintf is used because we want function names to appear
on separate lines, so it is convenient to specify a format string.

drivers/usb/gadget/configfs.c | 24 ++++++++++++++++++++++++
drivers/usb/gadget/functions.c | 25 +++++++++++++++++++++++++
drivers/usb/gadget/u_f.h | 2 ++
3 files changed, 51 insertions(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..352571b 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,36 @@ void unregister_gadget_item(struct config_item *item)
}
EXPORT_SYMBOL_GPL(unregister_gadget_item);

+static ssize_t sysfs_func_list_show(struct module_attribute *ma,
+ struct module_kobject *ko, char *buf)
+{
+ return usb_function_list_functions(buf, PAGE_SIZE);
+}
+
+static struct module_attribute sysfs_func_list = {
+ .attr = {
+ .name = "func_list",
+ .mode = S_IRUGO,
+ },
+ .show = sysfs_func_list_show,
+};
+
static int __init gadget_cfs_init(void)
{
int ret;

config_group_init(&gadget_subsys.su_group);

+ ret = sysfs_create_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);
+ if (ret)
+ return ret;
+
ret = configfs_register_subsystem(&gadget_subsys);
+ if (ret)
+ sysfs_remove_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);
+
return ret;
}
module_init(gadget_cfs_init);
@@ -1567,5 +1590,6 @@ module_init(gadget_cfs_init);
static void __exit gadget_cfs_exit(void)
{
configfs_unregister_subsystem(&gadget_subsys);
+ sysfs_remove_file(&THIS_MODULE->mkobj.kobj, &sysfs_func_list.attr);
}
module_exit(gadget_cfs_exit);
diff --git a/drivers/usb/gadget/functions.c b/drivers/usb/gadget/functions.c
index b13f839..fc43c1c 100644
--- a/drivers/usb/gadget/functions.c
+++ b/drivers/usb/gadget/functions.c
@@ -114,3 +114,28 @@ void usb_function_unregister(struct usb_function_driver *fd)
mutex_unlock(&func_lock);
}
EXPORT_SYMBOL_GPL(usb_function_unregister);
+
+/*
+ * Returns number of characters written excluding the terminating '\0',
+ * if written.
+ */
+size_t usb_function_list_functions(char *buf, size_t len)
+{
+ struct usb_function_driver *fd;
+ char *_buf = buf;
+ size_t n;
+
+ mutex_lock(&func_lock);
+ list_for_each_entry(fd, &func_list, list) {
+ n = snprintf(_buf, len, "%s\n", fd->name);
+ if (n >= len) {
+ mutex_unlock(&func_lock);
+ return -ENOMEM;
+ }
+ _buf += n;
+ len -= n;
+ }
+ mutex_unlock(&func_lock);
+
+ return _buf - buf;
+}
diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
index 1d5f0eb..f1a8dff 100644
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,6 +47,8 @@ struct usb_request;

struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);

+size_t usb_function_list_functions(char *buf, size_t len);
+
#endif /* __U_F_H__ */

[Andrzej Pietrasiewicz]

Hello All,

Uhm, errr.... please disregard this patch as well.
I still get it wrong.

Post by Andrzej Pietrasiewicz
When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.
This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.
---

<snip>

Post by Andrzej Pietrasiewicz
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..352571b 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,36 @@ void unregister_gadget_item(struct config_item *item)
}

<snip>

Post by Andrzej Pietrasiewicz
static int __init gadget_cfs_init(void)
{
int ret;
config_group_init(&gadget_subsys.su_group);
+ ret = sysfs_create_file(&THIS_MODULE->mkobj.kobj,
+ &sysfs_func_list.attr);

THIS_MODULE is NULL if compiled-in.

AP
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrzej Pietrasiewicz]

When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.

This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.

Signed-off-by: Andrzej Pietrasiewicz <andrzej.p-***@public.gmane.org>
---
This time there should be no obvious mistakes: potential
buffer overrun is checked and THIS_MODULE is not dereferenced at all.
Tested with libcomposite compiled-in and modular.

v1..v2:
- changed the location in sysfs: usb_gadget class is added

drivers/usb/gadget/configfs.c | 25 +++++++++++++++++++++++++
drivers/usb/gadget/functions.c | 25 +++++++++++++++++++++++++
drivers/usb/gadget/u_f.h | 2 ++
3 files changed, 52 insertions(+)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..358242a 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,37 @@ void unregister_gadget_item(struct config_item *item)
}
EXPORT_SYMBOL_GPL(unregister_gadget_item);

+static ssize_t gadget_func_list_show(struct class *c,
+ struct class_attribute *a, char *buf)
+{
+ return usb_function_list_functions(buf, PAGE_SIZE);
+}
+
+static struct class_attribute usb_gadget_attrs[] = {
+ __ATTR(func_list, S_IRUGO, gadget_func_list_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct class usb_gadget_class = {
+ .name = "usb_gadget",
+ .owner = THIS_MODULE,
+ .class_attrs = usb_gadget_attrs,
+};
+
static int __init gadget_cfs_init(void)
{
int ret;

config_group_init(&gadget_subsys.su_group);

+ ret = class_register(&usb_gadget_class);
+ if (ret)
+ return ret;
+
ret = configfs_register_subsystem(&gadget_subsys);
+ if (ret)
+ class_unregister(&usb_gadget_class);
+
return ret;
}
module_init(gadget_cfs_init);
@@ -1567,5 +1591,6 @@ module_init(gadget_cfs_init);
static void __exit gadget_cfs_exit(void)
{
configfs_unregister_subsystem(&gadget_subsys);
+ class_unregister(&usb_gadget_class);
}
module_exit(gadget_cfs_exit);
diff --git a/drivers/usb/gadget/functions.c b/drivers/usb/gadget/functions.c
index b13f839..fc43c1c 100644
--- a/drivers/usb/gadget/functions.c
+++ b/drivers/usb/gadget/functions.c
@@ -114,3 +114,28 @@ void usb_function_unregister(struct usb_function_driver *fd)
mutex_unlock(&func_lock);
}
EXPORT_SYMBOL_GPL(usb_function_unregister);
+
+/*
+ * Returns number of characters written excluding the terminating '\0',
+ * if written.
+ */
+size_t usb_function_list_functions(char *buf, size_t len)
+{
+ struct usb_function_driver *fd;
+ char *_buf = buf;
+ size_t n;
+
+ mutex_lock(&func_lock);
+ list_for_each_entry(fd, &func_list, list) {
+ n = snprintf(_buf, len, "%s\n", fd->name);
+ if (n >= len) {
+ mutex_unlock(&func_lock);
+ return -ENOMEM;
+ }
+ _buf += n;
+ len -= n;
+ }
+ mutex_unlock(&func_lock);
+
+ return _buf - buf;
+}
diff --git a/drivers/usb/gadget/u_f.h b/drivers/usb/gadget/u_f.h
index 1d5f0eb..f1a8dff 100644
--- a/drivers/usb/gadget/u_f.h
+++ b/drivers/usb/gadget/u_f.h
@@ -47,6 +47,8 @@ struct usb_request;

struct usb_request *alloc_ep_req(struct usb_ep *ep, int len, int default_len);

+size_t usb_function_list_functions(char *buf, size_t len);
+
#endif /* __U_F_H__ */

[Felipe Balbi]

Post by Andrzej Pietrasiewicz
When gadgets are composed with configfs the user must know what are the
available function names. The names are parts of usb_f_*.ko
modules' aliases. If a function is compiled as a module, the information
can be found in modules.alias file. But if a function is compiled-in,
there is no way to know the function's name.
This patch adds a sysfs attribute in libcomposite's sys directory to
show functions which are already registered. Functions which are
compiled-in will be in this list as well.
---
This time there should be no obvious mistakes: potential
buffer overrun is checked and THIS_MODULE is not dereferenced at all.
Tested with libcomposite compiled-in and modular.
- changed the location in sysfs: usb_gadget class is added
drivers/usb/gadget/configfs.c | 25 +++++++++++++++++++++++++
drivers/usb/gadget/functions.c | 25 +++++++++++++++++++++++++
drivers/usb/gadget/u_f.h | 2 ++
3 files changed, 52 insertions(+)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index bcc2a62..358242a 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1553,13 +1553,37 @@ void unregister_gadget_item(struct config_item *item)
}
EXPORT_SYMBOL_GPL(unregister_gadget_item);
+static ssize_t gadget_func_list_show(struct class *c,
+ struct class_attribute *a, char *buf)
+{
+ return usb_function_list_functions(buf, PAGE_SIZE);
+}
+
+static struct class_attribute usb_gadget_attrs[] = {
+ __ATTR(func_list, S_IRUGO, gadget_func_list_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct class usb_gadget_class = {

another class ? Please don't, we already have the udc class, we could
find a way to just use that instead.

[Krzysztof Opasiak]

-----Original Message-----
Sent: Thursday, July 10, 2014 3:39 PM
To: Andrzej Pietrasiewicz
Sebastian Andrzej Siewior; Marek Szyprowski
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions

(...)

Post by Andrzej Pietrasiewicz
+static ssize_t gadget_func_list_show(struct class *c,
+ struct class_attribute *a, char

*buf)

{

Post by Andrzej Pietrasiewicz
+ return usb_function_list_functions(buf, PAGE_SIZE); }
+
+static struct class_attribute usb_gadget_attrs[] = {
+ __ATTR(func_list, S_IRUGO, gadget_func_list_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct class usb_gadget_class = {

another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.

Using udc clas is not a good idea. This may cause failures in userspace.
How would you like to tell that this is not really a udc? Only type of
file will be different than for the udcs (udcs are symlink and this
would be normal file or directory). But who knows how much scripts or
soft depends on assumption that /sys/class/udc contains only names of
udc available in system?

Libusbg is good example. When you pass NULL as udc name to
usbg_enable_gadget() method, it scandir() the /sys/class/udc and take
the first entry of this directory. If we add something what is not an
udc this library and potentially many other userspace apps behavior will
be changed and they may suddenly fail.

I know that this solution has some disadvantages but I don't see any
better one which wont destroy the userspace. Maybe you have some idea?
Please share it with us:) Please let me also recall v1 version of this
patch which has been changed because it fails when libcomposite is built
into kernel (it hasn't own directory in /sys/module so adding an
attribute causes NULL pointer dereference)

--
BR's
Krzysztof Opasiak


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sebastian Andrzej Siewior]

Post by Felipe Balbi
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.

=20
Using udc clas is not a good idea. This may cause failures in userspa=

ce.
failures? like what?

How would you like to tell that this is not really a udc? Only type o=

f

Adding a new class for one file does not look right. Try to add a file
if you have to but without creating a new class for it.

It looks like it would fit best in the configfs root directory.

However, I am not sure this is required at all. I would rather prefer
having a userland tool (like target has) which helps you assembling a
gadget instead of having users poking at files and then "eh look! lets
see what this can do=85".

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrzej Pietrasiewicz]

Post by Sebastian Andrzej Siewior

Post by Felipe Balbi
another class ? Please don't, we already have the udc class, we
could find a way to just use that instead.

Using udc clas is not a good idea. This may cause failures in usersp=

ace.

Post by Sebastian Andrzej Siewior
failures? like what?

How would you like to tell that this is not really a udc? Only type =

of

Post by Sebastian Andrzej Siewior
Adding a new class for one file does not look right. Try to add a fil=

e

Post by Sebastian Andrzej Siewior
if you have to but without creating a new class for it.
It looks like it would fit best in the configfs root directory.

I guess you mean:

$ mount -t configfs none $CONFIGFS_ROOT
$ ls $CONFIGFS_ROOT/usb_gadget
func_list

Post by Sebastian Andrzej Siewior
However, I am not sure this is required at all. I would rather prefer
having a userland tool (like target has) which helps you assembling a
gadget instead of having users poking at files and then "eh look! let=

s

Post by Sebastian Andrzej Siewior
see what this can do=85".

A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same thing as being able
to discover it, so in fact this looks like a philosophical issue:
whether userspace should be able to discover what usb functions
there are or not?

AP


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sebastian Andrzej Siewior]

Post by Andrzej Pietrasiewicz
A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same thing as being able
whether userspace should be able to discover what usb functions
there are or not?

The same problem has target in principle as it supports more than one
backend / protocol, etc. What does it do?

Post by Andrzej Pietrasiewicz
AP

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrzej Pietrasiewicz]

Post by Sebastian Andrzej Siewior

Post by Andrzej Pietrasiewicz
A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same thing as being able
whether userspace should be able to discover what usb functions
there are or not?

The same problem has target in principle as it supports more than one
backend / protocol, etc. What does it do?

I believe a part of your response is missing, the above is all I got.

AP

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sebastian Andrzej Siewior]

Post by Andrzej Pietrasiewicz

A userland tool for assembling gadgets with configfs needs to know =

what

Post by Andrzej Pietrasiewicz

it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same thing as being abl=

e

Post by Andrzej Pietrasiewicz

whether userspace should be able to discover what usb functions
there are or not?

The same problem has target in principle as it supports more than on=

e

Post by Andrzej Pietrasiewicz

backend / protocol, etc. What does it do?

=20
I believe a part of your response is missing, the above is all I got.

No, it was complete. It has been compressed due to lack of time, true.

You say that userland tool may or may not need to know which functions
are available. And this is as you say a "philosophical issue". Correct.
Either your userland has a list of all available functions (with help /
explanation what it is and what it is good for) or it grabs a list of
available functions.
The latter has the advantage that you can use functions which were
introduced into the kernel before the userland tool was updated (unless
you can specify a "custom" function name). The former has the advantage
that you can "select" say a serial function without knowing that you
have to deal with f_acm.
So I think it boils down to how educated is the user of this in the
end. If he knows that he needs f_acm he does not need a list. If he
tries to use f_acm "manually" and the loading/linking the function
fails with ENOENT plus the kernel says "dude that function is not
available" then he knows that something is missing. Either that module
has not been copied or it has not been enabled in the kernel.

That is why I suggested to look at target subsystem and its userland
tool for configuration. In target you can have multiple storage units
(say file, block device, ram disk, transparent SCSI) and a few
protocols to access the device (iSCSI, firewire, USB, =85). So you have
the same problem from the user/tool point of view: May or may I not use
the iSCSI protocol? Was it enabled in the kernel? What modules are
available at all?
Since target and its userland tool (targetcli) is available for
sometime now, maybe a look on those will give an idea on how the
problem has been solved once _and_ whether it is good or not.

Post by Andrzej Pietrasiewicz
=20
AP
=20

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Post by Sebastian Andrzej Siewior

Post by Andrzej Pietrasiewicz

Post by Sebastian Andrzej Siewior

Post by Andrzej Pietrasiewicz
A userland tool for assembling gadgets with configfs needs to know what
it can or cannot do, that is, what usb functions are available.
Knowing what functions there are is not the same thing as being able
whether userspace should be able to discover what usb functions
there are or not?

The same problem has target in principle as it supports more than one
backend / protocol, etc. What does it do?

I believe a part of your response is missing, the above is all I got.

No, it was complete. It has been compressed due to lack of time, true.
You say that userland tool may or may not need to know which functions
are available. And this is as you say a "philosophical issue". Correct.
Either your userland has a list of all available functions (with help /
explanation what it is and what it is good for) or it grabs a list of
available functions.
The latter has the advantage that you can use functions which were
introduced into the kernel before the userland tool was updated (unless
you can specify a "custom" function name). The former has the advantage
that you can "select" say a serial function without knowing that you
have to deal with f_acm.
So I think it boils down to how educated is the user of this in the
end. If he knows that he needs f_acm he does not need a list. If he
tries to use f_acm "manually" and the loading/linking the function
fails with ENOENT plus the kernel says "dude that function is not
available" then he knows that something is missing. Either that module
has not been copied or it has not been enabled in the kernel.
That is why I suggested to look at target subsystem and its userland
tool for configuration. In target you can have multiple storage units
(say file, block device, ram disk, transparent SCSI) and a few
protocols to access the device (iSCSI, firewire, USB, 
). So you have
the same problem from the user/tool point of view: May or may I not use
the iSCSI protocol? Was it enabled in the kernel? What modules are
available at all?
Since target and its userland tool (targetcli) is available for
sometime now, maybe a look on those will give an idea on how the
problem has been solved once _and_ whether it is good or not.

I agree with Sebastian here. At the end of the day, we don't expect
users to go fiddle with configfs directly and rather use libgadget
through a tool that uses it.

[Andrzej Pietrasiewicz]

<snip>

Post by Felipe Balbi

Post by Sebastian Andrzej Siewior
Since target and its userland tool (targetcli) is available for
sometime now, maybe a look on those will give an idea on how the
problem has been solved once _and_ whether it is good or not.

I agree with Sebastian here. At the end of the day, we don't expect
users to go fiddle with configfs directly and rather use libgadget
through a tool that uses it.

I don't have a strong opinion here, either.

It is libusbg (that's how the library is actually called now) that
should now. The thing is _how_ it should know: it can either be
given a config file, or discover what's available.

I believe we should take the best from both worlds:

- there is a config file distributed with libusbg,
- there is some generic way to handle functions not known
at the moment of library's release

@Krzysztof:
@Matt:
what do you think?

AP
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Krzysztof Opasiak]

Post by Andrzej Pietrasiewicz

On Wed, Jul 16, 2014 at 09:58:31AM +0200, Sebastian Andrzej Siewior =

<snip>

Post by Sebastian Andrzej Siewior
Since target and its userland tool (targetcli) is available for
sometime now, maybe a look on those will give an idea on how the
problem has been solved once _and_ whether it is good or not.

I agree with Sebastian here. At the end of the day, we don't expect
users to go fiddle with configfs directly and rather use libgadget
through a tool that uses it.

I don't have a strong opinion here, either.
It is libusbg (that's how the library is actually called now) that
should now. The thing is _how_ it should know: it can either be
given a config file, or discover what's available.
- there is a config file distributed with libusbg,
- there is some generic way to handle functions not known
at the moment of library's release
what do you think?

In my opinion the target client is not libusbg but a layer above it,
let's call it gadget tool and gadget daemon. Libusbg should provide
convenient API for all functions which has been merged to kernel.
Library doesn't need to know which functions are available, it only
need to know how to configure them if the are available. If some
function is not available usbg_create_function() will simply fail with
suitable error code.

The problem is in a tool or a daemon. User should be able to discover
set of available functions using gadget tool or daemon. Currently it
is possible only by iterating through all supported in libusbg
functions and trying to create each of it. It's not a good method. In
my opinion it's more a hack that a solution.

There is a method to discover list of functions which are compiled as
kernel modules but without access to kernel config, tool and a daemon
are unable to discover which USB functions has been compiled into
kernel.

--
BR's
Krzysztof Opasiak
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Sebastian Andrzej Siewior]

Post by Krzysztof Opasiak
In my opinion the target client is not libusbg but a layer above it,
let's call it gadget tool and gadget daemon. Libusbg should provide
convenient API for all functions which has been merged to kernel.
Library doesn't need to know which functions are available, it only
need to know how to configure them if the are available. If some
function is not available usbg_create_function() will simply fail with
suitable error code.

So you didn't answer my questions. Say you have a list of two functions
says acm and ncm. Based on this information how do you know how to
configure it?

Post by Krzysztof Opasiak
The problem is in a tool or a daemon. User should be able to discover
set of available functions using gadget tool or daemon. Currently it
is possible only by iterating through all supported in libusbg
functions and trying to create each of it. It's not a good method. In
my opinion it's more a hack that a solution.
There is a method to discover list of functions which are compiled as
kernel modules but without access to kernel config, tool and a daemon
are unable to discover which USB functions has been compiled into
kernel.

I asked how target solving this. You are refering to libusbg and I have
no idea what this is. The way I see it, is that you have a bunch of different
functions and each function is different and needs to be configured
differently. Say storage needs iSerial not to mention the backend and ncm
needs a MAC address. Where do you gather that information from?

What I could image is right now is a tool that has a configuration file which
provides all the information how to configure a function. And now I ask
myself what is target doing. Does it query which modules and so backends
/ fabrics are available or does it just assume that all of those are
available?

Post by Krzysztof Opasiak
--
BR's
Krzysztof Opasiak

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Krzysztof Opasiak]

-----Original Message-----
Sent: Friday, October 17, 2014 3:03 PM
To: Krzysztof Opasiak
Cc: Andrzej Pietrasiewicz; Marek Szyprowski; Greg Kroah-Hartman;
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions

Post by Krzysztof Opasiak
In my opinion the target client is not libusbg but a layer above

it,

Post by Krzysztof Opasiak
let's call it gadget tool and gadget daemon. Libusbg should

provide

Post by Krzysztof Opasiak
convenient API for all functions which has been merged to kernel.
Library doesn't need to know which functions are available, it

only

Post by Krzysztof Opasiak
need to know how to configure them if the are available. If some
function is not available usbg_create_function() will simply fail

with

Post by Krzysztof Opasiak
suitable error code.

So you didn't answer my questions. Say you have a list of two
functions
says acm and ncm. Based on this information how do you know how to
configure it?

That's a good question but not directly related to current problem.
The problem is that user ends up in empty functions directory in
some gadget and has to write some magic strings which he may not know.
He has just build in the usb_f_mass_storage module and usb_f_ss_lb
and where should he get the information that he needs to use
mass_storage, Loopback and SourceSink as function types?
All those three are just magic strings hardcoded in kernel and not
exported in any place to userspace but we enforce the user to know them
and provide them to configfs.

Second scenario is that we have some running kernel and everything is
compiled-in and we would like to create a gadget. Let's say that we have
experience and we know all that magic strings but there still is a
problem
because we don't know what is available in current kernel. We need to
try
creating instance for all known for us functions type to learn what is
available in this kernel.

Post by Krzysztof Opasiak
The problem is in a tool or a daemon. User should be able to

discover

Post by Krzysztof Opasiak
set of available functions using gadget tool or daemon. Currently

it

Post by Krzysztof Opasiak
is possible only by iterating through all supported in libusbg
functions and trying to create each of it. It's not a good

method. In

Post by Krzysztof Opasiak
my opinion it's more a hack that a solution.
There is a method to discover list of functions which are

compiled as

Post by Krzysztof Opasiak
kernel modules but without access to kernel config, tool and a

daemon

Post by Krzysztof Opasiak
are unable to discover which USB functions has been compiled into
kernel.

I asked how target solving this. You are refering to libusbg and I have
no idea what this is. The way I see it, is that you have a bunch of different
functions and each function is different and needs to be configured
differently. Say storage needs iSerial not to mention the backend and ncm
needs a MAC address. Where do you gather that information from?
What I could image is right now is a tool that has a configuration file which
provides all the information how to configure a function. And now I ask
myself what is target doing. Does it query which modules and so backends
/ fabrics are available or does it just assume that all of those are
available?

Library may support all currently mainlined functions and know how to
configure them. Like I wrote above problem is that currently running
kernel may have only subset of them and user has no ability to get
list of functions from kernel. Even if he has a config file he needs
to study kernel source to know what name has this particular module
registered in configfs.

--
Krzysiek

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Krzysztof Opasiak]

-----Original Message-----
Sent: Friday, October 17, 2014 4:30 PM
To: 'Sebastian Andrzej Siewior'; 'Krzysztof Opasiak'
Cc: Andrzej Pietrasiewicz; Marek Szyprowski; 'Greg Kroah-Hartman';
Subject: RE: [PATCHv2] usb: gadget: composite: Provide a list of
available functions

-----Original Message-----
Sent: Friday, October 17, 2014 3:03 PM
To: Krzysztof Opasiak
Cc: Andrzej Pietrasiewicz; Marek Szyprowski; Greg Kroah-Hartman;
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions

Post by Krzysztof Opasiak
In my opinion the target client is not libusbg but a layer

above

it,

Post by Krzysztof Opasiak
let's call it gadget tool and gadget daemon. Libusbg should

provide

Post by Krzysztof Opasiak
convenient API for all functions which has been merged to

kernel.

Post by Krzysztof Opasiak
Library doesn't need to know which functions are available, it

only

Post by Krzysztof Opasiak
need to know how to configure them if the are available. If

some

Post by Krzysztof Opasiak
function is not available usbg_create_function() will simply

fail

with

Post by Krzysztof Opasiak
suitable error code.

So you didn't answer my questions. Say you have a list of two functions
says acm and ncm. Based on this information how do you know how

to

configure it?

That's a good question but not directly related to current problem.
The problem is that user ends up in empty functions directory in
some gadget and has to write some magic strings which he may not know.
He has just build in the usb_f_mass_storage module and usb_f_ss_lb
and where should he get the information that he needs to use
mass_storage, Loopback and SourceSink as function types?
All those three are just magic strings hardcoded in kernel and not
exported in any place to userspace but we enforce the user to know them
and provide them to configfs.
Second scenario is that we have some running kernel and everything is
compiled-in and we would like to create a gadget. Let's say that we have
experience and we know all that magic strings but there still is a
problem
because we don't know what is available in current kernel. We need to
try
creating instance for all known for us functions type to learn what is
available in this kernel.

Post by Krzysztof Opasiak
The problem is in a tool or a daemon. User should be able to

discover

Post by Krzysztof Opasiak
set of available functions using gadget tool or daemon.

Currently

it

Post by Krzysztof Opasiak
is possible only by iterating through all supported in libusbg
functions and trying to create each of it. It's not a good

method. In

Post by Krzysztof Opasiak
my opinion it's more a hack that a solution.
There is a method to discover list of functions which are

compiled as

Post by Krzysztof Opasiak
kernel modules but without access to kernel config, tool and a

daemon

Post by Krzysztof Opasiak
are unable to discover which USB functions has been compiled

into

Post by Krzysztof Opasiak
kernel.

I asked how target solving this. You are refering to libusbg and

I

have
no idea what this is. The way I see it, is that you have a bunch

of

different
functions and each function is different and needs to be

configured

differently. Say storage needs iSerial not to mention the backend and ncm
needs a MAC address. Where do you gather that information from?
What I could image is right now is a tool that has a

configuration

file which
provides all the information how to configure a function. And now

I

ask
myself what is target doing. Does it query which modules and so backends
/ fabrics are available or does it just assume that all of those are
available?

Library may support all currently mainlined functions and know how to
configure them. Like I wrote above problem is that currently
running
kernel may have only subset of them and user has no ability to get
list of functions from kernel. Even if he has a config file he
needs
to study kernel source to know what name has this particular module
registered in configfs.

In addition, this situation is quite similar to providing implementation
of some file system. Instead of looking to config file or going through
kernel source or doing anything else you have a list of registered file
systems in /proc/filesystems. Don't you think that this situation is
very similar to our?

--
Krzysiek

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

['Sebastian Andrzej Siewior']

Post by Krzysztof Opasiak

Post by Sebastian Andrzej Siewior
So you didn't answer my questions. Say you have a list of two functions
says acm and ncm. Based on this information how do you know how to
configure it?
=20

=20
That's a good question but not directly related to current problem.
The problem is that user ends up in empty functions directory in
some gadget and has to write some magic strings which he may not know=

=2E

Post by Krzysztof Opasiak
He has just build in the usb_f_mass_storage module and usb_f_ss_lb
and where should he get the information that he needs to use
mass_storage, Loopback and SourceSink as function types?
All those three are just magic strings hardcoded in kernel and not
exported in any place to userspace but we enforce the user to know th=

em

Post by Krzysztof Opasiak
and provide them to configfs.

okay. I try it once again and I am close to give up:
target uses configfs in a very similar fashion compared to what the
gadget interface does. Similar to the gadget interface it provides
different fabrics and back-ends. I doubt there is a list of available
"functionality" exported somewhere in the target code. I believe very
much that the userland hides all that information from you and simply
assumes that the modules is available (and the kernel tries to load it
if is not available but that is an implementation detail whether the
kernel or that tool tries to load the module on failure).

Post by Krzysztof Opasiak
Second scenario is that we have some running kernel and everything is
compiled-in and we would like to create a gadget. Let's say that we h=

ave

Post by Krzysztof Opasiak
experience and we know all that magic strings but there still is a
problem
because we don't know what is available in current kernel. We need to
try
creating instance for all known for us functions type to learn what i=

s

Post by Krzysztof Opasiak
available in this kernel.

That is the wrong attempt. You have to have a config file in your userl=
and=20
tool which provides the information of all available functions and how =
/=20
what is required to configure them. If the user decides to use the stor=
age
function the tool will offer the two storage functions we have _or_ dis=
play a
list of all available functions including a hint/help text what the fun=
ction
what it is good for (or do you know what ECM, NCM and ACM is good for?)=
=2E
Either way, the user selects the function he/she wants to use and the t=
ool does
magic in the background. If the mkdir fails then it is likely that the =
module
is not available and not built-in. And now you can display an error mes=
sage
about missing modules.

Seriously I don't see how a list of available / loaded functions will
help you in the long run because (as I wrote earlier) you need specific
knowledge how to configure it. Btw, what do you do if a given function
is not listed? Do you tell the use load the module or you modprobe it?

Once it is ready and you have your complete gadget configured you could
safe it for later usage. A nice thing would be to export the configurat=
ion=20
as a simple sh file which configures the gadget (say the userland is
written in java and you would prefer not to install java on your
embedded system for a few mkdir/ln/=E2=80=A6 invocations).

Post by Krzysztof Opasiak
Library may support all currently mainlined functions and know how to
configure them. Like I wrote above problem is that currently running
kernel may have only subset of them and user has no ability to get
list of functions from kernel. Even if he has a config file he needs
to study kernel source to know what name has this particular module
registered in configfs.

Yes and the user land tool I wrote and wrote about should have the
required knowledge so you do not have to study the kernel source at all=
=2E

So if you would have taken a look on target-cli you would see that you
do not need to read the kernel code in order to setup scsi device. And
exactly the same thing I have in mind for the gadget interface.

Post by Krzysztof Opasiak
=20
--
Krzysiek
=20

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Krzysztof Opasiak]

-----Original Message-----
Sent: Monday, October 20, 2014 7:38 PM
To: Krzysztof Opasiak
Cc: 'Krzysztof Opasiak'; Andrzej Pietrasiewicz; Marek Szyprowski;
Subject: Re: [PATCHv2] usb: gadget: composite: Provide a list of
available functions
=20

Post by Krzysztof Opasiak

Post by Sebastian Andrzej Siewior
So you didn't answer my questions. Say you have a list of two functions
says acm and ncm. Based on this information how do you know how

to

Post by Krzysztof Opasiak

Post by Sebastian Andrzej Siewior
configure it?

That's a good question but not directly related to current

problem.

Post by Krzysztof Opasiak
The problem is that user ends up in empty functions directory in
some gadget and has to write some magic strings which he may not

know.

Post by Krzysztof Opasiak
He has just build in the usb_f_mass_storage module and

usb_f_ss_lb

Post by Krzysztof Opasiak
and where should he get the information that he needs to use
mass_storage, Loopback and SourceSink as function types?
All those three are just magic strings hardcoded in kernel and

not

Post by Krzysztof Opasiak
exported in any place to userspace but we enforce the user to

know them

Post by Krzysztof Opasiak
and provide them to configfs.

=20
target uses configfs in a very similar fashion compared to what the
gadget interface does. Similar to the gadget interface it provides
different fabrics and back-ends. I doubt there is a list of
available
"functionality" exported somewhere in the target code. I believe very
much that the userland hides all that information from you and
simply
assumes that the modules is available (and the kernel tries to load it
if is not available but that is an implementation detail whether the
kernel or that tool tries to load the module on failure).

I don't know the target and it's configfs usage so I can only speak
about composing gadget. Assuming that all usb functions are available
in kernel is not a good idea. This hurts user experience because a tool
or something may tell user that such function is available when really
it's not. This means that creating it's instance will fail.

=46unctions are kind of building blocks and gadget is simply some build=
ing
which consist of that blocks. Those blocks are identified using some un=
ique
ID called "function type" which is just a string registered by kernel d=
river.
Our assumption is that user know exactly how to configure RNDIS, Functi=
on FS
and other functions. Problem is that user doesn't know which of those f=
unctions
are available in his current kernel and what are the magic strings regi=
stered
as a type name.

Problem is on two levels:

- bare command line interface level
User doesn't have any additional tool and only know what is the convent=
ion and what
is Remote Network Driver Interface Specification and what is Function F=
S and how to
use them. So now I ask how user can discover that first of them is regi=
stered as rndis
and not as RNDIS or Rndis or maybe RndiS? Moreover let's say that funct=
ion fs has not
been selected while building this kernel and it's not available.
So how should we discover it?
Just try to create the directory?
This is good for one function but what if we have 10 or 15 of them?

- tool or library level
While creating such thing we may hardcode the strings for each currentl=
y mainlined
function and information how to configure it. The case here is that usu=
ally currently
running kernel will have only subset of those functions but not all of =
them.
The question here is how user can ask such a tool what he can create? S=
howing user a full
list of known function may be confusing because on one hand we show tha=
t this functions
is available but on other hand we tell him that we cannot create such f=
unction because there
is no suitable module. Of course tool can iterate over all known usb fu=
nctions and try to
create each of them to check if this function is available.
Don't you thing that this is a little bit weird and confusing?
It look really ugly, cause overhead and makes configfs dirty due to cre=
ating some "test"
gadget to check available functions.

=20

Post by Krzysztof Opasiak
Second scenario is that we have some running kernel and

everything is

Post by Krzysztof Opasiak
compiled-in and we would like to create a gadget. Let's say that

we have

Post by Krzysztof Opasiak
experience and we know all that magic strings but there still is

a

Post by Krzysztof Opasiak
problem
because we don't know what is available in current kernel. We

need to

Post by Krzysztof Opasiak
try
creating instance for all known for us functions type to learn

what is

Post by Krzysztof Opasiak
available in this kernel.

=20
That is the wrong attempt. You have to have a config file in your
userland
tool which provides the information of all available functions and
how /
what is required to configure them. If the user decides to use the
storage
function the tool will offer the two storage functions we have _or_
display a
list of all available functions including a hint/help text what the
function
what it is good for (or do you know what ECM, NCM and ACM is good
for?).
Either way, the user selects the function he/she wants to use and
the tool does
magic in the background. If the mkdir fails then it is likely that
the module
is not available and not built-in. And now you can display an error
message
about missing modules.

But please separate knowledge about how to configure each function
from knowledge if this function is currently available. We may know the
configuration for each mainlined usb function but our current kernel ma=
y
have only acm for example.
So why should we show user a full list with storage, Ethernet and other=
if
those functions are not available and it won=E2=80=99t be possible to c=
reate their
instance?
It's very confusing for user.

Moreover if you would like to say now that we may provide information w=
hat
is available in config file please wait a minute and ask again yourself=
if
you really would like to use it. Creating a separate configuration file=
which
content depends on current kernel configuration means that something is=
missing
in kernel framework. This is why the whole sys and proc has been create=
d.
To allow user look into kernel and learn what hardware and kernel objec=
ts are
available.

Please once again look to example which I gave you (the file systems). =
We have
a generic framework where particular driver can register. While mountin=
g, user
can specify -t option and pass the fs type which is the "name of driver=
"
(string which uniquely identify the fs driver ex. ext4, fat32 etc.).
But user doesn't need to know those magic strings because they are all =
available
in /proc/filesystems. Don't you think that situation with usb functions=
is very
similar? User should be able to ask kernel "Hey kernel, tell me what yo=
u have
inside what I can use?" This is how it works with filesystems and what =
user
should be able to do with usb functions. I don't see any reason to writ=
e this
information manually in regular config file for tool instead of exporti=
ng this
automatically form kernel.

=20
Seriously I don't see how a list of available / loaded functions will
help you in the long run because (as I wrote earlier) you need
specific
knowledge how to configure it. Btw, what do you do if a given
function
is not listed? Do you tell the use load the module or you modprobe it?

Like I wrote above we may know how to configure each mainlined usb func=
tions
but we should also have opportunity to discover what we have in our cur=
rently
running kernel.

=20
Once it is ready and you have your complete gadget configured you could
safe it for later usage. A nice thing would be to export the
configuration
as a simple sh file which configures the gadget (say the userland is
written in java and you would prefer not to install java on your
embedded system for a few mkdir/ln/=E2=80=A6 invocations).

We have chosen other approach in libusbg. We create a configuration fil=
e
which can be loaded using single library function.

=20

Post by Krzysztof Opasiak
Library may support all currently mainlined functions and know

how to

Post by Krzysztof Opasiak
configure them. Like I wrote above problem is that currently

running

Post by Krzysztof Opasiak
kernel may have only subset of them and user has no ability to

get

Post by Krzysztof Opasiak
list of functions from kernel. Even if he has a config file he

needs

Post by Krzysztof Opasiak
to study kernel source to know what name has this particular

module

Post by Krzysztof Opasiak
registered in configfs.

=20
Yes and the user land tool I wrote and wrote about should have the
required knowledge so you do not have to study the kernel source at
all.
=20
So if you would have taken a look on target-cli you would see that you
do not need to read the kernel code in order to setup scsi device. And
exactly the same thing I have in mind for the gadget interface.

Please see my comments above.

Krzysiek

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html