usb4bsd patch review [was Re: ...]
Hans Petter Selasky
hselasky at c2i.net
Wed Aug 20 16:07:42 UTC 2008
On Tuesday 19 August 2008, Kris Kennaway wrote:
> Hans Petter Selasky wrote:
> >> This raises the question of why the kernel changes need to be committed
> >> now, and what benefit they bring in the absence of a compatible
> >> userland. Shouldn't the commit happen after both kernel and userland
> >> are ready (and reviewed)?
> > I think that is correct.
> OK, so does this mean we should expect to see a revised commit candidate
> patch from you and/or alfred later once that is finished?
Alfred, I leave this up to you.
> You could look at what the sound code does, (I think it is specifically
> the snd_driver module). This implements auto-loading of the "right"
> drivers by loading them and then unloading the ones that don't attach.
> This still has overhead though, so users often will just compile in the
> ones they know they have.
> >> Also is it safe to drop and reacquire the lock here?
> > You have to drop the lock, else I get witness warnings.
> Yes, and presumably rightly so. It doesn't mean that dropping the lock
> and later reacquiring it is safe though; it could introduce races.
Yes, I know.
> OK, this seems unrelated to USB then and is something you should discuss
> with the sound maintainers. It sounds to me like the ability to "run
> without mutexes" is the real bug here, and "support" for that should be
> removed completely instead of patching it up downstream.
Yes, and it would be nice if the sound maintainers would try out the new USB
stack, and propose how they want to solve the problems that exist in the
> > There are multiple issues:
> > 1) If PAGE_SIZE is 16384 bytes, then the code simply fails.
> > 2) Sometimes PAGE_SHIFT is already defined.
> > #if PAGE_SIZE == 4096
> > #define PAGE_SHIFT 12
> > #elif PAGE_SIZE == 8192
> > #define PAGE_SHIFT 13
> > #else
> > #error PAGE_SHIFT undefined!
> > #endif
> OK, but again, why? If some architecture is not defining the same
> symbols as the others then maybe that architecture should be fixed,
> instead of working around the effect downstream.
Yes, but then there will be even more patches, and I've been told to reduce
the number of patches outside USB.
> P.S. There were a number of questions you didn't answer, can I assume
> those will follow later?
Could you please repeat the questions you did not get an answer to?
More information about the freebsd-usb