[okl4-developer] Sharing a driver between vservers

Geoffrey Lee glee at ok-labs.com
Mon Jul 14 13:21:51 EST 2008


On Fri, Jul 11, 2008 at 12:05:37PM +1000, Jamie Lennox wrote:
> Hi,
> 

Hi Jamie

> My situation is i'm trying to write okl4 drivers that will handle a 
> keyboard and mouse in x86. Too make it expendable i have my vkeyboard 
> and vmouse servers. However in the case of PS/2 both are run through the 
> same 8042 chip. This means i need some form of lock when they are operating.
> 
> My understanding is that there is a single thread per vserver and the 
> vserver are linked against each other so can call each other directly 
> (no ipc). Meaning if i linked vkeyboard and vmouse against the same 
> driver then i am linking against different instances of the same driver 
> and so cannot share a lock that way.

Yes, they would be different instances in this scenario.

> 
> My question i suppose, is there some way to link both vservers to the 
> same 8042 driver instance so i can do my own synchronization?

Yes, this should be possible.  You pair up the vserver with 
the appropriate driver in the platform description file.  

> 
> I realise i can create a memsection with a lock and pass this to both 
> drivers, however this problem is really only applicable in this case and 
> so i would prefer not to do it that way.
> 
> I suppose i can use the naming server to share a memory section, but i 
> understand this is being phased out in favour of elfweaver.
> 

It may be possible to use Ipc() or similar to do synchronization.  
Another way, as you have noted, is to create a shared memory region 
that both servers have access to do synchronization in that region.

One option may be to divide it at the boundary of the device rather
than functionality.  For example rather than having vkeyboard and
vmouse maybe have one vinput instead.

> I'm not sure if i can do it in elfweaver as i dont want the memory if 
> neither driver is employed, and i dont want it created twice in the 
> instance of both (and would prefer not to hack it up to do checks in the 
> root of the build system).
> 
> Those are my options i know of. Is there another (nicer) way?
> 
> Jamie.
> 
> PS. Still wondering about using something other the device_if.di for 
> creating drivers.
> 

device_if.di is intended to serve as a base that is common across
different types of device drivers.  Some devices are specific.  In this
case the best way is to have a null implementation of the call.  Is
there any strong reason why you would prefer not to use device_if?

	-gl

> 
> 
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer
> 

-- 




More information about the Developer mailing list