> -----Original Message-----
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, January 27, 2015 8:38 PM
> To: Krzysztof Opasiak
> Cc: ba...@ti.com; linux-usb@vger.kernel.org;
> gre...@linuxfoundation.org; bige...@breakpoint.cc;
> s.wa...@samsung.com; k.lewando...@samsung.com;
> m.szyprow...@samsung.com; andrze...@samsung.com
> Subject: Re: [PATCH] usb: gadget: composite: Provide list of
> registered functions
> 
> Hi,
> 
> On Tue, Jan 27, 2015 at 08:20:58PM +0100, Krzysztof Opasiak wrote:
> >
> >
> > > -----Original Message-----
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Tuesday, January 27, 2015 7:45 PM
> > > To: Krzysztof Opasiak
> > > Cc: ba...@ti.com; linux-usb@vger.kernel.org;
> > > gre...@linuxfoundation.org; bige...@breakpoint.cc;
> > > s.wa...@samsung.com; k.lewando...@samsung.com;
> > > m.szyprow...@samsung.com; andrze...@samsung.com
> > > Subject: Re: [PATCH] usb: gadget: composite: Provide list of
> > > registered functions
> > >
> > > Hi,
> > >
> > > On Tue, Jan 27, 2015 at 06:24:42PM +0100, Krzysztof Opasiak
> wrote:
> > > > > > 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.
> > > > >
> > > > > and that's fine, they can certainly assume that. Once
> configfs
> > > is
> > > > > mounted, we will have a new /sys/kernel/config/usb-
> functions
> > > > > directory.
> > > > >
> > > > > Inside that directory we should have a file which contains
> your
> > > list
> > > > > of available functions :-) I don't see what the problem is
> with
> > > that
> > > > > :-s
> > > > >
> > > >
> > > > Please hold done I don't get it. Let's clarify.
> > >
> > >  _________________________________________
> > > / Hello! I'm a programmer cow who can     \
> > > | explain ConfigFS-related questions much | better than Felipe
> > > Balbi.
> > > | What we need  |
> > > | in this case is just for the our USB    |
> > > | Gadget ConfigFS port to create the file |
> > > | when that is mounted. Just have the     |
> > > | file come with /usb_gadget. Not ProcFS, | not SysFS, but with
> > > ConfigFS
> > > | and we're  |
> > > | good to go. Let me know if I can        |
> > > \ explain anything further                /
> > >  -----------------------------------------
> > >         \   ^__^
> > >          \  (Oo)\_______
> > >             (__)\       )\/\
> > >                 ||----w |
> > >                 ||     ||
> > >
> > > > Would you like to register a separate usb-functions subsystem
> in
> > > > configfs only to expose there a list of available functions?
> As
> > > far as
> > > > I know it's the only way of creating anything in configfs
> root.
> > > >
> > > > So you would get:
> > > >
> > > > $ ls /sys/kernel/config
> > > > usb-gadget usb-functions
> > > >
> > > >
> > > > Or it is just a typo and you would like to place a usb-
> functions
> > > > attribute in usb-gadget directory?
> > > > In this option we will get:
> > > >
> > > > $ ls /sys/kernel/config
> > > > usb-gadget
> > > > $ ls /sys/kernel/config/usb-gadget usb-function $ cat usb-
> function
> > > > acm ecm ...
> > >
> > >  ______________________________________
> > > / Hello again. This is exactly what I  \
> > > | have in mind. Thank you. Let's just  | call it a more
> descriptive
> > > name
> > > | like |
> > > \ 'available_functions'                /
> > >  --------------------------------------
> > >         \   ^__^
> > >          \  (Oo)\_______
> > >             (__)\       )\/\
> > >                 ||----w |
> > >                 ||     ||
> > >
> >
> > I have written this few times in previous emails but our new
> friend
> > could miss those emails so once again esp. for beautiful cow from
> a
> > rubber duck:
> >
> >   IMPORTANT______________________________________________
> >  /                                                        \
> >  | Adding a file to usb_gadget directory is an *ABI break*.|
> 
> an ABI break would be removing an existing file, not adding a new
> one.

ABI break is a change of behavior without backward compatibility

> 
> >  \_________________ _____________________________________ /
> >                   //
> >                 //
> >        ..---..//
> >      .'  _    `.
> >  __..'  (o)    :
> > `..__          ;
> >      `.       /
> >        ;      `..---...___
> >      .'                   `~-. .-')
> >     .                         ' _.'
> >    :                           :
> >    \                           '
> >     +                         J
> >      `._                   _.'
> >         `~--....___...---~' mh
> >
> > Currently each valid file name is also suitable for gadget.
> > There is no additional restrictions.
> >
> > No matter what name we will give to this new file this name could
> be
> > used previously by someone in userspace.
> > His program could be broken after kernel upgrade.
> 
> the first thing a user of usb-gadget has to do, is create a
> directory, not a file.

This:

$ modprobe libcomposite
$ mount none -t configfs /sys/kernel/config/usb-gadget
$ mkdir available_functions
$ cd available_functions
$ mkdir functions/ecm.eth0
$ mkdir configs/c.1
$ ln -s functions/ecm.eth0 configs/c.1
$ echo `ls /sys/class/udc | tail -n 1` > UDC

works fine with current kernel and  will *fail* after adding
available_functions file due to name already taken even
immediately after system boot.

> 
> > Moreover some broken userspace programs may relay on fact that
> > usb-gadget directory contains only gadget dirs. And some other
> things
> > there is a lot of possible breaks in userspace.
> 
> if there are any users who rely on the fact that *only* directories
> exist under usb-gadget, that's wrong.

I know that it's wrong but that's what Documentation/ABI says
about usb-gadget directory.

> 
> Imagine is sysfs would be forbidden of adding new files and
> directories.
> That's inside, it's crazy-talk :-)
> 

Objects in sysfs are managed by kernel. Kernel creates all 
files there (even if you are dealing with gpio you have to
write name/id to export file and kernel will create attribute
for you) and *kernel will handle their naming*. This means that
user cannot add there an arbitrary file/directory. He may only
read/write existing one. In this case adding a new file doesn't
change the behavior but only adds a new attribute.
This doesn't break the ABI.

In configfs all naming issues are *handled by user*.
User decides what is the name for his gadget. Adding a file to
usb-gadget directory effectively adds a new restriction for
gadget name. This may cause some programs which are currently
working to fail with newer kernel.

Best regards,

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
k.opas...@samsung.com




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

Reply via email to