From: Michal Nazarewicz <mina86@mina86.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Felipe Balbi <balbi@ti.com>,
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: Thu, 09 Oct 2014 12:56:34 +0200 [thread overview]
Message-ID: <xa1tr3yheckd.fsf@mina86.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1410081049400.1633-100000@iolanthe.rowland.org>
>> On Tue, Oct 07 2014, Alan Stern <stern@rowland.harvard.edu> wrote:
>>> 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.
> On Tue, 7 Oct 2014, Michal Nazarewicz wrote:
>> 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.
On Wed, Oct 08 2014, Alan Stern <stern@rowland.harvard.edu> wrote:
> Actually, we shouldn't need to consider the case where the descriptors
> change. That _always_ requires a disconnect, and the user can cause
> a disconnect simply by killing the daemon and starting it again. No
> separate restart capability is needed.
Correct. This may be going a bit off-topic, but I was thinking of
a possible feature that would allow the daemon to indicate to kernel it
is ready to pick up the pieces after its previous instance crashed.
This would require the zombie mode to be implemented.
* Currently, once the daemon finishes or crashes, USB disconnect
happens.
* In zombie mode, I could imagine the following scenarios:
- daemon crashes, but the gadget still works, no disconnect happens;
- daemon opens ep0 with O_APPEND, no disconnect happens;
- daemon sends *the same* descriptors as before;
- kernel recreates all the ep# files and let the daemon continue
handling USB requests with host possibly never noticing.
Opening ep0 w/o O_APPEND or sending different descriptors would cause
a disconnect. With the above, user-space would be able to force gadget
to disconnect by killing the daemon and then doing
printf '' >/dev/functionfs/ep0
So I guess my point is that with zombie mode, user space could tell the
kernel to not-disconnect (rather than having an explicit disconnect
request) if it was written in a way that supports crash recovery.
This is a wishful thinking at this stage I guess, but perhaps it's worth
considering when deciding how the zombie interface should look like.
For example, I have some concerns if it should be enabled by an fs mount
option.
--
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--
prev parent reply other threads:[~2014-10-09 10:56 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
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 [this message]
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=xa1tr3yheckd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.