All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Smith <danms@us.ibm.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: [RFC] dm-userspace
Date: Thu, 20 Apr 2006 13:06:33 -0700	[thread overview]
Message-ID: <87d5fcc8qe.fsf@caffeine.beaverton.ibm.com> (raw)
In-Reply-To: a4e6962a0604201050h44d2e8e0r5a96d763f53328e7@mail.gmail.com


[-- Attachment #1.1: Type: text/plain, Size: 2333 bytes --]

EVH> It seems like this would be really useful for prototyping and
EVH> debugging new device mapper modules (like the dm-cache ideas I
EVH> posted about a few weeks back).

Yes, I think that is a major benefit to going with the dm-userspace
idea over the cow-specific dm-cow.

EVH> 1) how would you handle permissions?  IIRC FUSE allows normal
EVH> users to bind their own FUSE userspace file systems, would
EVH> something similar happen for dm-userspace or would even binding a
EVH> userspace device-mapper module require root?

Hmm, I think that due to the way device-mapper works, this would be
difficult.  Without the ability to create a pseudo-device with a
dm-userspace target, I think you'd be out of luck.

EVH> 2) How close would the userspace API be to the kernel
EVH> device-mapper API?  It'd be nice to have something close so that
EVH> userspace code could easily be migrated into the kernel (for
EVH> performance reasons) as appropriate.

Well, currently I pass basically the same information to userspace.
You get the location of the access and whether it was a read or a
write.  The userspace module passes back a destination location,
device, and whether or not to copy the area from a source location
(which gives you an interface to kcopyd).

I think that we could easily add a layer to be able to run simple
device-mapper modules in userspace with it, similar to how nfsim
works, which may be very useful to people trying to write new
device-mapper targets.  What are people's thoughts on this?

Something I should mention here: to simplify things and reduce
communication, the current module blocks contiguous regions of the
disk together so that you can talk about whole chunks at a time,
instead of each individual bio request, which may be of varying size
and location.  Block sizes can be no smaller than 512 bytes.  I think
that most device-mapper work will be dealing with fixed blocks of some
size, so this shouldn't be a problem.

EVH> 3) When do you think you'll be able to post a patch for RFC?

I'm currently just cleaning some things up at the moment.  I would be
glad to post a patch and a sample userspace app if people would be
willing to take a look at it.

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2006-04-20 20:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-19 19:48 [RFC] dm-userspace Dan Smith
2006-04-20 17:50 ` Eric Van Hensbergen
2006-04-20 20:06   ` Dan Smith [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-04-26 22:45 Dan Smith
2006-04-26 22:45 ` Dan Smith
2006-04-26 22:55 ` Ming Zhang
2006-04-26 23:07   ` Dan Smith
2006-04-26 23:41     ` Ming Zhang
2006-04-27  2:22       ` Dan Smith
2006-04-27 13:09         ` Ming Zhang
2006-05-09 23:02   ` Dan Smith
2006-05-10 13:27     ` Ming Zhang

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=87d5fcc8qe.fsf@caffeine.beaverton.ibm.com \
    --to=danms@us.ibm.com \
    --cc=dm-devel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.