DragonFlyBSD

Yes, but it seems that you didn't care about changes we have made locally
or brought in from other BSD's? I just checked quickly the change I
remember doing for sure -
http://www.dragonflybsd.org/cvsweb/src/sys/bus/usb/uhub.c.diff?r1=1.19&r2=1.20&f=h

So, before it goes in, it should be very carefully audited, please.

And please stay away from USB serial stuff while going to sync device
drivers. These are in much better shape in DragonFly than in FreeBSD. I
wouldn't mind at all (no, I'd love to see that, really) if someone would
sync ucom(4) itself with FreeBSD, but it would require to merge changes
from tty(4) as well I'm not familiar at all.

It's a diff between synchronized DragonFly (ie. the first patch applied)
and FreeBSD current?

Good work, anyway.

Hasso Tepper wrote:
> Michael Neumann wrote:
>> A patch (usb.diff) that brings in all recent FreeBSD-current USB
>> changes (no devices yet). Tested on two laptops and qemu. All three
>> paniced before with the same message as in this thread:
>>
>> http://leaf.dragonflybsd.org/mailarchive/kernel/2007-11/msg00034.html
>>
>> This should be easily reproducable using qemu with -usb and -usbdevice
>> options.
>>
>> After the patches, all three boot up and I can use USB without
>> problems. One problem is not yet fixed: When I boot with a USB device
>> connected, it sometimes hangs.
>
> Yes, but it seems that you didn't care about changes we have made
locally
> or brought in from other BSD's? I just checked quickly the change I
> remember doing for sure -
>
http://www.dragonflybsd.org/cvsweb/src/sys/bus/usb/uhub.c.diff?r1=1.19&r2=1.20&f=h
>
> So, before it goes in, it should be very carefully audited, please.

Yes, I just upgraded it to the FreeBSD code base, with the (possibly
wrong) assumption that the FreeBSD code base will pull in code from
other BSDs, so that we don't have to do it manually. I didn't want to
spend or duplicate too much effort.

If changes are done in the DragonFly USB version, it would be nice to
mark them as DragonFly-specific in the code, so that getting newer stuff
from FreeBSD into DragonFly would become easier and patching can be done
semi-automatically.

The correct way would be to ask FreeBSD to pull in those changes, so
that we can gain from it without much effort. On the other hand, it
would be great to refactor the FreeBSD code, but then we have to spend a
lot of time now and later (is it really worth for USB?).

> And please stay away from USB serial stuff while going to sync device
 > drivers. These are in much better shape in DragonFly than in FreeBSD. I
 > wouldn't mind at all (no, I'd love to see that, really) if someone would
 > sync ucom(4) itself with FreeBSD, but it would require to merge changes
 > from tty(4) as well I'm not familiar at all.

Okay :)

I'm just learning and this got me a bit deeper into DragonFly. And then,
the final goal is to be able to run DragonFly again on this laptop.

>> The second diff (freebsd.usb.diff) is against FreeBSD-current as of
 >> yesterday.
 >
 > It's a diff between synchronized DragonFly (ie. the first patch applied)
 > and FreeBSD current?

Exactly.

There are some open issues, like specifying a lock in bus_dma_create_tag
etc.

> Good work, anyway.

Your welcome (to test ;-)

Regards,

Michael

Well, we made a lot of stability fixes to USB that FreeBSD never had,
and still doesn't. We have to retain all of that work or we'd be going
backwards. In particular we made changes that allow USB devices to be
pulled and plugged in willy nilly without crashing the machine, and
that's an important feature.

I think a more careful examination and incremental commit of the patch
    is in order.  I see some obvious improvements, but stuff is also missing.

That said, the patches are only 160K each, it should be possible to audit
    them.

-Matt

The best approach to this might be to audit and commit in small chunks,
to reduce the remaining diff set size.

Hey Michael, how would you like a commit bit?  I'll send you some
    private email w/ details.

-Matt