Bill Studenmund <wrstuden@NetBSD.org> writes:

> On Thu, May 12, 2005 at 03:31:35PM +0200, Quentin Garnier wrote:
> > On Thu, May 12, 2005 at 11:39:27AM +0100, Nick Hudson wrote:
> > 
> > While reading the code, though, I was wondering how difficult it would
> > be to have an ucom(4) attaching to this device instead of mostly
> > replicating all the code.  AFAICT, it should be possible to do that by
> > adding a few methods to ucom_methods and making ucom(4) use them
> > instead of making calls to usbd_* at the relevant places.
> > 
> > That would save you a lot of documentation as to where to find the
> > relevant device node, at least ;)
> > 
> > Of course, I'm really no expert of the USB code, so I might be missing
> > something.
> 
> I too have to ask why not have this attach as some sort of ucom. I know
> very little about the USB code, but as a naive user, I'd expect a
> USB<->Serial thingie to use the ucom device node. :-) So if you can do it, 
> please do. :-)

The ucom layer is not, in fact, a universal "usb serial" layer; it
just happens to be a convenient abstraction for some devices. It makes
some pretty strong assumptions about how the underlying USB device
exposes its serial stream (for example, that there's exactly one bulk
pipe each way). Thus, it's entirely reasonable that a device that
doesn't line up with ucom's assumptions shouldn't use it.

If you think ucom *should* be a universal "usb serial" layer, I'd like
to know why we should have more than one tty device node/major number
anywhere in the tree.

        - Nathan