From: Livio Baldini Soares <livio@ime.usp.br>
To: "David Sanán Baena" <davidsanan@teleline.es>
Cc: Ben Collins <bcollins@debian.org>, linux-kernel@vger.kernel.org
Subject: Re: how to access user space memory from kernel.
Date: Mon, 11 Nov 2002 23:46:53 -0200 [thread overview]
Message-ID: <20021112014653.GA17743@ime.usp.br> (raw)
In-Reply-To: <20021111225942.GB522@phunnypharm.org>
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 <livio@ime.usp.br>
prev parent reply other threads:[~2002-11-12 1:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-11 22:40 how to access user space memory from kernel David Sanán Baena
2002-11-11 22:59 ` Ben Collins
2002-11-12 1:46 ` Livio Baldini Soares [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021112014653.GA17743@ime.usp.br \
--to=livio@ime.usp.br \
--cc=bcollins@debian.org \
--cc=davidsanan@teleline.es \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox