[9fans] USB developments

[9fans] USB developments

[Lucio De Re]

Will the USB developers on Plan 9 please stand up, specially the
one with all the comments about how classes should not be managed
in usb/usbd?

I now have a surprising number of USB 2.0 peripherals as wells as
enough USB specifications to make me want to test them.

Let me list them, in case anyone wants me to test their efforts:

	HP ScanJet 5200 scanner
	Canon BJC-2100 colour printer
	Handspring Visor USB cradle
	external IDE drive enclosure with ISD-300 USB controller
	Speed Com+ USB modem (VD56US?)
	an as yet unconnectable Flash RAM reader/writer (Apacer thing)

I've been messing around with the existing code, including Richard
Miller's mass storage driver, but I'm only a little more familiar
with the goings on after all the source perusing and hacking.

I _have_ made a change to /sys/src/usb/usbd/device.c that allows
a configure index of -1 to be used to specify the first available
configuration as the external IDE enclosure I use has only
configuration 2 :-(  No use looking for 1 as usbd.c does in
enumerate(), specially when that is only a first stab at the real
thing as indicated by the /* TO DO */ comment.

My immediate question is whether it makes sense and is even possible
to imitate the behaviour of ip/ipconfig in the case of USB and, in
the instance I have in mind, mount the IDE driver (or the SCSI
driver or the generic "sd" driver, whichever comes closest after
making the necessary adjustments) on the appropriate desired port,
as ipconfig does with etherx and the TCP/IP stack?

If somebody cares to hold my hand while I misuse the last few days
of freedom I have left while the SO is overseas, I'd like to make
some progress on this score.

I have read the USB source code for Plan 9, if not in its entirety,
certainly a few important modules; I still don't understand
(conspicuous amongst many other issues) how isochronous transfers
are created or sustained (I presume the host controller does all
the hard work, if not, I'm missing a huge chunk of knowledge), and
Richard Miller has set me right on a few other issues indicative
of great ignorance on my part.

I have to admit I _like_ USB 2.0, although I am familiar with all
the complaints levelled at it and I believe Plan 9 can and ought
to support it wholeheartedly.  If I can help getting this right,
I'd really like to do it.

++L

Re: [9fans] USB developments

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

I'm not a usb expert, but have done some hacking on it and
have been tempted (a few times) to clean up a bit the
usbd/drivers/#U relationship. We are also running for usb 2.0
devices, and have some of them around, including a touch screen.
BTW, the specs in the usb web site are pretty complete.

It would be great if you could Cc me any mail regarding this issue,
I might help.

[-- Attachment #2: Type: message/rfc822, Size: 4438 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] USB developments
Date: Thu, 15 Jan 2004 08:16:38 +0200
Message-ID: <20040115081637.M4316@cackle.proxima.alt.za>

Will the USB developers on Plan 9 please stand up, specially the
one with all the comments about how classes should not be managed
in usb/usbd?

I now have a surprising number of USB 2.0 peripherals as wells as
enough USB specifications to make me want to test them.

Let me list them, in case anyone wants me to test their efforts:

	HP ScanJet 5200 scanner
	Canon BJC-2100 colour printer
	Handspring Visor USB cradle
	external IDE drive enclosure with ISD-300 USB controller
	Speed Com+ USB modem (VD56US?)
	an as yet unconnectable Flash RAM reader/writer (Apacer thing)

I've been messing around with the existing code, including Richard
Miller's mass storage driver, but I'm only a little more familiar
with the goings on after all the source perusing and hacking.

I _have_ made a change to /sys/src/usb/usbd/device.c that allows
a configure index of -1 to be used to specify the first available
configuration as the external IDE enclosure I use has only
configuration 2 :-(  No use looking for 1 as usbd.c does in
enumerate(), specially when that is only a first stab at the real
thing as indicated by the /* TO DO */ comment.

My immediate question is whether it makes sense and is even possible
to imitate the behaviour of ip/ipconfig in the case of USB and, in
the instance I have in mind, mount the IDE driver (or the SCSI
driver or the generic "sd" driver, whichever comes closest after
making the necessary adjustments) on the appropriate desired port,
as ipconfig does with etherx and the TCP/IP stack?

If somebody cares to hold my hand while I misuse the last few days
of freedom I have left while the SO is overseas, I'd like to make
some progress on this score.

I have read the USB source code for Plan 9, if not in its entirety,
certainly a few important modules; I still don't understand
(conspicuous amongst many other issues) how isochronous transfers
are created or sustained (I presume the host controller does all
the hard work, if not, I'm missing a huge chunk of knowledge), and
Richard Miller has set me right on a few other issues indicative
of great ignorance on my part.

I have to admit I _like_ USB 2.0, although I am familiar with all
the complaints levelled at it and I believe Plan 9 can and ought
to support it wholeheartedly.  If I can help getting this right,
I'd really like to do it.

++L

Re: [9fans] USB developments

[Lucio De Re]

On Thu, Jan 15, 2004 at 09:23:45AM +0100, Fco.J.Ballesteros wrote:
>
> I'm not a usb expert, but have done some hacking on it and
> have been tempted (a few times) to clean up a bit the
> usbd/drivers/#U relationship. We are also running for usb 2.0
> devices, and have some of them around, including a touch screen.

I think we'll need a database of those anyway, could we use someone's
hospitality and list the usb/usbd debug output and whoever may have
an interest in that particular entry (a little like /lib/vgadb) on
a globally accessible server?

We'll also probably need a /lib/vgadb definition file for all the
quirks that USB devices seem to suffer from (I have a document that
covers foibles in CBI devices, a google find I'm sure I can repeat).

> BTW, the specs in the usb web site are pretty complete.
>
They are, aren't they (give or take "bootability" which seems to
have lost track altogether)?  I've collected a good few of their
documents but the 650 pages standard is not one I'm ready to print
just yet.

> It would be great if you could Cc me any mail regarding this issue,
> I might help.

I would like to set up a special interest group, if that's OK with
anyone else who's interested, but not really a separate mailing
list unless the traffic starts swamping other interests here.

Nemo, you're much more familiar with the kernel code, could you
look into the bit I suggested, where a USB utility merges a kernel
function (ATA is my immediate interest) with the USB device,
analogously to the ip/ipconfig does?  I'll be thrilled to implement
the ideas, if you can set me on the right track.

Anyone else wants to play?  I should think a small reflector of
interested individuals for comparing notes would be sufficient?

++L

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> I think we'll need a database of those anyway, could we use someone's
> hospitality and list the usb/usbd debug output and whoever may have
> an interest in that particular entry (a little like /lib/vgadb) on
> a globally accessible server?

Sure. I'm willing to open accounts here, although perhaps sources is
a better place to do that.

> We'll also probably need a /lib/vgadb definition file for all the
> quirks that USB devices seem to suffer from (I have a document that
> covers foibles in CBI devices, a google find I'm sure I can repeat).

After taking a look to it all, I ended up thinking that the scheme should
be like:

#U, does mostly what it does, but stays appart of csp definitions.
usbd: simply configures the device and reads a usbdb file to
learn which program is to be used for each csp.
usbd: starts those programs when a new csp is noticed.
drivers: are started always on a particular target, and work just
for a particular device.

All of it started at boot time.

For example, we have to keep an ugly sleep in boot.c to give
usbd some time before usbhid starts. It would be better the other way.


>
> I would like to set up a special interest group, if that's OK with
> anyone else who's interested, but not really a separate mailing
> list unless the traffic starts swamping other interests here.

Yep. Better keep on using 9fans. There's no need for a separate list.

> Nemo, you're much more familiar with the kernel code, could you
> look into the bit I suggested, where a USB utility merges a kernel
> function (ATA is my immediate interest) with the USB device,
> analogously to the ip/ipconfig does?  I'll be thrilled to implement
> the ideas, if you can set me on the right track.
>

I'd just modify usbd to start the driver when a device is first seen,
then the driver can be responsible for killing himself, should the device
go away. If the device comes back again, usbd could start the device
again.

Isn't that enough?

Re: [9fans] USB developments

[Fco.J.Ballesteros]

>> I'll be thrilled to implement
>> the ideas, if you can set me on the right track.

One thing you could do, if you have time now for this (I'm sorry but I don't
have it right now) is to change usbd so it just does what we've said before
in this thread. I may get a bit of time to help there, but not too much.

Re: [9fans] USB developments

[Lucio De Re]

On Thu, Jan 15, 2004 at 10:13:10AM +0100, Fco.J.Ballesteros wrote:
>
> Sure. I'm willing to open accounts here, although perhaps sources is
> a better place to do that.
>
Probably, if Bell Labs are willing and can keep it going.  Maybe
we ought to locate a mirror server for sources?  Anyone can provide
such a luxury?

> After taking a look to it all, I ended up thinking that the scheme should
> be like:
>
> #U, does mostly what it does, but stays appart of csp definitions.

Yep, sounds sensible.  But I'll get back to this in a moment.

> usbd: simply configures the device and reads a usbdb file to
> learn which program is to be used for each csp.

Mostly what I expect too, still with reservations.

> usbd: starts those programs when a new csp is noticed.

Let me call this "configure" because it needs a little bit of
thinking, in my opinion.

> drivers: are started always on a particular target, and work just
> for a particular device.
>
Presumably multiple instances if targets are duplicates.

> All of it started at boot time.
>
> For example, we have to keep an ugly sleep in boot.c to give
> usbd some time before usbhid starts. It would be better the other way.
>
I agree.  I haven't looked at your new keyboard stuff, but I plan to.

> I'd just modify usbd to start the driver when a device is first seen,
> then the driver can be responsible for killing himself, should the device
> go away. If the device comes back again, usbd could start the device
> again.
>
> Isn't that enough?

Well, my thinking (muddled as it is) was that the ATA/ATAPI driver
must somehow submit commands via the USB interface, which means that
if the ATAPI driver is not already split along these lines, it ought
to be and the top portion would then be linked to its bottom portion
or the USB driver depending on how it is to be used.

Am I making sense?

If I am, then usbd may as well spawn the command to link the top half
to the bottom half as the "configure" operation I was mentioning
earlier.

++L

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> Probably, if Bell Labs are willing and can keep it going.  Maybe
> we ought to locate a mirror server for sources?  Anyone can provide
> such a luxury?

Well, the mirror for sources is each one of our installations. :-)
Again, I could open accounts here if any of you want to do a pull from here
for whatever reasons, however, I think it's a better idea to do that from
sources.

> Well, my thinking (muddled as it is) was that the ATA/ATAPI driver
> must somehow submit commands via the USB interface, which means that
> if the ATAPI driver is not already split along these lines, it ought
> to be and the top portion would then be linked to its bottom portion
> or the USB driver depending on how it is to be used.

I had the same point of view wrt to keyboard processing. In the beginning I
kept the `top part' of the keyboard driver inside the kernel (kbdmap processing
et al.), and the `bottom part' would be either the chipset part of the driver, or
the user-level kbd driver. This was a nightmare, the usbhid had to supply scan
codes to the kernel via an added /dev/kbdin, and there were races along the way.
I just did what presotto suggested, and kept all in the user level program.

What I did was to remove the `top part' from the kernel. I moved it to the user-level
program, so that kbd processing could happen just in the user-level program (mostly).

But you still have to keep some of the top-part in the kernel, because you want
the kernet to be able to work if for whatever reason the user program is not
started.

Regarding ata, I'd say that it's best to put the top-part also within the usb
driver, and leave the kernel driver alone.

Don't know what you think about this.

Re: [9fans] USB developments

[Lucio De Re]

On Thu, Jan 15, 2004 at 12:05:14PM +0200, Lucio De Re wrote:
>
> Well, my thinking (muddled as it is) was that the ATA/ATAPI driver
> must somehow submit commands via the USB interface, which means that
> if the ATAPI driver is not already split along these lines, it ought
> to be and the top portion would then be linked to its bottom portion
> or the USB driver depending on how it is to be used.
>
As suggested by Richard Miller, I had a look at /dev/sdctl.
There'are configure() and unconfigure() functions in there that
certainly seem appropriate to our needs.  If I read it right, they
deal with the appearance and disappearance of ATA (and SCSI? doesn't
look like it, at first glance) controllers in PCMCIA (PC-Card)
format.

The corresponding /dev/sdstat, queried on my workstation, yields:

	term% cat /dev/sdstat
	sdC ata port 1F0 ctl 3F4 irq 14
	sdD ata port 170 ctl 374 irq 15

which is pretty useful, if not exactly in the format USB would
require.  Is there any documentation on this other than the source?
The source is OK, I guess, but it seldom provides rationale, which
would help me immensely.

At a guess, for correction by those in the know, I'd wish for:

	...
	sdU ata usb0/2 ...

with all sorts of complications that cause my head to hurt.  But it
won't cause any damage to fix the little comment:

	/* Try to find the card on the ISA bus.  This code really belongs
		in sdata and I'll move it later.  Really! */

(this in /sys/src/9/port/devsd.c!).  I should think that generalising
the (un)configure() functions would require producing specialised
stubs for each machine dependent or otherwise device, so the above
would be fixed as a matter of course.

++L

Re: [9fans] USB developments

[Richard Miller]

> As suggested by Richard Miller, I had a look at /dev/sdctl.

If usb mass storage needed to be "hooked" explicitly into the kernel,
that would be the place to do it.  But I wasn't suggesting that it was
the right thing to do.  I would still rather see usb mass storage
provided as a self contained file server rather than as a "driver"
wired into the kernel -- then a normal 9P interface suffices.
What's the objection to this high level approach?

-- Richard

Re: [9fans] USB developments

[Lucio De Re]

On Thu, Jan 15, 2004 at 02:05:53PM +0000, Richard Miller wrote:
>
> If usb mass storage needed to be "hooked" explicitly into the kernel,
> that would be the place to do it.  But I wasn't suggesting that it was
> the right thing to do.  I would still rather see usb mass storage
> provided as a self contained file server rather than as a "driver"
> wired into the kernel -- then a normal 9P interface suffices.
> What's the objection to this high level approach?
>
Maybe I'm just stupid, I just can't see how the high level approach
would provide the same functionality as #S without enormous repetition
as well as inefficiency on a data path that should be as fast as
possible.

- Oops, the above is a bit loaded, consider it toned down, there's
  not much "enormous" about it :-)

I also don't see that extending /sys/src/9/pc/sdata.c (and whatever
helpers apply) to deal with USB as the data path rather than the
IDE controller or, as already seems to be the case, PCMCIA devices,
would not lead to a cleaner architecture.  At some cost, without
a doubt, but making the most of Plan 9's lack of legacy would seem
appropriate here.

And as far as I am concerned, the top half of the ATAPI driver
could easily be either a kernel or a userland module, possibly even
both as is the case with your mass storage USB driver presently
and the corresponding ATAPI/SCSI functionality in the kernel.  I
want to avoid adding bulk to your driver when the functionality is
already in place in the ATAPI kernel module and I was a little
frightened when I noted that some USB/ATA interface chips do not
cope properly with SCSI commands, but implement the ATAPI ones
properly.  I may be misunderstanding matters totally, I grant, but
there aren't any shortcuts to finding out.

Or am I being utterly blind to something?  I suppose what I'm
suggesting is to streamline the kernel so the USB, PCMCIA and
IDE/SCSI bottom halves become as close to interchangeables as
possible.  It may be overkill, but once it's done, it may turn out
to be the type of investment that makes Plan 9 even more superior.

I'm curious as to whether it is even possible, but I have not heard
any strong objections yet, at least on its merit rather than on
its desirability from the point of view of minimising effort.

Sorry, the above is a bit disjointed, I hope others will be able
to piece the significant information together.  In summary, I find
USB surprisingly clean and I believe that Plan 9 is better suited
to the concept than any other OSes I am familiar with.  I need to
get more familiar with it and I'm willing to put a fair bit of
effort into it, but I'm not clever enough to do it properly without
understanding both USB and Plan 9 better.

++L

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> Or am I being utterly blind to something?  I suppose what I'm
> suggesting is to streamline the kernel so the USB, PCMCIA and
> IDE/SCSI bottom halves become as close to interchangeables as
> possible.  It may be overkill, but once it's done, it may turn out
> to be the type of investment that makes Plan 9 even more superior.

With enough effort put on that, I'd probably agree with you. However,
I think that would require a lot of effort to learn how to split them clearly
(consider that you'd want your kernel to be operational despite user programs
problems).

Given that, I'd vote for duplication of code. With some effort, the code
can be borrowed "as is", without keeping a different version.

Re: [9fans] USB developments

[Lucio De Re]

On Thu, Jan 15, 2004 at 03:56:36PM +0100, Fco.J.Ballesteros wrote:
>
> With enough effort put on that, I'd probably agree with you. However,
> I think that would require a lot of effort to learn how to split them clearly
> (consider that you'd want your kernel to be operational despite user programs
> problems).
>
OK, I'm really only interested in viability.  As long as we agree
that it is possible, I assume no one will implement USB management
that will preclude moving in the direction I advocate.
Difficult does not frighten me, short-sighted implementations do.

> Given that, I'd vote for duplication of code. With some effort, the code
> can be borrowed "as is", without keeping a different version.

I think it will need changing, but that the changes can be back
ported to the kernel.  As I mentioned, I think the separation
between userland and kernel drivers is quite blurred by them
appearing as filesystems in both cases.  There are underlying
issues, but I think the similarity is more significant.

My present plan is to strip #U to bare essentials, removing any
knowledge it may have of specific USB features and instead allowing
it to report changes to the configuration as they occur.  I'll use
usbd as the foundation for a daemon that does no more than monitor
these #U reports and allows me to add configuration and initialisation
as I grasp the details better.

++L

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> My present plan is to strip #U to bare essentials, removing any
> knowledge it may have of specific USB features and instead allowing
> it to report changes to the configuration as they occur.  I'll use
> usbd as the foundation for a daemon that does no more than monitor
> these #U reports and allows me to add configuration and initialisation
> as I grasp the details better.

Cool. Go for it.
And please, if you don't mind, drop me a line as you make progress
(no matter if it works or is flaky), so I could have the opportunity to
help if I happen to find some time.

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> I would still rather see usb mass storage
> provided as a self contained file server rather than as a "driver"
> wired into the kernel -- then a normal 9P interface suffices.
> What's the objection to this high level approach?

I'd certainly vote for this, after the usbhid experience.

Re: [9fans] USB developments

[Dan Cross]

Sorry, I've just been skimming the discussion, but I remember trying to
hook my digital camera up to my Think pad last summer and the pain that
caused.  At the time, I thought a good idea might be able to have a
/dev/sdloop (loopback device) that could speak the SCSI protocol to things
that opened it.  I never looked further at it than that.  It sounds like
what some of you guys are talking about with augmenting /dev/sdctl might
be similar.

	- Dan C.

usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Thu, Jan 15, 2004 at 10:13:10AM +0100, Fco.J.Ballesteros wrote:
>
> #U, does mostly what it does, but stays appart of csp definitions.

I presume we'll look at this later, I'm sure there's a bit of work
needed here.

> usbd: simply configures the device and reads a usbdb file to
> learn which program is to be used for each csp.
> usbd: starts those programs when a new csp is noticed.

Let me see if I understand this correctly.  I would remove the initial
configuration from the kernel driver (#U) and delay it until usbd is
activated, although it's not (yet) clear to me whether the code needs
to reside in the kernel, in which case an "enumerate" function would
be implemented in #U and would return, through the control or status
file, the list of enumerated devices, each uniquely identifiable (by
numeric index seems good enough).

Let me stop here.  Have I explained how I see things properly?  How
do others suggest I tackle the above?

Next, we need to looks at /lib/usbdb, establish s tentative format and
a set of routines to read it.  Is that what aux/vga does?  How much
can we copy from there?

I then expect the ipconfig-like operation that Richard Miller suggest
could use /dev/sdctl needs to be implemented.  As Richard suggests,
this need not happen in a first phase, although I find it hard to
implement something knowing I'll do it differently soon enough.

My vote with Nemo about the plumber, which is not to say that plumbing
is not the right principle to employ.

Here I pause.  I think I need some input before proceeding, so feel
free to mail me, privately or publicly.  If private, make sure you
let me know if you don't want to be quoted in public.  And don't count
on me not making mistakes, with advance apologies right now :-)

++L

Re: usbd - revision (Was: [9fans] USB developments)

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

I think the #U work is just to setup the bus and also to hardwire
the endpoints (i.e. to service real usb interrupts as it's doing now,
for performance). It should not depend on user programs, although
they can for sure setup the endpoints and the like.

Usbd is probably where the enumeration belongs, but I'd say that
just that. The driver is the one who knows how to configure the device,
once it has been started by usbd (which only needs to look at usbdb).

So, should we start perhaps by reworking the relationship between usbd
and the drivers? I don't really know.


[-- Attachment #2: Type: message/rfc822, Size: 4174 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: usbd - revision (Was: [9fans] USB developments)
Date: Thu, 15 Jan 2004 12:30:09 +0200
Message-ID: <20040115123004.D25947@cackle.proxima.alt.za>

On Thu, Jan 15, 2004 at 10:13:10AM +0100, Fco.J.Ballesteros wrote:
>
> #U, does mostly what it does, but stays appart of csp definitions.

I presume we'll look at this later, I'm sure there's a bit of work
needed here.

> usbd: simply configures the device and reads a usbdb file to
> learn which program is to be used for each csp.
> usbd: starts those programs when a new csp is noticed.

Let me see if I understand this correctly.  I would remove the initial
configuration from the kernel driver (#U) and delay it until usbd is
activated, although it's not (yet) clear to me whether the code needs
to reside in the kernel, in which case an "enumerate" function would
be implemented in #U and would return, through the control or status
file, the list of enumerated devices, each uniquely identifiable (by
numeric index seems good enough).

Let me stop here.  Have I explained how I see things properly?  How
do others suggest I tackle the above?

Next, we need to looks at /lib/usbdb, establish s tentative format and
a set of routines to read it.  Is that what aux/vga does?  How much
can we copy from there?

I then expect the ipconfig-like operation that Richard Miller suggest
could use /dev/sdctl needs to be implemented.  As Richard suggests,
this need not happen in a first phase, although I find it hard to
implement something knowing I'll do it differently soon enough.

My vote with Nemo about the plumber, which is not to say that plumbing
is not the right principle to employ.

Here I pause.  I think I need some input before proceeding, so feel
free to mail me, privately or publicly.  If private, make sure you
let me know if you don't want to be quoted in public.  And don't count
on me not making mistakes, with advance apologies right now :-)

++L

Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Thu, Jan 15, 2004 at 11:46:53AM +0100, Fco.J.Ballesteros wrote:
>
> I think the #U work is just to setup the bus and also to hardwire
> the endpoints (i.e. to service real usb interrupts as it's doing now,
> for performance). It should not depend on user programs, although
> they can for sure setup the endpoints and the like.
>
We have the interesting Plan 9 feature that the kernel need not be
used for separation of identity, everything the kernel can do, eve
can also do, specially as regards peripherals.  In Unix one moves
operations into the kernel as soon as they need to have more rights
than the average user.  In Plan 9 the only really reason for kernel
inclusion is efficiency: even interrupts could be handled by eve
processes.

What I'm trying to say is that we can put the bare essentials in
#U and delegate an unreasonable amount to usb/usbd.  But, to counter
this, I think enumeration, to the extent that it can be treated as
a generic operation, does belong in the kernel.  I would repeat my
suggestion that it be a #U operation triggered bu usbd, returning
a list of devices and hubs that can be used as a starting point
for further tasks.

With usb_enumerate() as a #U function, it may be possible as well
as necessary to include in the kernel code (is init(8) not a
possibility?) keyboard, screen and mouse initialisation and
configuration so as to be able to boot.  Nemo, your experience is
invaluable here, I must confess I didn't pay much attention at the
time you posted your findings as USB was nowhere on my horizon at
the time.

> Usbd is probably where the enumeration belongs, but I'd say that
> just that. The driver is the one who knows how to configure the device,
> once it has been started by usbd (which only needs to look at usbdb).
>
I think the code itself should live in #U; usbd invokes it thereafter,
the ideal time would be by blocking on a ctl read until #U detects
a bus change (is this a correct understanding?).  Usbd collects
the fresh list of hubs/functions on completion.  Mind you, #U may
as well do the enumeration itself, unblock usbd by posting the list
of

	devno -> (type, status)

on the ctl usbd is blocked on.  Too expensive, perhaps?  I'm thinking
of making the enumeration as simple as one can conceive, usbd can
then be forgiven for repeating some of the functionality.  If #U
only holds a list of 0 to 127 possible devices and an accurate
"condition", usbd can be expected to maintain the full bus description.
We can stop multiple instances of usbd occurring (we may be doing
this already?) by making sure that the #U/usbn files are single-open.

(Maybe I can try my hand at a #U that does little more than this,
right away?  Comments?)

> So, should we start perhaps by reworking the relationship between usbd
> and the drivers? I don't really know.
>
Somebody with a lot of USB experience should be looking at the
usbdb database, I think.  This is a long-term function, so it would
be nice to have a few volunteers, specially persons who already
have some experience interacting with USB device manufacturers.

I'd like to look at usbd in more detail, particularly trying to
understand how to separate its functionality along standard lines.
The device class bit is still very unclear to me, so I need to do
some further reading of the USB specification.

Those of us who have already looked at various devices may want to
suggest where they see the separation between function-specific
code and code that should be in usbd.  I'd like to hear from them
and tune usbd to suit.  This with a view to making the device driver
capable of being "mounted" on any USB stream, preferably with little
or no knowledge of the actual shape of the stream itself.  Even
the choice of alternative (the standard annoyingly adopted the
incorrect adjective "alternate" which I suppose I must force myself
to use in future) configurations should be delegated to /lib/usbdb
and usbd, in my premature opinion.

I'll dig into Richard Miller's mass-storage code and try to understand
where I'd hook into the ATAPI driver for my bit in the above.  I now
have two CBI devices, one ATA, the other flash memory card
reader/writer, so it's worth my while to do some digging.

Please keep the suggestions coming.  Specially if you see me stray off
the sensible path.  And don't let me get away with waffle, please pick
any nonsense I spout off here and correct me.

++L

Re: usbd - revision (Was: [9fans] USB developments)

[Charles Forsyth]

certainly before writing the original devusb.c,
my impression on inspecting the mess that was USB
implementation in other systems is that one ended up with
a fair number of little drivers in the kernel to handle the
peculiar dances required for each new (or broken) device.
for instance, i fail to see why talking to a Palm on USB
should need anything in the kernel, but there it is in other systems.
to paraphrase hume, crud that is dynamically-loaded is still crud.

i therefore deliberately put enumeration outside the kernel because it is (potentially)
non-trivial and recursive (so is PCI enumeration but it has
rather less to do, placing less of a strain on KSTACK).

i still think a kernel would need to interact
with a configurable user-level process (or processes) to do
enumeration properly in general.  the state required to do that
seemed to be split between kernel and process, which seemed
clumsy, compared to putting it all in user-mode.

that code still seems to me to belong beyond the `much-needed gap'.

Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Thu, Jan 15, 2004 at 12:11:38PM +0000, Charles Forsyth wrote:
>
> certainly before writing the original devusb.c,

Probably no one better qualified than you for that purpose :-)

> my impression on inspecting the mess that was USB
> implementation in other systems is that one ended up with
> a fair number of little drivers in the kernel to handle the
> peculiar dances required for each new (or broken) device.

Which is why my first thoughts were that we ought to take a peek
at brucee's work in connection with LKMs.  But we don't have to,
we can certainly interchange kernel and userland top-halfs, in my
opinion.  I gave my reasons elsewhere, but to recap, the kernel
doesn't have much greater authority than eve, so as long as eve
owns the drivers, they'll work fine except for some context switching
costs.

Still, brucee, any reason why your work is still languishing unused?

> for instance, i fail to see why talking to a Palm on USB
> should need anything in the kernel, but there it is in other systems.

Well, let's not put it in there, we get a choice, don't we?  And
we can use others' bad experiences to save ourselves blood, ssweat
and tears.

> i therefore deliberately put enumeration outside the kernel because it is (potentially)
> non-trivial and recursive (so is PCI enumeration but it has
> rather less to do, placing less of a strain on KSTACK).
>
But no more than seven deep, or is that five?  Surely we can cope?
Much more importantly, how complex is enumeration as such?  In my
extremely limited understanding, it merely needs to return (assign,
in fact) the ID of the device, its type and whether it connected
or disconnected.  And, no, I'm not sure :-)  I'm asking.  Worse,
I'm hoping.  But of course I can "just try it".

> i still think a kernel would need to interact
> with a configurable user-level process (or processes) to do
> enumeration properly in general.  the state required to do that

Well, not what you have in mind, but if usbd reads the ctl or stat
or enum file (whatever you need to call it) and configures and
initialises each device in turn (and may or may not do something
with those that have disappeared, I'm not sure whether they need
reporting by #U or can just be detected by their absence, something
probably needs to be done about them at usbd/user level), then #U
needs to do only what it knows about, which is hopefully very
little, let's call it identification and someone (me?) can document
what it should consist of.

> seemed to be split between kernel and process, which seemed
> clumsy, compared to putting it all in user-mode.
>
I ought to take your word for it, but I won't: you don't sound
convinced enough.  Now if rob or jmk were saying the same in their
somewhat very final style, I would just go hide in my corner :-)

> that code still seems to me to belong beyond the `much-needed gap'.

Flesh this out a a bit for fools like me (if there are any), please!

++L

Re: usbd - revision (Was: [9fans] USB developments)

[C H Forsyth]

>> i therefore deliberately put enumeration outside the kernel because it is (potentially)
>> non-trivial and recursive (so is PCI enumeration but it has
>> rather less to do, placing less of a strain on KSTACK).
>>
>But no more than seven deep, or is that five?  Surely we can cope?
>Much more importantly, how complex is enumeration as such?  In my
>extremely limited understanding, it merely needs to return (assign,
>in fact) the ID of the device, its type and whether it connected
>or disconnected.  And, no, I'm not sure :-)  I'm asking.  Worse,
>I'm hoping.  But of course I can "just try it".

PCI enumeration would probably become more complex
for similar reasons when hot-swapping is possible.

i'll say a bit more about the original intention, and which parts i now dislike.

i observed that the linux and freebsd (and one other i can't mention)
usb implementations were rather complex.  much of that was related
to insisting on enumerating and configuring the devices in the kernel, and there was
quite a bit of non-trivial state.

in particular, to enumerate, you typically build a tree of devices.
if you're only enumerating in the kernel
(ie, assigning IDs) then a user-level program
will do configuration.  that needs to maintain a similar tree.
if a hub is removed, you need to delete chunks of substructure
but if both kernel and usbd are keeping a tree, they'll update
at different times (eg, kernel then usbd).  alternatively, they
can exchange data to try to keep things in sync, but then there's the potential for races.

furthermore, for the purposes of IO through the kernel, the tree structure is
irrelevant, since the ID space is actually flat and only endpoints within
devices matter.

it therefore seemed more straightforward to have the user process build the only
copy of the tree (which really is needed for enumeration and hot-plugging/unplugging)
and maintain it.  it then tells the kernel to enable devices.
the kernel provides files it can read to see the status of the root hub.
it monitors the state of individual hubs itself, using a process.
(ie, usbd is the class/device-specific manager for hubs.)
it's easy for usbd to use libthread, and do quite a bit of potentially
messy error handling that again i thought would be painful in the kernel.

a device-specific device managing process can do device-specific
configuration including parsing complex structures like the HID,
and it enables endpoints, within the given device directory.

the kernel needs to manage only structures for devices and endpoints
(which believe me are complex enough), and it does that in response to
instructions from user-mode programs.  usbd is in control.

i was broadly happy with the kernel/user split, and
the overall structure.  the kernel device is essentially
an IO multiplexor and i think that's about right.  the kernel doesn't
need to know about fancy hub trees or HID descriptors,
and that also seems good to me.  (for mouse and keyboard there
are or were special boot-time modes one could use before usbd could run.)
(in fact, usbd could probably devise/check the USB IO schedule too.)

at the time i wrote it five or six years ago (!), i had trouble finding
USB devices that kept to the spec--or even correct PIIXn implementations--
and decided to do more urgent things.  that's one reason that i
never supported iso mode (someone else did that and did a lot
of work on the driver and usbd).

had i realised that i wouldn't really get back to it, i'd have made several
more passes over it then.  for instance, when i first wrote it, qio.c didn't exist in Plan 9,
and i used Stream Blocks instead.  i was never very happy with
the amount of code in the driver overall, and it was ugly.
i did have a quick go at putting Queues in properly but didn't complete it.

i was much less happy with the name space.   i think it was right
that it's flat, an array of devices (rather than attempting to mimic the connection hierarchy
which seemed an irrelevant physical detail).   the naming within
the directories is fussy, though, and the use of physical
names (device/endpoint) to access logical things such as printer
or ether is troublesome.  i thought of allowing a logical name to be created
below usb, to refer to an endpoint or endpoints,
but not having tried it, i don't know whether that would be better.
sometimes a device presents one endpoint for reading and
one for writing, but interfaces such as ethermedium expect
a single name.   there are other peculiar cases.

Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Thu, Jan 15, 2004 at 06:01:41PM +0000, C H Forsyth wrote:
>
> PCI enumeration would probably become more complex
> for similar reasons when hot-swapping is possible.
>
Naturally.  But I agree with you that the kernel view of the USB
need only be flat, not hierarchical.

> i'll say a bit more about the original intention, and which parts i now dislike.
>
Thank you.  Every bit of information will help me understand the
subject better.  There is no substitute for experience.

> i observed that the linux and freebsd (and one other i can't mention)
> usb implementations were rather complex.  much of that was related
> to insisting on enumerating and configuring the devices in the kernel, and there was
> quite a bit of non-trivial state.
>
Device configuration in the kernel strikes me as absurd unless
you're sold, as Torvald is, on monolithics.  I reserve judgement
on enumeration.

> in particular, to enumerate, you typically build a tree of devices.
> if you're only enumerating in the kernel
> (ie, assigning IDs) then a user-level program
> will do configuration.  that needs to maintain a similar tree.

I'm assuming, possibly without justification, that the in-kernel
data structure is far simpler, but I'm listening...

> if a hub is removed, you need to delete chunks of substructure
> but if both kernel and usbd are keeping a tree, they'll update
> at different times (eg, kernel then usbd).  alternatively, they
> can exchange data to try to keep things in sync, but then there's the potential for races.
>
Let's see if our paths will cross.  Kernel enumerates based on
notification (an interrupt, perhaps?) that the structure has changed.
Am I reading the spec right that enumeration is the only way to
determine the structure and that it should occur frequently?  That's
certainly what it sounds like, I'm assuming that instead of polling
one can wait for interrupts, but whichever applies, the code is no
doubt in the existing driver code already as there is nothing optional
about it.

Now, the kernel driver reports, by writing to one of its files the
new address space, optionally adding the devices that have been
dropped, it seems to me one could get away with leaving them out
and letting userland figure out for itself what has changed, but
perhaps that's suboptimal.

Userland has the only copy of the tree structure that models the
previous state of the USB and now rewalks the USB creating an up
to date copy.  Userland and the kernel have only the flat list of
devices present in common, with the kernel copy specifically kept
to the bare essentials: index, ID, type, status.s currently
applicable.

> furthermore, for the purposes of IO through the kernel, the tree structure is
> irrelevant, since the ID space is actually flat and only endpoints within
> devices matter.
>
Hence my assumption that the kernel can have a very narrow view of
it.  Userland keeps a mapping between the kernel entries and the
tree.  It rebuilds it whenever it starts up or the kernel recommends
a rescan.  It may be useful to allow user requests too.

> it therefore seemed more straightforward to have the user process build the only
> copy of the tree (which really is needed for enumeration and hot-plugging/unplugging)
> and maintain it.  it then tells the kernel to enable devices.

I imagined that the actual userland enumeration operation would be
more of bus scan in which each device is examined and if it requires
enabling, configuring or initialising, it can be done based on the
reported status change.  As long, as you suggest, that race conditions
don't cause the kernel and userland daemon to get out of sync.
Using the kernel functionality would prevent such loss of
synchronisation, in my opinion.

> the kernel provides files it can read to see the status of the root hub.
> it monitors the state of individual hubs itself, using a process.
> (ie, usbd is the class/device-specific manager for hubs.)
> it's easy for usbd to use libthread, and do quite a bit of potentially
> messy error handling that again i thought would be painful in the kernel.
>
Yes.  It doesn't take much effort for usbd to notify the kernel
when something needs kernel intervention.

> a device-specific device managing process can do device-specific
> configuration including parsing complex structures like the HID,
> and it enables endpoints, within the given device directory.
>
Here my pet obsession makes me interject that it makes little
difference whether the device managing process is kernel or userland
resident.  At the risk of showing how little I know, I suggest that
as long as usbd and the device driver exchange information via
control files, the choice remains open.  But, yes, I see that things
are not quite this straightforward.

> the kernel needs to manage only structures for devices and endpoints
> (which believe me are complex enough), and it does that in response to
> instructions from user-mode programs.  usbd is in control.
>
Sounds OK to me.  The devil will no doubt be in the details.

> i was broadly happy with the kernel/user split, and
> the overall structure.  the kernel device is essentially
> an IO multiplexor and i think that's about right.  the kernel doesn't
> need to know about fancy hub trees or HID descriptors,
> and that also seems good to me.  (for mouse and keyboard there
> are or were special boot-time modes one could use before usbd could run.)
> (in fact, usbd could probably devise/check the USB IO schedule too.)
>
Enter Nemo.  I'll leave him to comment, I'm just a poorly informed
spectator.

> at the time i wrote it five or six years ago (!), i had trouble finding
> USB devices that kept to the spec--or even correct PIIXn implementations--
> and decided to do more urgent things.  that's one reason that i
> never supported iso mode (someone else did that and did a lot
> of work on the driver and usbd).
>
Complaints about spec conformance still abound, but it is purely
a matter of dealing with each quirk.  It's O(n) unless somebody
wants to produce a single driver for all devices.  Quirk descriptions
can bring it down to O(log n) if tracking all the different VID/DID
or serial numbers etc. becomes too painful.  Keep in mind that XP
deals with it, why shouldn't Plan 9?

> had i realised that i wouldn't really get back to it, i'd have made several
> more passes over it then.  for instance, when i first wrote it, qio.c didn't exist in Plan 9,
> and i used Stream Blocks instead.  i was never very happy with
> the amount of code in the driver overall, and it was ugly.
> i did have a quick go at putting Queues in properly but didn't complete it.
>
Noted, even though I understand very little of it :-)

> i was much less happy with the name space.   i think it was right
> that it's flat, an array of devices (rather than attempting to mimic the connection hierarchy
> which seemed an irrelevant physical detail).   the naming within
> the directories is fussy, though, and the use of physical

I wasn't going to say so, at least not until I was a lot more
comfortable, but I agree.  Could I ask you to put some thought into
that, I can do the implementation.  Like passing a string to the
kernel to do the prefixing or suffixing?  ep3data is a terrible
name for a mass-storage interrupt pipe and mv ep3data intrpipe
isn't likely to work, either.

> names (device/endpoint) to access logical things such as printer
> or ether is troublesome.  i thought of allowing a logical name to be created
> below usb, to refer to an endpoint or endpoints,
> but not having tried it, i don't know whether that would be better.

It sounds a lot more liveable with, if nothing else.

> sometimes a device presents one endpoint for reading and
> one for writing, but interfaces such as ethermedium expect
> a single name.   there are other peculiar cases.

They strike me as needing more of a policy than much hard implementation
effort, but you're the one with the T-shirt :-)

Based on the NetBSD philosophy, I can safely claim that #U is
optional and therefore it can be bloated, at least while still
under development.  I would prefer not to have to list all the
possible devices at kernel compile time (can you say distribution?)
which weighs seriously in favour of userland drivers, but I still
believe that brocee's work should be reconsidered.  Specially if
it then involves a merger of technologies rather than a switch of
philosophy.

Thanks, Charles.  I wish you had more time to spend explaining #U
to me (usbd I can grasp, I think), you and whoever added that
seeming extremely complex paradigm of isochronous transfer.  This
last message surely covered a lot of ground, but also exposed a
glimpse of the real complexity lurking.

++L

Re: usbd - revision (Was: [9fans] USB developments)

[Charles Forsyth]

>>Let's see if our paths will cross.  Kernel enumerates based on
>>notification (an interrupt, perhaps?) that the structure has changed.
>>Am I reading the spec right that enumeration is the only way to
>>determine the structure and that it should occur frequently?  That's
>>certainly what it sounds like, I'm assuming that instead of polling
>>one can wait for interrupts, but whichever applies, the code is no
>>doubt in the existing driver code already as there is nothing optional
>>about it.

no.  in UHCI you can get interrupts for the notional `root hub' but
that's because it's notional.  it's not a USB hub.  you can't talk to
it as though it's a USB hub.  there are some strange registers.
otherwise, for a real hub, you must periodically
use a USB transaction on the hub's control endpoint to poll for changes
to the status of its ports.  there is no code in the existing driver to
poll, but that's precisely because it leaves that to usbd, which anyway
needs to poll for other changes in configuration.

you need the tree structure because that reflects the physical connection
structure.  when a hub goes, it takes all the connections through it,
including directly-connected devices, other hubs, their devices, and so on.

i just don't see why it's so important to you that the kernel enumerate
(if it doesn't configure, and if it does configure, it needs to know much
more about the class, and since classes are often 0, the device).

>>or serial numbers etc. becomes too painful.  Keep in mind that XP
>>deals with it, why shouldn't Plan 9?

because many manufacturers write special USB drivers that
deal with the peculiar/proprietary protocol used by their device!
it's no different in that regard from VGA (or VESA)

>>believe that brocee's work should be reconsidered.  Specially if

it has been, but that's not really a key to this discussion.
it might indeed be useful to load USB-device-specific modules into
the kernel, in the same way that Etherif components might be loaded,
but that doesn't seem to me to be the determining aspect.

the naming problem isn't that usb1/2/ep3data (say) is a funny name:
at that level it's as good as any other existing one (eg, eia0, sdD0).
the trouble is that for hardwired devices,
it's not too bad to name them by physical
connection (and that's to some extent unambiguous), since it's
long-lived enough to associate with some higher-level notion
(eg, my printer is on lpt0), but
for dynamically-connected devices, the physical connection name
is still unambiguous, but much less useful, since the printer
now is usb0/3/ep2data but in a little while it's usb1/2/ep2data,
depending on which USB slot on my thinkpad i chose.
(in fact, for USB it's worse because the /2/ and /3/ there are
dynamically assigned and unpredictable.)

that's possibly where a link to (something like) plumbing might
be relevant because it might be adequate to be able to say
`if there's a printer on the USB bus, that's the one' or even
`if there's an HP printer, that's the laser printer, but
if there's an Epson that's the photo printer'.

Re: usbd - revision (Was: [9fans] USB developments)

[Micah Stetson]

> the naming problem isn't that usb1/2/ep3data (say) is a funny name:
> at that level it's as good as any other existing one (eg, eia0, sdD0).
> the trouble is that for hardwired devices,
> it's not too bad to name them by physical
> connection (and that's to some extent unambiguous), since it's
> long-lived enough to associate with some higher-level notion
> (eg, my printer is on lpt0), but
> for dynamically-connected devices, the physical connection name
> is still unambiguous, but much less useful, since the printer
> now is usb0/3/ep2data but in a little while it's usb1/2/ep2data,
> depending on which USB slot on my thinkpad i chose.
> (in fact, for USB it's worse because the /2/ and /3/ there are
> dynamically assigned and unpredictable.)

It might be noted that even XP has difficulty with this.
I have a USB 802.11b interface that was configured while
plugged into one USB slot on my wife's laptop.  If I plug
it into the other slot, Windows has no clue that it's
the same device and wants me to re-enter all of the
network config information (SSID, passphrase, etc.).
It's annoying, and it would be nice if Plan 9 got it
right.

Micah

Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Thu, Jan 15, 2004 at 08:24:12PM +0000, Charles Forsyth wrote:
> otherwise, for a real hub, you must periodically
> use a USB transaction on the hub's control endpoint to poll for changes
> to the status of its ports.  there is no code in the existing driver to
> poll, but that's precisely because it leaves that to usbd, which anyway
> needs to poll for other changes in configuration.
>
I assumed polling would best be a kernel function, but I can see
that there are different views.  I'll go along with usbd doing it,
it seems most appropriate here.

> you need the tree structure because that reflects the physical connection
> structure.  when a hub goes, it takes all the connections through it,
> including directly-connected devices, other hubs, their devices, and so on.
>
I have to agree.  My assumption was that usbd would do that, on #U
reporting that there has been a change.  You make a very strong case
for it not working.

> i just don't see why it's so important to you that the kernel enumerate
> (if it doesn't configure, and if it does configure, it needs to know much
> more about the class, and since classes are often 0, the device).
>
I'm not sure why it was so important, but it may come back and bite
me.  Still, your arguments are presently unassailable.

> >>or serial numbers etc. becomes too painful.  Keep in mind that XP
> >>deals with it, why shouldn't Plan 9?
>
> because many manufacturers write special USB drivers that
> deal with the peculiar/proprietary protocol used by their device!
> it's no different in that regard from VGA (or VESA)
>
No, no, no.  I'm thinking USB here, not function.  I suppose there
may be hubs that are also broken, but these are all special cases,
they mustn't get mixed up in the minestrone.  My beef is that I
want the bus management to match the specs as accurately as possible,
on the assumption that the bus is OK.  Device drivers, quirks and
databases will handle functions and all their foibles.  It should
not be necessary to alter the bus drivers to deal with them, except
perhaps to implement the quirk - but at least it's then a few
generic operations, not a mass of special cases.

> >>believe that brocee's work should be reconsidered.  Specially if
>
> it has been, but that's not really a key to this discussion.
> it might indeed be useful to load USB-device-specific modules into
> the kernel, in the same way that Etherif components might be loaded,
> but that doesn't seem to me to be the determining aspect.
>
See, you agree with me :-)

> ... since the printer
> now is usb0/3/ep2data but in a little while it's usb1/2/ep2data,
> depending on which USB slot on my thinkpad i chose.
> (in fact, for USB it's worse because the /2/ and /3/ there are
> dynamically assigned and unpredictable.)
>
Yep, a point I could have made, had I thought things out instead
of shooting from the hip.  Again, the database should contain enough
information to give various devices sensible prefixes or suffixes
and the daemon can assign them instance indices which might suffice.
A naming scheme is nothing more than a naming scheme, /lib/ndb can
deal with local conventions.

> that's possibly where a link to (something like) plumbing might
> be relevant because it might be adequate to be able to say
> `if there's a printer on the USB bus, that's the one' or even
> `if there's an HP printer, that's the laser printer, but
> if there's an Epson that's the photo printer'.

Plan 9 is a little too tightly coupled to its conventions, but I'm
sure the naming scheme will soon settle into something workable
for most and flexible enough for the few exceptions to be managed.

++L

Re: usbd - revision (Was: [9fans] USB developments)

[Fco.J.Ballesteros]

>> i was broadly happy with the kernel/user split, and
>> the overall structure.  the kernel device is essentially
>> an IO multiplexor and i think that's about right.  the kernel doesn't
>> need to know about fancy hub trees or HID descriptors,
>> and that also seems good to me.  (for mouse and keyboard there
>> are or were special boot-time modes one could use before usbd could run.)
>> (in fact, usbd could probably devise/check the USB IO schedule too.)
>>
> Enter Nemo.  I'll leave him to comment, I'm just a poorly informed
> spectator.

Regarding the hid, there's nothing special. It works in a back-compat
mode (boot mode) while the system gets up, to allow you to type.
Roughly, when usb gets up, it assumes that the system can speak its
usb protocol and switches to it. The only special thing is that hid introduced
the need to start usbd and usbhid at boot(8) time, since you must
mount the new /dev/cons (fake) device before anyone opens it.

But regarding this discussion, it's just another regular usb driver.

Re: usbd - revision (Was: [9fans] USB developments)

[Fco.J.Ballesteros]

Besides usbd / driver issues, there's an interesting idea from paurea
that I think is worth raising here.

Since you may have a resource (say a mouse) that speaks the same
protocol and is to be handled in the same way in several different devices
(say usbmouse and usbhid). it might have sense to split the driver level
in two parts so that:

- usbd starts device drivers
- device drivers configure the devices and locate resources
- resource drivers speak the protocols and provide the services
 (perhaps this third level could be just a library and not a different process).

Paurea's aim was to share the code for stuff found in multiple kind of
devices.

Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Fri, Jan 16, 2004 at 08:38:46AM +0100, Fco.J.Ballesteros wrote:
>
> Besides usbd / driver issues, there's an interesting idea from paurea
> that I think is worth raising here.
>
Keep them coming!

> ...
> - resource drivers speak the protocols and provide the services
>  (perhaps this third level could be just a library and not a different process).
>
> Paurea's aim was to share the code for stuff found in multiple kind of
> devices.

Sounds like it ought to be some sort of protocol multiplexor, at
first glance.  Could be useful, specially if one can manage with
or without it.  Let's say I like the idea and I imagine it can be
made an objective without having to implement it immediately.

In a way I'm glad 4ed Plan 9 no longer supports kernel streams,
otherwise we'd be tempted to use them :-)

++L

Re: usbd - revision (Was: [9fans] USB developments)

[Bruce Ellis]

usb ends in tears because the vendors are quite happy to
send undocumented stuff to undocumented ports.  and it's
fine 'cause they have a windows driver for it.

dhog spend some lazy time trying to decypher an audio
device of mine (either the extigy or the sound canvas).
yes - he wrote a lot of code to get thru the tree, and
scribbled a diagram for me - had to cram to fit it on
a page.  lots of undocumented ports in the storm.

so i still run usb devices off a windows box and inferno
serves me the multimedia crap that i have no idea how
to get out of the device.

i'm glad that there is p9 support for the standard usb
stuff, mouse - kbd - massstore; and encourage it.

it makes video card support look easy?

brucee

Re: usbd - revision (Was: [9fans] USB developments)

[Lucio De Re]

On Fri, Jan 16, 2004 at 09:23:16PM +1100, Bruce Ellis wrote:
>
> usb ends in tears because the vendors are quite happy to
> send undocumented stuff to undocumented ports.  and it's
> fine 'cause they have a windows driver for it.
>
Maybe I'm just farting in the wind, but imagine that Plan 9 had a
USB infrastructure that "just worked".  So much so that device
vendors would not need to provide device drivers for their units,
they could rely on Plan 9 to supply the driver on condition they
tighten up slightly on their design.  To a clear, simple spec.

Wouldn't that annoy Microsoft?

++L

Re: usbd - revision (Was: [9fans] USB developments)

[boyd, rounin]

> Maybe I'm just farting in the wind, but imagine that Plan 9 had a
> USB infrastructure that "just worked".

imagine 'thing' that '"just worked"  -- it's non trivial.

Re: usbd - revision (Was: [9fans] USB developments)

[Richard Miller]

> Maybe I'm just farting in the wind, but imagine that Plan 9 had a
> USB infrastructure that "just worked".

The #U infrastructure "just works" now, as far as I can tell.  The
problem is lack of drivers for devices.

-- Richard

Re: usbd - revision (Was: [9fans] USB developments)

[Bruce Ellis]

and as i said - the vendors delight of secrecy.
you can't support a device if you can't find the
secrets to their proprietary carp.

----- Original Message -----
From: "Richard Miller" <rm@hamnavoe.com>
To: <9fans@cse.psu.edu>
Sent: Friday, January 16, 2004 10:45 AM
Subject: Re: usbd - revision (Was: [9fans] USB developments)


> > Maybe I'm just farting in the wind, but imagine that Plan 9 had a
> > USB infrastructure that "just worked".
>
> The #U infrastructure "just works" now, as far as I can tell.  The
> problem is lack of drivers for devices.
>
> -- Richard

Re: usbd - revision (Was: [9fans] USB developments)

[rog]

> you can't support a device if you can't find the
> secrets to their proprietary carp.

i knew that companies were producing genetically engineered
fish these days, but i have to say the link to USB devices
is a new one on me...

Re: [9fans] USB developments

[Charles Forsyth]

>>BTW, the specs in the usb web site are pretty complete.

adequate if your device adheres to the spec;  storage devices tend to do that.
most of the video/audio devices i tried previously did not,
at least to the extent that some of the interesting features used
undocumented schemes.

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> adequate if your device adheres to the spec;  storage devices tend to do that.
> most of the video/audio devices i tried previously did not,
> at least to the extent that some of the interesting features used
> undocumented schemes.

Our touch screen is mostly out of the standard, but (thanks to usb!) the
protocol was quite easy to learn from what we could read from the device.
We have included the support in usbhid, but have not made it public because
I think we're violating the standard just to make this work. BTW, it's an LG
L1510SF. I wouldn't buy such model in the future.

Re: [9fans] USB developments

[Lucio De Re]

On Thu, Jan 15, 2004 at 09:07:35AM +0000, Charles Forsyth wrote:
>
> >>BTW, the specs in the usb web site are pretty complete.
>
> adequate if your device adheres to the spec;  storage devices tend to do that.
> most of the video/audio devices i tried previously did not,
> at least to the extent that some of the interesting features used
> undocumented schemes.

In some cases, the spec is too lax, like where, apparently, a
10-byte ATAPI request is accepted, but an equivalent 6-byte SCSI
one isn't.  I believe the spec does not enforce the compatibility.

But these things don't stop one providing the infrastructure, the
quirks just need to be assimilated in as general a manner as
possible, and documented.

++L

Re: [9fans] USB developments

[Richard Miller]

>> adequate if your device adheres to the spec;  storage devices tend to do that.
> ...
> In some cases, the spec is too lax, like where, apparently, a
> 10-byte ATAPI request is accepted, but an equivalent 6-byte SCSI
> one isn't.

Another example: some devices crash if you send a ScmdStart.
Others won't work unless you send one.

-- Richard

Re: [9fans] USB developments

[Richard Miller]

> My immediate question is whether it makes sense and is even possible
> to imitate the behaviour of ip/ipconfig in the case of USB and, in
> the instance I have in mind, mount the IDE driver (or the SCSI
> driver or the generic "sd" driver, whichever comes closest after
> making the necessary adjustments) on the appropriate desired port,
> as ipconfig does with etherx and the TCP/IP stack?

There's a /dev/sdctl file which appears to be provided just this
sort of purpose.  But I found with the usb mass storage driver that
(nearly) everything can be done quite comfortably outside the kernel.
The awkward part of course is hot plugging.

I think usbd is already doing all the necessary work of noticing
when usb devices come and go.  If it communicated this information
to the rest of the world with attach/detach messages on a plumbing port,
then either individual drivers could watch for their devices appearing,
or a "hotplug manager" could load the relevant driver on demand (maybe
this could be accommodated within the plumber itself with "plumb start"
rules).

-- Richard

Re: [9fans] USB developments

[Fco.J.Ballesteros]

> I think usbd is already doing all the necessary work of noticing
> when usb devices come and go.  If it communicated this information
> to the rest of the world with attach/detach messages on a plumbing port,
> then either individual drivers could watch for their devices appearing,
> or a "hotplug manager" could load the relevant driver on demand (maybe
> this could be accommodated within the plumber itself with "plumb start"
> rules).

Hmm. I'd prefer to keep plumber out of the way here. All in all, there's no
`user preferences' regarding how to handle a device, the device is likely
to have just its driver, and usbd is the one who could know that such
driver has to be started. A usbdb file (a la vgadb) would suffice.

Re: [9fans] USB developments

[boyd, rounin]

i know sod all about USB but am in a postition to maybe mess
with it.  i also have this idea for venti that could be commercialised,
but it's a bit tricky.

i have to talk/work to/with a mate.