Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks.

Remko Lodder wrote:

On Dec 23, 2008, at 6:50 PM, Joe Marcus Clarke wrote:

Wilko Bulte wrote:
Quoting Rink Springer, who wrote on Tue, Dec 23, 2008 at 05:23:36PM
+0100 ..
Hi people,

On Mon, Dec 22, 2008 at 01:40:10PM -0800, Alfred Perlstein wrote:
We're going to usher in the New Year with a new usb stack.

Now is the time to test, test, test.

It is also the time to point out anything missing from usb2 that
is in usb1.

In two weeks, on Jan 3rd I will switch the GENERIC kernel to use

The old usb code will remain in case there is any fallout.

Depending on how this trial goes we will hopefully move to the new
stack entirely within a few weeks after bug reports start dying
For what it's worth, I think this is *way* too early to be even
considering this; there is still massive fundamental work being
performed on the new stack (which reminds me that I really should get
back to my permission patches soonish), but that is not the only

Guys.. is there any reason why this needs to be rushed in over the
break? Getting it in the tree, fine. But making USB2 the default so
quickly does not appear to be proper engineering procedure.

The days that CURRENT was broken for long periods is not something the
project wants to get back to. The discussions sofar do not make me
this will be a smooth transition, it seems it will need testing and
fixing for
a reasonable (considerable?) period.

Agreed. For desktop users, sysutils/hal is currently broken with usb2.
It's on my todo list to fix, but I may not have time to do it in the
next two weeks. I know this may seem minor considering other issues,
but people used to automounting USB media in their desktop won't think


Given the amount of problems that there are reported on various sources
(usb->serial converters not working etc), I think we should provide a
base where at least 95% of the things that we ship are working by
default. I have seen advises that we should disable some kernel builds
and add stuff via modules. I do not think that is the way to go for
something which people normally 'take for granted'.

I would like to see the code mature in the current form, gets it's
developer attention and updates (and yeah there might be painful
updates, even for hps, live with them in order to get this thing going
as strong as possible).

In the past (imo) we had several project sites on that
listed our projects, and the milestones to take and open items. Is it an
idea to send doc@ (or me whatever) a list of open items that need
attention, that we document on the site, and only change default
behaviour if enough bullets had been fired (read: if enough items had
been fixed). That way there is a hardcopy of what needs attention, it's
clear for anyone which items that need attention, and if everyone steps
up, there is no one that can complain that his arguments aren't listed
there and no one that can say that he/she didn't know about the arguments.

I'll offer a different POV. I think we should switch ASAP and resolve
open issues (so long as the old code is kept around for folks to fall
back on). We cannot ship 8.0 w/ 2 stacks and delaying the inevitable
will only leave unknown issues closer to the release date and
potentially delay/extend the release process. I said this when the code
was first committed and feel even more strongly now. Of course all this
depends on developers stepping up and fixing problems. IMO we cannot
depend on this code if it is treated purely as vendor-contributed code.

The only reason I can see for not switching are important regressions in
functionality (both in the kernel and user programs) or security issues.
It sounds like there are reasons to not switch now but I think we need
to move ASAP.

freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"