From: Robert Baldyga <r.baldyga@samsung.com>
To: balbi@ti.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, mina86@mina86.com,
andrzej.p@samsung.com, k.opasiak@samsung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
Date: Tue, 07 Oct 2014 08:33:16 +0200 [thread overview]
Message-ID: <5433892C.80109@samsung.com> (raw)
In-Reply-To: <20141007022851.GA13956@saruman>
On 10/07/2014 04:28 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 06, 2014 at 01:25:14PM +0200, Robert Baldyga wrote:
>> Since we can compose gadgets from many functions, there is the problem
>> related to gadget breakage while FunctionFS daemon being closed. In some
>> cases it's strongly desired to keep gadget alive for a while, despite
>> FunctionFS files are closed, to allow another functions to complete
>> some presumably critical operations.
>>
>> For this purpose this patch introduces "zombie" mode. It can be enabled
>> by setting mount option "zombie=1", and results with defering function
>> closure to the moment of reopening ep0 file or filesystem umount.
>>
>> When ffs->state == FFS_ZOMBIE:
>> - function is still binded and visible to host,
>> - setup requests are automatically stalled,
>> - all another transfers are refused,
>> - opening ep0 causes function close, and then FunctionFS is ready for
>> descriptors and string write,
>> - umount of functionfs cause function close.
>>
>> Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
>
> Can you further explain how do you trigger this ? Do I understand
> correctly that you composed a gadget using configfs and that gadget has
> functionfs + another gadget ?
>
Yes, I compose configfs gadget from functionfs + another gadget, and
when functionfs daemon closes ep files, entire gadget get disconnected
from host. FFS function is userspace code so there is no way to know
when it will close files (it doesn't matter what is the reason of this
situation, it can be daemon logic, program breakage, process kill or any
other). So when we have another function in gadget which, for example,
sends some amount of data, does some software update or implements some
real-time functionality, we may want to keep the gadget connected
despite FFS function is no longer functional. We can't just remove one
of functions from gadget since it has been enumerated, so the only way
we can do that is to make broken FFS function "zombie". It will be still
visible to host but it will no longer implement it's functionality.
> Then what do you need to do the trigger the issue, and what really _is_
> the issue ? Is gadget disconnecting from host too early ? Do you see a
> crash ? Memory leak ? Any logs available ? Any steps to reproduce ?
>
You simply compose gadget from, for example, ethernet and functionfs.
You try to send some huge file through ftp, and in meantime FFS function
breaks. If FFS hasn't enabled "zombie" mode, entire gadget will be
disconnected and data transmission will fail. If "zombie" mode is
enabled, then FFS function after daemon breakage will become "zombie"
and will be nonfunctional, but ethernet gadget will be still active and
data transfer will be completed.
> Quite frankly, I don't really like this "zombie" mode. <joke> I know
> there's a "The Walking Dead" hype right now, but this is too much.
> </joke>
>
I see, but after all I couldn't find more descriptive name for this feature.
> Anyway, please giver me further details of how to get this done.
>
Best regards,
Robert Baldyga
next prev parent reply other threads:[~2014-10-07 6:33 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 [this message]
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
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=5433892C.80109@samsung.com \
--to=r.baldyga@samsung.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=mina86@mina86.com \
/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).