mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew Dharm <mdharm-kernel@one-eyed-alien.net>
To: "Richard B. Johnson" <linux-os@analogic.com>
Cc: Kernel Developer List <linux-kernel@vger.kernel.org>
Subject: Re: mmap() and ioctl()
Date: Mon, 4 Apr 2005 12:19:42 -0700	[thread overview]
Message-ID: <20050404191942.GB6464@one-eyed-alien.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0504041453440.5597@chaos.analogic.com>

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

On Mon, Apr 04, 2005 at 03:02:26PM -0400, Richard B. Johnson wrote:
> On Mon, 4 Apr 2005, Matthew Dharm wrote:
> 
> >This probably is a silly question, but....
> >
> >Is is possible to open a file, mmap() it into memory, then pass the address
> >of that map via an ioctl() call to the kernel, which will copy_from_user()
> >that data?
> >
> 
> Yes. A user-mode pointer, passed via ioctl() is valid in the kernel
> in the context of the user, i.e., during read() write() ioctl().
> 
> However, it is not valid if it is accessed by some other process or
> an interrupt. In other words, you can't store it somewhere and
> access it later in some other context.

Right, I've got that part.  The plan has been to mmap(), ioctl(), and
inside the ioctl do a copy_from_user() into a kernel-context buffer.

> >Yeah, that's an odd concept, I know... I could always malloc() some
> >memory, read the file in, and then ioctl() it.  But, if I could get away
> >with a direct mmap(), that would be much better for me.
> 
> Since you need to copy anyway, you could mmap() your kernel
> data (impliment mmap in your driver). Then you mmap both
> "files" the same way and copy to/from in user-mode.

That's an interesting concept, and one I'm not familiar with.  Any useful
pointers (beyond UTSL)?  I'll admit to being much more familiar with SCSI
and USB internals than I am with something like device-layer interfacing.

It sounds like you're saying that my driver can implement an mmap() method
(similar to the ioctl method), and then I can just mmap the source file and
the driver /dev node and do a memcpy() between them. 

That's an interesting idea, but potentially not what I need.  The data
needs to go with some command information and a buffer to stuff the results
in.  This is basically a co-processor device I'm talking to.  The basic
data path here is from a file, through the driver, to a custom piece of
hardware (and back again).

Tho, anything that allows me to move the data from the disk up to a place
where I can pci_map_single() it faster is a Good Thing(tm).

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed 
suction darts!
					-- Salesperson to Greg
User Friendly, 12/30/1997

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-04-04 19:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-04 18:27 Matthew Dharm
2005-04-04 19:02 ` Richard B. Johnson
2005-04-04 19:19   ` Matthew Dharm [this message]
2005-04-05 15:30 Aleksey Gorelov

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=20050404191942.GB6464@one-eyed-alien.net \
    --to=mdharm-kernel@one-eyed-alien.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    /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

all inboxes | Powered by JetHome®