linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Alan Stern <stern@rowland.harvard.edu>, Felipe Balbi <balbi@ti.com>
Cc: Krzysztof Opasiak <k.opasiak@samsung.com>,
	"'Robert Baldyga'" <r.baldyga@samsung.com>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, andrzej.p@samsung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
Date: Tue, 07 Oct 2014 22:08:18 +0200	[thread overview]
Message-ID: <xa1toatny765.fsf@mina86.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1410071429500.1504-100000@iolanthe.rowland.org>

> On Tue, 7 Oct 2014, Felipe Balbi wrote:
>> Right, but if we allow this, I can already see folks abusing to
>> connect to the host early and only when necessary do some trickery to
>> e.g. start adbd (not saying Android will do this, just using it as an
>> easy example).

I don't really see that happening.  For the gadget to start all
descriptors need to be known.  Functionfs  will know the descriptors
only once the user space daemon provides them.  Therefore, with the
current features (or even with addition of Robert's feature) there is no
way to let the gadget start without having the daemon running.

On Tue, Oct 07 2014, Alan Stern <stern@rowland.harvard.edu> wrote:
> We can still keep the pullup turned off until all the functions are
> ready.  That's a part of normal behavior -- unlike what happens when a
> userspace component crashes or is killed.

>> Then how do we differentiate a normal close() from a "oh-crap-I-died"
>> close() ?

> We can't, so why worry about it?

We actually might be able to distinguish those cases with another ioctl
which daemon must issue on the ep0 prior to closing it.  I'm not saying
that we should implement that though.

> If a file handle was closed for normal reasons then userspace probably 
> in the middle of shutting down the gadget anyway.  If not then the 
> user will get what they deserve.
>
> If the file handle was closed for abnormal reasons, we can behave like 
> crashed firmware.  Which means, in the end, doing the same thing as in 
> the normal-reason case -- i.e., do nothing.  In particular, don't 
> disconnect.
>
> If you want to allow for the possibility of orderly shutdown (and maybe 
> even possible restart) of a userspace handler, the function library 
> should first tell the kernel explicitly to disconnect.  Then function 
> components can be changed around completely, and when everything is 
> ready, userspace can tell the kernel to connect again.

I'm wondering if it would be possible to support user-space daemon
restarts with O_APPEND flag.  This is probably looking too far to the
future though.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz    (o o)
ooo +--<mpn@google.com>--<xmpp:mina86@jabber.org>--ooO--(_)--Ooo--

  parent reply	other threads:[~2014-10-07 20:08 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-06 11:25 [PATCH] usb: gadget: f_fs: add "zombie" mode Robert Baldyga
2014-10-06 12:36 ` Michal Nazarewicz
2014-10-06 12:51   ` Robert Baldyga
2014-10-06 14:07     ` Michal Nazarewicz
2014-10-07  2:28 ` Felipe Balbi
2014-10-07  6:33   ` Robert Baldyga
2014-10-07 14:06     ` Felipe Balbi
2014-10-07 15:01       ` Krzysztof Opasiak
2014-10-07 15:28         ` Felipe Balbi
2014-10-07 16:37           ` Krzysztof Opasiak
2014-10-07 16:51             ` Felipe Balbi
2014-10-07 17:15               ` Alan Stern
2014-10-07 17:57                 ` Felipe Balbi
2014-10-07 18:42                   ` Alan Stern
2014-10-07 18:57                     ` Felipe Balbi
2014-10-07 19:16                       ` Alan Stern
2014-10-07 20:08                     ` Michal Nazarewicz [this message]
2014-10-08 10:09                       ` Krzysztof Opasiak
2014-10-08 11:28                         ` Michal Nazarewicz
2014-10-08 14:52                       ` Alan Stern
2014-10-09 10:56                         ` Michal Nazarewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xa1toatny765.fsf@mina86.com \
    --to=mina86@mina86.com \
    --cc=andrzej.p@samsung.com \
    --cc=balbi@ti.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=k.opasiak@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=r.baldyga@samsung.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).