Hi. I need to access to user space memory from a kernel module. This module
is not a driver, so I would like how can i write and read from/to a variable
in a user application from my kernel module?
At first I thought I could do that with shared memory (shmget, shmat...),
but in that is not possible in a kernel module. So I have thought to do it
with copy_from_user and copy_to_user, but i don't know how to do it exactly,
basically how to know where to write or read in the user var...
Any suggestion???
Thanks in advance
On Mon, Nov 11, 2002 at 11:40:19PM +0100, David San?n Baena wrote:
> Hi. I need to access to user space memory from a kernel module. This module
> is not a driver, so I would like how can i write and read from/to a variable
> in a user application from my kernel module?
> At first I thought I could do that with shared memory (shmget, shmat...),
> but in that is not possible in a kernel module. So I have thought to do it
> with copy_from_user and copy_to_user, but i don't know how to do it exactly,
> basically how to know where to write or read in the user var...
> Any suggestion???
> Thanks in advance
The user space application will have to make a call to the driver
somehow. Usually this is in the way of an ioctl() on a device that the
driver has made available to use space. The arguments passed across the
ioctl are known to your kernel module and userspace app. You could pass
a pointer to the kernel module which would be userspace memory that the
driver could copy_to_user some data to.
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Hello David and Ben,
Ben Collins writes:
> On Mon, Nov 11, 2002 at 11:40:19PM +0100, David San?n Baena wrote:
> > Hi. I need to access to user space memory from a kernel module. This module
> > is not a driver, so I would like how can i write and read from/to a variable
> > in a user application from my kernel module?
[...]
> The user space application will have to make a call to the driver
> somehow. Usually this is in the way of an ioctl() on a device that the
> driver has made available to use space. The arguments passed across the
> ioctl are known to your kernel module and userspace app. You could pass
> a pointer to the kernel module which would be userspace memory that the
> driver could copy_to_user some data to.
Using ioctl() should work ok, but it seems that ioctl is already
cluttered as it is. I did a little project once where I made the
kernel dispatch `upcalls` to a user-space daemon. Basically I
implemented this mecanism stealing the idea from the Coda FS
[http://www.coda.cs.cmu.edu/].
(Look at fs/coda/psdev.c for the implementation).
They basically set up a new entry in /dev/, and Venus (it's
user-space daemon) would poll()/read()/write() from the created
entry. As Ben said you can then write() the pointer to memory you want
to copy.
But I have a question for the gurus out there. Which is the most
appropriate manner of extending the kernel for introduction of an
interface which only one particular module would use?
I've heard that ioctl() is already too much cluttered. So are the
common virtual filesystems like /proc/ and /dev/. And _certainly_ new
syscalls are out of question.
If I recall correctly Jeff Garzik and Greg KH have previously
suggested that an ad hoc ramfs based file system be setup for
interfacing with the module/kernel. But later on, Patrick Mochel
defended the use of sysfs.
Personally I feel that ad hoc virtual file system can make things a
living hell, whereas a unified, neatly named sysfs could improve
things (but what do I know, I'm just a kernelnewbie ;).
So which is it guys? Sysfs or ad hoc ramfs?
And I've googled around for documentation on sysfs and have found
almost nothing. Can someone point me to some material (mailing list
posts, docs, etc) regarding sysfs?
best regards!
--
Livio <[email protected]>