[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: wsevent MP-safe
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.
Main Index |
Thread Index |