Re: untangling the compat mess

On Sat, Dec 09, 2017 at 09:39:27AM +1100, matthew green wrote: > i think #3 is the best end-goal as it allows both kernels to > skip the compat they don't need (since any module will have > that via some other module [orstaticically for #2]) while does > not duplicate (compiled) code. Indeed,

Re: getsockopt(2)

In article , Robert Swindells wrote: > >I wrote: >>Does anyone know why we don't use the input 'optlen' parameter to the >>getsockopt(2) syscall, we do write back to it on return. >> >>In ip_output() there is this, which suggests that someone had

re: untangling the compat mess

Maxime Villard writes: > Le 06/12/2017 à 21:23, matthew green a écrit : > > kernel libraries are supposed to be built as a .o not a .a, > > for modular/lkm kernels. did this get lost some where? > > libcompat is a .a, I saw that too ah, so that is the underlying problem. > > ie, if you have a

xhci spec (mis?)interpretation on hubs

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 of hubs is HS->FS->LS. The GetDescriptor of the LS device never makes it

Re: kernel condvars: how to use?

>>> Where do you set LPT_RF_WAITING? >> Hm, now that you mention it, I think I don't. > Note that a flag like this is not normally necessary, Of course. > or even particularly helpful -- cv_broadcast already has essentially > the same optimization internally. That doesn't surprise me, but it

Re: untangling the compat mess

Le 06/12/2017 à 21:23, matthew green a écrit : kernel libraries are supposed to be built as a .o not a .a, for modular/lkm kernels. did this get lost some where? libcompat is a .a, I saw that too ie, if you have a MODULAR kernel, then the build should always include all the library stuff,

Re: kernel condvars: how to use?

> Date: Fri, 8 Dec 2017 09:04:25 -0500 (EST) > From: Mouse > > > Where do you set LPT_RF_WAITING? > > Hm, now that you mention it, I think I don't. Note that a flag like this is not normally necessary, or even particularly helpful -- cv_broadcast already has

Re: kernel condvars: how to use?

> For lptclose, note that callout_stop does not wait for the callout to > stop if it was in the middle of executing, and does not destroy it. > You must use callout_halt to wait, and then use callout_destroy to > destroy it. Okay, manpage bug - 5.2's callout(9) does not mention callout_halt

Re: RFC: PERCPU_LIST to fix PR kern/52515

> Date: Fri, 8 Dec 2017 18:51:28 +0900 > From: Kengo NAKAHARA > > However, it seems your patch has large diff... From the point of code > stability, smaller diff SLIST version would be better for netbsd-8 branch > to fix the bug. Because your patch causes some new ATF

Re: kernel condvars: how to use?

> Where do you set LPT_RF_WAITING? Hm, now that you mention it, I think I don't. That should prevent read() from ever being woken up, but I don't think it should deadlock the whole system. > Some other general comments: > Are you sure that's the code you're using? lpt_raw_read seems to >

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On 12/06/17 11:11, Ryota Ozaki wrote: On Tue, Nov 28, 2017 at 6:40 PM, Ryota Ozaki wrote: On Mon, Nov 27, 2017 at 12:24 AM, Nick Hudson wrote: On 11/17/17 07:44, Ryota Ozaki wrote: [snip] Hi, (Sorry for late replying. I was sick in bed for

Re: kernel condvars: how to use?

On 12/08/17 09:04, Nick Hudson wrote: On 12/08/17 03:26, Mouse wrote: [Brian Buhrow] 1.  [...].  Mutexes that use spin locks can't be used in interrupt context. Sure you don't have that backwards?  I _think_ mutex(9) says that spin mutexes are the only ones that _can_ be used from an

Re: RFC: PERCPU_LIST to fix PR kern/52515

Hi, On 2017/12/07 14:21, Taylor R Campbell wrote: > I dropped this thread on the floor a while ago and I forget what the > status was. I've had a patch sitting in my tree for a while which I > brushed off to put the list update logic in separate functions, as I > think chuq requested a while

Re: kernel condvars: how to use?

On 12/08/17 03:26, Mouse wrote: [Brian Buhrow] 1. [...]. Mutexes that use spin locks can't be used in interrupt context. Sure you don't have that backwards? I _think_ mutex(9) says that spin mutexes are the only ones that _can_ be used from an interrupt. Brain did get it backwards. To