>On Mar 17, 2006, at 10:30 AM, Garrett D'Amore wrote:
>
>> This is almost exactly what I had in mind.  It is the ioctl that I
>> wanted to optimize away.
>
>I can think of a couple of ways to make it less expensive for the u- 
> >k notification... but I'll have to stew on it for a bit first...   
>My brain is doing in the direction of a generic message queue  
>description / notification API... If we had a generic subsystem, it  
>would be reasonable to implement a generic "fast trap" for this on  
>platforms that can do it.
>
>Anyway, for now I would suggest "use an ioctl to get your stuff  
>working", and then we can always speed it up later..
>
>-- thorpej
>

	I don't know how much is publicly documented, but try looking at
the mechanisms in IRIX for u->k (the GLqueue handled by code in the page
fault path) and k->u (shmiq and qcntl).  The biggest problem becomes doing
validation on the data passed each way, not merely passing the data.  At
the cost of a test and branch in the page fault handler, you can implement
this easily on any machine with an MMU (at least any I know of).

	Paul Shupak