Subject: Re: ucycom driver
To: Nathan J. Williams <>
From: Bill Studenmund <>
List: tech-kern
Date: 05/12/2005 10:33:55
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 12, 2005 at 01:11:09PM -0400, Nathan J. Williams wrote:
> Bill Studenmund <> writes:
> > On Thu, May 12, 2005 at 03:31:35PM +0200, Quentin Garnier wrote:
> > >=20
> > > Of course, I'm really no expert of the USB code, so I might be missing
> > > something.
> >=20
> > 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 =
> > 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.

Did you miss the "naive user" part above? :-)

If shoving this driver into ucom would end up bulldozing both, then let's
not do it. However Quentin's comments indicated that it might be adding a
few simple abstractions to make it all work. And it sounded like Nick=20
hadn't explored that possibility. All I'm asking is "Please explore that=20

If it doesn't work, it doesn't work, and we add a new major number for=20
this device.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)