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
usb2.

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
down.
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
issue.

Guys.. is there any reason why this needs to be rushed in over the
Christmas
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
believe
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
so.

Joe


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 www.freebsd.org 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.

Sam
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: The Anti Alts who have been here for years.
    ... any kind of attention will do. ... being the true reason. ... naively posted some pro Homeopathy comments. ... feel THREATENED by almost any alternative medicine ...
    (misc.health.alternative)
  • Re: Quitting 3.5
    ... that have absolutely no reason to let the fights be anything like fair. ... And the immediate lieutenant is not paying attention to ... the gang of trouble-seekers that we call an adventuring party doesn't ... Sauruman the White, Maiar and wizard ...
    (rec.games.frp.dnd)
  • Re: IMPLICIT NONE (F2k8+/-)
    ... The assertion that there is absolutely no good reason to continue with a convention that has served Fortran for 50 years, is itself, no good reason for change. ... Those of us who like implicit typing find that we can instantly recognize the type of a variable from its initial letter, provided that explicit typing has not been turned on. ... We have to conclude that only single variables are susceptible to mistyping and not being trapped. ... IMPLICIT NONE is the case that could be selected by a compiler switch, as the user of this option will have declared the type of every variable explicitly, and other than the case where the programmer has made an error, it is immaterial whether or not it is used. ...
    (comp.lang.fortran)
  • Re: The mechanism behind bouncing...
    ... I just wish to know the precise reason why for example, ... noise-free source like a mechanical switch. ... They do not scale with voltage? ... Your logic is like saying a resistor behaves exactly the same no matter what ...
    (sci.electronics.basics)
  • Re: whats the ifc corresponding argument for -bp in absoft f90
    ... > The problem is dsinwhere y is a single precision floating point while ... Guess I have to ask why you don't just fix the code? ... Is this the *ONLY* reason you are using the -dp option? ... I wouldn't guarantee that it necessarily has such a switch. ...
    (comp.lang.fortran)