All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Nazarewicz <mina86@mina86.com>
To: Robert Baldyga <r.baldyga@samsung.com>, balbi@ti.com
Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, andrzej.p@samsung.com,
	k.opasiak@samsung.com
Subject: Re: [PATCH] usb: gadget: f_fs: add "zombie" mode
Date: Mon, 06 Oct 2014 16:07:29 +0200	[thread overview]
Message-ID: <xa1tppe52swu.fsf@mina86.com> (raw)
In-Reply-To: <5432903A.9070907@samsung.com>

> On 10/06/2014 02:36 PM, Michal Nazarewicz wrote:
>> However, all the ep# files will still exist on the filesystem.  This may
>> be a bit confusing and error-prone, no?

On Mon, Oct 06 2014, Robert Baldyga <r.baldyga@samsung.com> wrote:
> Shouldn't be error-prone, because opening them will fail with -ENODEV,
> but indeed it can be confusing. I will try to do something about that

I could imagine someone will write shell script like so:

	ffs_active() {
		test -d "$1" || return 1
		set -- "$1"/ep*
		test $# -gt 1
	}

	if ffs_active /dev/foo-ffs; then
		# …
	fi

With such a script, non-functional ep# files in the functionfs mount
point, could lead to some errors in user-space.  I'm not saying that
this should block on any kind of changes to the way the filesystem works
when the function is inactive, but if possible, w/o a lot of additional
code, I'd rather if all the files disappeared in a zombie state.

-- 
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--

  reply	other threads:[~2014-10-06 14:07 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 [this message]
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

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=xa1tppe52swu.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 \
    /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.