On Tue, Jun 05, 2012 at 10:10:30PM +0200, Hans Petter Selasky wrote:
> If two SMP enabled stacks have each their lock, and they are
> calling each other, that means any callbacks must go unlocked,
> because else you can get a LOR (locking order reversal). Agree?
No. If this is an issue, the loc
On Tuesday 05 June 2012 19:59:08 matthew green wrote:
> > - usbd_bus_methods{} gains a get_lock() to enable the
> >
> > host controller to provide a lock for the USB code.
> > if the lock isn't provided, old-style protection is
> > (partially) applied.
> - usbd_bus_methods{} gains a get_lock() to enable the
> host controller to provide a lock for the USB code.
> if the lock isn't provided, old-style protection is
> (partially) applied.
>
> It is better if the USB driver can select the lock, like in FreeBSD.
On Sunday 03 June 2012 03:20:01 Michael wrote:
> Hello,
>
> On Sun, 03 Jun 2012 06:37:14 +1000
>
> matthew green wrote:
> > i think the usbmp branch is ready to merge into -current. i've
> > built a couple of i386/amd64 GENERIC kernels for people to test
> > in the next week or so. i've also t
Hello,
On Sun, 03 Jun 2012 06:37:14 +1000
matthew green wrote:
> i think the usbmp branch is ready to merge into -current. i've
> built a couple of i386/amd64 GENERIC kernels for people to test
> in the next week or so. i've also tested on sparc64 and powerpc
> but if anyone else would like a
hi folks.
i think the usbmp branch is ready to merge into -current. i've
built a couple of i386/amd64 GENERIC kernels for people to test
in the next week or so. i've also tested on sparc64 and powerpc
but if anyone else would like a kernel please let me know (or
checkout the jmcneill-usbmp br
