Sure i can use the synchronization primitives, the problem is that the response to a request sent to PS3 VUART port is not available immediately, and i have to disallow kernel access to the PS3 VUART while i'm waiting for the response in user space. I send request with write syscall from user space and wait for response with read syscall. In the period of time between sending request and receiving response i could receive some other packets from VUART port, e.g. some kind of event notification, i have to skip them. But kernel should not interfer until i get my response. So i would need to lock out the kernel during this time. I think i found a good solution for this problem, just use a IOCTL which tells kernel device driver to stop processing kernel requests and events, something like SET_USER_MODE. After that i can use it in user space.
21 сентября 2011, 16:27 от Ivan Voras <ivo...@freebsd.org>: > On 21/09/2011 08:05, geoffrey levand wrote: > > I think you misunderstood what i need. If i got it right then cuse4bsd > allows user applications to create char devices, right ? > > I do not want to create character devices from user space. My VUART kernel > > module should provide the character device for user space. What i need is a > way to synchronize access > > to VUART data between kernel and user space. The kernel device driver should > provide 2 interfaces: one for user space > > (through char dev) and the other for kernel land. The problem is how to > synchronize the access to VUART data between 2 > > lands because VUART cannot be shared by both simultaneously. > > I'm not sure I understand your question but what exactly is the problem > here? As the userland will access the device through the char device, > you need kernel code which services this device's requests. This kernel > code can use any number of synchronization operations provided by the > kernel to protect access to any and all needed resources. > > In other words, you should have a single point of entry to the device in > the kernel anyway (e.g. a module, a header file, whatever) and then you > may need just a simple sx(9) lock or a sema(9) semaphore, assuming the > device access needs sleeping, or mutex(9) if it doesn't.
_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
