getting vendor IDs

[M. Warner Losh]

In message: <200412250207.iBP27mQ40936 at Mail.NOSPAM.DynDNS.dK>
            Barry Bouwsma <freebsd-misuser at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> writes:
: 
: On Fri, 24 Dec 2004 15:52:18 -0700 (MST), "M. Warner Losh" wrote:
: 
: > : In such a case, the only thing I can see doing is to provide the
: > : end-product description as part of the vendor product, for NetBSD.
: > : Which will be rather a lot of work, but when you have the case of
: > : some unfamiliar-to-consumer's chip in a well-known camera case,
: > : I don't see an easy way to keep the descriptions short yet clear.
: 
: > I don't understand what you are saying at all.
: 
: Sorry, I'll try again.  Since NetBSD uses these strings, I want to
: make them match the device a bit more, especially for cases where
: the descriptor string is deficient.  That's the case with my camera,
: which is just `CAMERA' according to the internal vendor string,
: if I remember.

But NetBSD only uses these strings if there's no driver to claim the
device.  Otherwise, it uses the same method as FreeBSD.

: Of course, I need to look where NetBSD uses the product's string,
: and where it refers to the table from usbdevs, to see where it
: matters.  It's not in the boot-time messages for an attached
: device, though, as my uaudio vendor wasn't identified with
: uaudio present in my NetBSD kernel.

Yes.  It is better to know and understand where NetBSD uses things
before going off on assumptions.

: I'm hoping to introduce coordination, to reduce the differences
: between the files that make keeping up-to-date more of a hassle
: than it should be.  As in this case, the BSDen share a common
: base (unlike, say, uaudio where there are significant differences,
: or more specifically, the audio infrastructure in general), I
: don't see a reason why all the BSDen can't draw from a single
: source that's synchronized between them, for the data within,
: that doesn't change between OSen.

I think I made my point badly: NetBSD developers do not coordinate
things well, so there tends to be a lot of different conventions in
place.

: I'm thinking of the two devices I showed earlier (mouse and uaudio
: device) that were missing vendor strings, and in part a product.
: If this information can't be pulled from the device itself, in
: hopefully relatively few cases, my feeling is it would be good to
: fall back on a database which provides more than just the vendor
: and product numbers.
: ums0: vendor 0x062a product 0x0000, rev 1.10/0.00, addr 4, iclass 3/1

That code is already in place.  Please, go look at the code before
speculating.

Warner