Date: Wed, 20 Aug 2008 14:16:44 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Kris Kennaway <kris@FreeBSD.org> Cc: freebsd-usb@freebsd.org Subject: Re: usb4bsd patch review [was Re: ...] Message-ID: <20080820211644.GD16977@elvis.mu.org> In-Reply-To: <48AC54B8.4040406@FreeBSD.org> References: <20080818205914.GJ16977@elvis.mu.org> <200808192219.19246.hselasky@c2i.net> <48AB3D3A.4040303@FreeBSD.org> <200808201809.24620.hselasky@c2i.net> <48AC54B8.4040406@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ Reply to Hans at end of this ]] [[ Reply to Kris inline ]] * Kris Kennaway <kris@FreeBSD.org> [080820 10:30] wrote: > Hans Petter Selasky wrote: > >On Tuesday 19 August 2008, Kris Kennaway wrote: > >> > >>>>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. > > ...so what is the answer? > > >>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 sound system. > > This is backwards. If you perceive problems in other subsystems you > should take the lead on engaging with the relevant developers and > resolving those problems to your mutual satisfaction, instead of > inviting them to come to you. I think there has been a huge amount of effort just on the usb side, I think expecting Hans to come up with a patch that is "fix all freebsd issues" is a bit too much. I think we can proceed in an organic matter and clean up these small nits as time goes on, just like we do with almost every other problem... except for when we don't do require a completionist solution and never produce anything. (ie, the SMP lag). > >>>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. > > The way you minimize patches outside of USB is by submitting separate > patches that fix upstream issues at their source, instead of adding > workarounds like several of those that appeared in this diff. It's a two line ifdef, I dare say we're being a bit pedantic here. How much of a showstopper is this in reality? How _wrong_ is it compared to how _wrong_ the old usb code is? Are you taking into account that these nits can be fixed easily compared to the extra effort we will have to go through to submit all these stuff just for a two line delta? > >>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? > > I've repeated some of them already. e.g. in this mail you still didn't > answer the "is it safe to drop the locks" question which was asked > twice. Rather than me repeating them yet again, I'd suggest you go back > and take another close read over my emails and your responses, and reply > to the questions that are still not resolved. Hans, let's just leave sound the way it is. I will remove that part of the patch. It might be better to leave a bad locking in that generates a warning rather than obscure the locking issue by removing the warning without fully understanding the issues. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080820211644.GD16977>