🚀 go-pugleaf

In a previous article, I rambled incoherently:
>I'm having great difficulty writing an asynchronous Unix style device driver
>running under BSD/Mach/NeXTStep. Are there any asynchronous device driver
>authors out there that could help me please?. There's zippo documentation on
>how to do this in NeXT's "Writing Loadable Kernel Servers" manual, and it's
>proving very difficult.

>In particular, implementing select() for the driver is a nightmare; the
>"selwakeup" kernel function is undocumented, and it's operation is different
>to the same function on other BSDish systems, such as a Sun. The only example
>code I can find is from the Sun device driver manual, and it appears to have a
>race condition where the driver could get an interrupt between when the
>driver's xxselect returns false and the kernel puts the process to sleep;
>causing the process to hang since it's already missed the chance to selwakeup.

As you can see, I was deeply frustrated, and certainly not in a fit state to be
posting when I posted this. The problem is with a NeXT machine, and this
probably has a target audience of approximately (or at least very close to)
zero, but I've found the solution, so I'm going to post it anyway.

The problem, which I diagnosed by the ancient art of kernel disassembly, is
that selwakeup (and also wakeup, which I was using elsewhere too) ultimately
calls thread_wakeup, and the NeXT A"Writing Loadable Kernel Servers" manual
states that thread_wakeup can't be called at interrupt priorities greater than
3. Since our server handles NeXTbus interrupts at ipl5, I was doing the wrong
thing, and suffering kernel panics and lockups for it.

The solution is to use kern_serv_callout to call selwakeup and wakeup.

>Is there any hope for me?.
So, there is a tiny ray of hope... just.

Graham