Re: wsevent MP-safe

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Matthias Drochner <M.Drochner%fz-juelich.de@localhost> wrote:
> > Here is a patch (been forgotten and dusting in my tree for a while)
> 
> Hmm, yes, obviously...
> So what is the substance? Replacing the splwsevent() by a mutex?

In essence, yes.  It cannot be *just* replaced, though.  Code needs slight
rework to be able to run without kernel-lock.  Goal is to get rid of this
lock from wscons (next would be wsmouse, wskbd).

> Sorry for sounding unfriendly, but it is hard to see what is
> important within all the cosmetic nonsense, you should have
> seperated it.
> But about cosmetics -- I don't like the new name "wsevents_t"
> for wseventsvar. If at all, it is a wsevent_queue or so, this
> would describe what it is good for.

Let it be wsevent_queue, if you want.  Some "cosmetic" changes are to hide
this structure, implementation details and always use the interface.

> As I understand it, the initial plan was to have this queue mmap()able,
> or at least accessible to kernel video drivers which can control a sprite,
> to avoid system call latency for mouse movements. Noone did the work
> to implement this, but seeing the trend to in-kernel video drivers
> in Linux I'd at least not actively inhibit it.

Why do you think that patch inhibits it, especially when I read that nobody
is working on this?  It should not be hard to make queue mmap()able, more
work would be in the part which actually mmap()s it, I guess.

-- 
Mindaugas