lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <001201cdcd72$0c424d50$24c6e7f0$%p@samsung.com>
Date:	Wed, 28 Nov 2012 15:09:54 +0100
From:	Andrzej Pietrasiewicz <andrzej.p@...sung.com>
To:	'Sebastian Andrzej Siewior' <bigeasy@...utronix.de>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	'Kyungmin Park' <kyungmin.park@...sung.com>,
	'Felipe Balbi' <balbi@...com>,
	'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>,
	'Joel Becker' <jlbec@...lplan.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	'Michal Nazarewicz' <mina86@...a86.com>
Subject: RE: [RFC][PATCH] fs: configfs: programmatically create config groups

On Wednesday, November 28, 2012 9:39 AM Sebastian Andrzej Siewior wrote:

<snip>

> >
> > so that we can create the endpoint directories.
> > And now what? What names shall the user use for the endpoint
> > directories? Oh, that's simple: just see what the endpoint
> > directories' names are. But wait, aren't we just creating them?
> >
> > Please also see MichaƂ's point about user interface.
> 
> Yeah I did. Now I'm okay with creating new directories but we should keep
> this to a minimum and encode as much information possible in directory's
> name.
> 

I think I've identified one more case where programmatic creation/removal
of configfs directories is required. There is a general agreement that
binding/unbinding the gadgets will be achieved with using symlinks between
configfs representations of udcs and gadgets. So we need to represent
udcs in configfs. Suppose that the udc driver for user's platform
is modular, e.g. s3c-hsotg.ko. Now, after:

$ modprobe s3c-hsotg

I would _very_ much like the s3c-hsotg or something similar to appear
_automatically_ under $CONFIGFS_ROOT/udcs, e.g.:

$ ls $CONFIGFS_ROOT/udcs

s3c-hsotg

If there can be more instances than 1, then probably I would want

s3c-hsotg.0 	s3c-hsotg.1 ....

or something like that.

It would be _very_ frustrating for the user to have to guess
what name to use _if_ the relevant directory were to be
created manually with mkdir. Conversely, what would

$ rmdir s3c-hsotg

mean? Should it cause the s3c-hsotg.ko to unload?

All the above problems are elegantly solved with programmatic
creation and removal of configfs directories: in the udcs
config_group there is no make_item nor make_group, so mkdir
is not allowed, but instead the directories appear and
disappear as udcs come and go.

Andrzej


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ