cvs commit: src/sys/dev/usb uhid.c

[M. Warner Losh]

In message: <20040627011551.F666 at korben.in.tern>
            Lukas Ertl <le at FreeBSD.org> writes:
: On Sat, 26 Jun 2004, M. Warner Losh wrote:
: 
: > : BTW, we should probably split up the uhid driver like NetBSD did with
: > : uhidev.
: >
: > Agreed, to a point.  There's a number of issues with how the ucom
: > stuff was split out and I'd like to make sure that we don't repeat
: > those mistakes...
: 
: Interesting... could you please point out what these issues were?

The split didn't use device_t at all.  That makes it hard to know what
driver really attached.  You only see ucom in the dmesg.  It is too
much like the NetBSD config system, and not enough like FreeBSD.

Tell me, which driver attached to my phone:

ucom0: Sanyo Electric Sanyo SCP-4900 USB Phone, rev 1.01/0.00, addr 2, iclass 2/2
ucom0: data interface 1, has CM over data, has break
ucom0: status change notification available

No fair grepping to find out where 'has CM over data' is printed.

Also, in devinfo, it shows up wrong:

          usb1
            uhub1
              ucom0

You have no clue that this is umodem, or uplcom or something else.  My
phone is umodem, and my brother's phone is ulpcom (same carrier,
slightly different model).

I do like the fact that all the usb com ports are presetned to
userland as ucom, but I really dislike the fact that the real driver
is hidden.

On NetBSD, the separation is explicit:

umodem0 at uhub3 port 2 configuration 2 interface 0
umodem0: Sanyo Electric Sanyo SCP-4900 USB Phone, rev 1.01/0.00, addr 2, iclass 2/2
umodem0: data interface 1, has CM over data, has break
umodem0: status change notification available
ucom0 at umodem0

We should do that on FreeBSD as well.  NetBSD does something similar
for uhiddev and uhid,ums,ukbd.  All I'm trying to say is that we
should do it with device_t's that are visisble to the rest of the
system and not collapse it down like we bogusly do now for ucom.

There are a number of other issues with usb integration into FreeBSD
as well.  The biggest one is that you can't kldload a driver AFTER the
device has been plugged into the bus.  This is even true if you omit
ugen from the kernel so nothing is attached to that child.  I'm
working on the ugen problem (there are issues with acpi that preclude
my committing the fixes), but no one has done anything on the rescan
problem :-(.

Warner