Removing an entry from struct emul

2017-12-20 Thread coypu
Hi, COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault. But it's been removed. can I remove e_fault from the struct, or would this break compat too hard? Its sole use is a check in mips/trap.c. I would like to remove this, too.

Re: workqueue_drain

2017-12-20 Thread Joerg Sonnenberger
On Thu, Dec 21, 2017 at 05:32:58AM +0800, Paul Goyette wrote: > I'm not totally convinced here. It might be useful to wait for a > particular work to be finished in order to allow it to be enqueued > again (no work can be enqueued if already in the queue). But I don't > see how "remember the

Re: workqueue_drain

2017-12-20 Thread Michael van Elst
On Thu, Dec 21, 2017 at 05:32:58AM +0800, Paul Goyette wrote: > again (no work can be enqueued if already in the queue). But I don't > see how "remember the last work enqueued and wait for it to be done > before destroying" is more versatile than "waiting for all to be done > before destroying".

Re: workqueue_drain

2017-12-20 Thread Paul Goyette
On Wed, 20 Dec 2017, Michael van Elst wrote: ozak...@netbsd.org (Ryota Ozaki) writes: On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: What about a method that waits for a specific work to complete? It might be useful but how it works in this case? You

Re: workqueue_drain

2017-12-20 Thread Michael van Elst
ozak...@netbsd.org (Ryota Ozaki) writes: >On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: >> What about a method that waits for a specific work to complete? >It might be useful but how it works in this case? You could remember the last work enqueued and wait for it

Re: workqueue_drain

2017-12-20 Thread Ryota Ozaki
On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: > ozak...@netbsd.org (Ryota Ozaki) writes: > >>Here is a patch: >> http://www.netbsd.org/~ozaki-r/workqueue_drain.diff >>(I will update workqueue.4 once the proposal is accepted.) > > What about a method that waits for

Re: RFC: ipsec(4) pseudo interface

2017-12-20 Thread Thor Lancelot Simon
On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote: > Hi, > > We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo > interface manages its security policy(SP) by itself, in particular, we do > # ifconfig ipsec0 tunnel 10.0.0.1 10.0.0.2 > the SPs "10.0.0.1 ->

Re: xhci spec (mis?)interpretation on hubs

2017-12-20 Thread Nick Hudson
On 12/20/17 12:18, Sprow wrote: In article <3ef1728a-54fb-6c89-5634-e39ca9808...@netbsd.org>, Nick Hudson wrote: How so? It used to read #define IS_TTHUB(dd) \ ((dd)->bDeviceProtocol == UDPROTO_HSHUBSTT || \ (dd)->bDeviceProtocol == UDPROTO_HSHUBMTT) then

Re: xhci spec (mis?)interpretation on hubs

2017-12-20 Thread Sprow
In article <3ef1728a-54fb-6c89-5634-e39ca9808...@netbsd.org>, Nick Hudson wrote: > On 12/19/17 20:32, Sprow wrote: > > In article <5fc73ccd-26a2-7919-17e3-8098ccb3f...@netbsd.org>, > > Nick Hudson wrote: > >> On 12/17/17 10:40, Nick Hudson wrote: > >>>

Re: RFC: ipsec(4) pseudo interface

2017-12-20 Thread Christos Zoulas
In article <75925357-8e16-0f0f-b7a0-78155c865...@iij.ad.jp>, Kengo NAKAHARA wrote: >Hi, > >On 2017/12/19 2:54, Christos Zoulas wrote: >> In article <02c36311-2fcd-08cf-cc71-b472e7c01...@iij.ad.jp>, >> Kengo NAKAHARA wrote: >>> Hi, >>> >>> We

Re: xhci spec (mis?)interpretation on hubs

2017-12-20 Thread Nick Hudson
On 12/19/17 20:32, Sprow wrote: In article <5fc73ccd-26a2-7919-17e3-8098ccb3f...@netbsd.org>, Nick Hudson wrote: On 12/17/17 10:40, Nick Hudson wrote: On 12/08/17 18:25, Sprow wrote: I've been having a look on a USB analyser at a class of hubs that don't seem to work on

Re: xhci spec (mis?)interpretation on hubs

2017-12-20 Thread Nick Hudson
On 12/17/17 10:40, Nick Hudson wrote: On 12/08/17 18:25, Sprow wrote: Hi, I've been having a look on a USB analyser at a class of hubs that don't seem to work on a driver based on    src/sys/dev/usb/xhci.c Comparing the dialogue for a non XHCI controller I see the issue is that the cascade

Re: workqueue_drain

2017-12-20 Thread Michael van Elst
ozak...@netbsd.org (Ryota Ozaki) writes: >Here is a patch: > http://www.netbsd.org/~ozaki-r/workqueue_drain.diff >(I will update workqueue.4 once the proposal is accepted.) What about a method that waits for a specific work to complete? -- -- Michael van Elst

Re: workqueue_drain

2017-12-20 Thread Ryota Ozaki
On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette wrote: >> On Wed, 20 Dec 2017, Ryota Ozaki wrote: >> >>> Hi, >>> >>> workqueue_destroy requires that its queue doesn't have >>> any works (and no new work

Re: workqueue_drain

2017-12-20 Thread Ryota Ozaki
On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette wrote: > On Wed, 20 Dec 2017, Ryota Ozaki wrote: > >> Hi, >> >> workqueue_destroy requires that its queue doesn't have >> any works (and no new work will be enqueued anymore) >> before being called. Currently users of workqueue have

Re: workqueue_drain

2017-12-20 Thread Paul Goyette
On Wed, 20 Dec 2017, Paul Goyette wrote: KASSERT_MSG((wq->wg_flags & WQ_DRAINING) != 0, "adding work to a draining workqueue") And, of course, that should have been ==, not != :) +--+--++ | Paul Goyette