public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>

      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