Hello,
does anybody know a way through which we can make a SysV IPC calls from dynamic loading kernel modules ?
I have a resource which must be manipulated through semaphores from user space and from kernel space ... I think the only way is to use a SysV IPC semaphore ...
but it seems I can't use it from my kernel module .. the kernel doesn't export any of its functions ...

any ideas ?

If the resource is located in kernel, it should be guarded by kernel
spinlock, I think. Access operation from userspace must wait with this
spinlock.

If you decribe yor problem more detailed (what is the resource, what are
resource operations from userspace and kernel, for example) other
suggestions may comes.

BTW, preferred language in this forum is Russian, so please forgive me
my terrible English.



zifo wrote:

> I have a resource which must be manipulated through semaphores from user space and from kernel space ... I think the only way is to use a SysV IPC semaphore ...
> but it seems I can't use it from my kernel module .. the kernel doesn't export any of its functions ...

Здравствуйте, TheBeard, Вы писали:

TB>If the resource is located in kernel, it should be guarded by kernel
TB>spinlock, I think. Access operation from userspace must wait with this
TB>spinlock.

TB>If you decribe yor problem more detailed (what is the resource, what are
TB>resource operations from userspace and kernel, for example) other
TB>suggestions may comes.

TB>BTW, preferred language in this forum is Russian, so please forgive me
TB>my terrible English.



TB>zifo wrote:

>> I have a resource which must be manipulated through semaphores from user space and from kernel space ... I think the only way is to use a SysV IPC semaphore ...
>> but it seems I can't use it from my kernel module .. the kernel doesn't export any of its functions ...


Actually, resource is an ordinary node file (file located in /dev directory). There can be processes which open and manipulate the mentioned file and drivers which do the same thing, but at every moment only one module (read driver or process) can work with it. So, I must synchronize this process ...
Is there any way to synchronize the same resource from kernel space and user space ?
This is the main question

I think, guarding your file operations (read/write/ioctl) with spinlock
in your module should solve the problem. It doesn't matter from where
the file is accessed -- from userspace or from other driver.

wrote:

> Actually, resource is an ordinary node file (file located in /dev directory). There can be processes which open and manipulate the mentioned file and drivers which do the same thing, but at every moment only one module (read driver or process) can work with it. So, I must synchronize this process ...
> Is there any way to synchronize the same resource from kernel space and user space ?

TB>I think, guarding your file operations (read/write/ioctl) with spinlock
TB>in your module should solve the problem. It doesn't matter from where
TB>the file is accessed -- from userspace or from other driver.

TB> wrote:

>> Actually, resource is an ordinary node file (file located in /dev directory). There can be processes which open and manipulate the mentioned file and drivers which do the same thing, but at every moment only one module (read driver or process) can work with it. So, I must synchronize this process ...
>> Is there any way to synchronize the same resource from kernel space and user space ?

You can also use internal open/close counter to prevent device file from being open twice.

Здравствуйте, TheBeard, Вы писали:

TB>I think, guarding your file operations (read/write/ioctl) with spinlock
TB>in your module should solve the problem. It doesn't matter from where
TB>the file is accessed -- from userspace or from other driver.

TB> wrote:


Actually, I need to synchronize only the ioctl call , and I don't think that with just forced locking the ioctl call will solve the problem. It may be a situation when some process has allready started the execution of ioctl and only after that the module is executed..
I think that in such case the forced locking won't work ...

Excuse me, I don't understand this. Does this mean your ioctl is
acynchronous? If your module creates a device file, it should implement
ioctl routine as well.

> It may be a situation when some process has allready started the
> execution of ioctl and only after that the module is executed..

Здравствуйте, TheBeard, Вы писали:

TB>Excuse me, I don't understand this. Does this mean your ioctl is
TB>acynchronous? If your module creates a device file, it should implement
TB>ioctl routine as well.

Of course in general it is synchronized ..
Ok, imagine this situation :
there is a driver which has an ioctl function. This function can be invoked from some process (which has opened the file connected with mentioned driver) and from some kernel module (yes, ioctl can be invoked from some kernel module).
I want this situation be synchronized ... the invokation of ioctl by module and process must be synchronized ...
thats all

any ideas ?

_The same_ ioctl function is invoked both from userspace process and
from other kernel modules, isn't it? I.e., the same code is executed in
both cases and _this_ code have to be synchronized (guarded by spinlock).

Maybe you use _two different implementation_ of ioctl routine, one for
kernel mode and another to be called userspace? This is a bad design.

wrote:

> there is a driver which has an ioctl function. This function can be invoked from some process (which has opened the file connected with mentioned driver) and from some kernel module (yes, ioctl can be invoked from some kernel module).
> I want this situation be synchronized ... the invokation of ioctl by module and process must be synchronized ...