On 12/08/2012 12:18 AM, Joel Becker wrote:
Hey Guys,
Hi Joel,
you took quite some time to write this down.
Please remember that configfs is not a "user" interface, it's a
userspace<->kernelspace interface. Like sysfs, it's not required to be
convenient for someone at a bash prompt. My goal is that it is *usable*
from a bash prompt. So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but you
might have a lot of those mkdir/echo combos to configure something.
When it comes to the "user" interface, a wrapper script or library
should be converting a user intention into all that boilerplate.
It is good that you say such things so people that want this things know
the reasons why it is not done.
I think the question is of information flow direction. If user gives
some information to the kernel, she should be the one creating any
necessary directories. But if the information comes from kernel to the
user, the kernel should create the structure.
This last paragraph actually describes the distinction between
configfs and sysfs. More specifically, if userspace wants to create an
object in the kernel, it should use configfs. If the kernel has created
an object on its own, it exposes it via sysfs. It is a deliberate
non-goal for configfs to replicate sysfs behavior.
So you are saying that I should expose my UDC hardware device via sysfs
after the hardware is available because the kernel created it.
How should I get then into configfs? mkdir a directory which is named
like the HW? This would be painful to do manually but as you said, we
should have a tool.
[What About the Patch?]
In general, attribute setting that turns into created configfs
objects is against the theory of configfs. In practice, it's a
nightmare locking change. Coming into this discussion, I though you
were doing dymanic things at ->make_group() time, but that is already
supported.
But I want to hear your thoughts. I've dumped a bunch of
alternate approaches here. Do any seem to fit? What other challenges
do you see?
I'm mostly fine with this. Part of the problem was/is that the user
could create lun1 without lun0. Now, after looking at target they don't
have this limitation so I don't think we should have it either. As nab
explained, lun0 is always handled implicit for certain requests and not
exposed as a lun if the user did not create it. So I think we can live
with this. After all we can still return with -EINVAL if the user
creates lun1 before lun0.
Now one little question remains: We plan to expose interface numbers
and endpoints. The current idea is to have one directory for each
endpoint something like endpointXX where XX is the endpoint number.
We create the gadget upfront and assign it later to the UDC via a
symlink. We learn the interface number after the gadget has been
assigned. I think you suggest that we create the directory via the tool
once we exposed its details via sysfs or so. This might be okay since we
want it probably only for debugging. On the hand if we drop the
endpooint number we don't have this. Got to keep thinking about this.
Anyway, thank you for time and arguments pro / contra self-created
directories.
Joel
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
