We never made that assumption. We used ioctl's since it was the easiest
and consistent way of solving the problem at the moment. We never said
it was the pefect solution :)
> The advantage of read/write is that it doesn't _force_ a packet on you,
> but the kernel really doesn't care if you have some structure to your read
> and write requests.
No argument here. I completely agree.
The problem with the shared control pipe is not 2 writers stomping on
each other, it's permissions. You can have 2 interfaces on one device
which are completely seperate from each other and you'd like 2 seperate
users/programs to have access to each interface. Each endpoint is
guaranteed to be unique to an interface, except for the default control
pipe.
A simple solution would be to clone the default control pipe for each
interface and manage the permissions independantly.
The major problem with read/write and USB is that while it can solve the
problem for control and bulk pipes, it can't for interrupt and
isochronous pipes.
> > > or possibly you take a more socket-like approach and do
> > >
> > > fd = socket(part-of-the-structure);
> > > bind(fd, more-of-the-structure)
> > > connect(fd, last-part-of-the-structure);
> >
> > I don't like socket's since we do have a well bound set of endpoints. We
> > don't have 4 billion IP's with 64k ports to choose from. We have x
> > endpoints that the device tells us about ahead of time.
>
> Note that "sockets" != "IPv4". Sockets just have names, they can be IPv4
> (4+2 byte things), they can be pathnames (UNIX domain) and they can be
> large IPv6 (16+2 or whatever). Or they could be small USB names. There's
> nothing fundamentally wrong with "binding" a one-byte address and a
> one-byte "interface" name. You'd just create a AF_USB layer ;)
I had always made the assumption that sockets were created because you
couldn't easily map IPv4 semantics onto filesystems. It's unreasonable
to have a file for every possible IP address/port you can communicate
with.
It's not so unreasonable with USB however since the data set (endpoints)
is significantly smaller and manageable. It can be placed in the
filesystem namespace without any problems.
That being said, we can't solve all of USB's problems that way. AF_USB
would probably solve them all however.
> But no, I don't actually like sockets all that much myself. They are hard
> to use from scripts, and many more people are familiar with open/close and
> read/write.
Agreed.
It would be nice to use open/close/read/write for control and bulk and
sockets for interrupt and isochronous.
Although I think that's just too complicated. It's probably easier to
make everything a socket and deal with it that way.
JE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/