--a2FkP9tdjPU2nyhF
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 <wrstuden@NetBSD.org> writes:
>=20
> > 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 =
it,=20
> > please do. :-)
>=20
> 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.
>=20
> 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
possibility."

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

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCg5OCWz+3JHUci9cRAkYDAJ9zGAmXW3miB2Cf79nDn61XYxQ99QCgiOHS
m4Ao1VY7S0aRbtXVf2Ghjns=
=y9k2
-----END PGP SIGNATURE-----

--a2FkP9tdjPU2nyhF--