From: Milan Broz <mbroz@redhat.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Alasdair G Kergon <agk@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/15] dm: support ioctls on mapped devices
Date: Thu, 22 Jun 2006 10:15:30 +0200 [thread overview]
Message-ID: <449A51A2.4080601@redhat.com> (raw)
In-Reply-To: <20060621205206.35ecdbf8.akpm@osdl.org>
Andrew Morton wrote:
> On Wed, 21 Jun 2006 20:31:21 +0100
> Alasdair G Kergon <agk@redhat.com> wrote:
>
>> From: Milan Broz <mbroz@redhat.com>
>>
>> Extend the core device-mapper infrastructure to accept arbitrary ioctls
>> on a mapped device provided that it has exactly one target and it is
>> capable of supporting ioctls.
>
> I don't understand that. We're taking an ioctl against a dm device and
> we're passing it through to an underlying device? Or something else?
Solving this situation: logical volume (say /dev/mapper/lv1) mapped in dm
to single device (/dev/sda):
If there is need to send ioctl you must know that /dev/mapper/lv1
is mapped to /dev/sda (and use /dev/sda for ioctl).
This is dm work - so send ioctl to /dev/mapper/lv1 directly
and let dm decide what to do.
This is supported only for single mapping. If there are more than one target
it will return -ENOTTY.
>> [We can't use unlocked_ioctl because we need 'inode': 'file' might be NULL.
>> Is it worth changing this?]
>
> It _should_ be possible to use unlocked_ioctl() - unlocked_ioctl() would be
> pretty useless if someone was passing it a NULL file*. More details?
yes,
(I prefer change block code to not pass NULL and use unlocked_ioctl,
- Alasdair ?)
see
drivers/char/raw.c:
126: return blkdev_ioctl(bdev->bd_inode, *NULL*, command, arg);
and block/ioctl.c: [file = NULL here]
206: if (disk->fops->unlocked_ioctl)
207: return disk->fops->unlocked_ioctl(*file*, cmd, arg);
--
Milan Broz
mbroz@redhat.com
next prev parent reply other threads:[~2006-06-22 8:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 19:31 [PATCH 01/15] dm: support ioctls on mapped devices Alasdair G Kergon
2006-06-22 3:52 ` Andrew Morton
2006-06-22 8:15 ` Milan Broz [this message]
2006-06-22 8:29 ` Andrew Morton
2006-06-22 15:17 ` Alasdair G Kergon
2006-06-22 16:55 ` Andrew Morton
2006-06-23 3:31 ` Kevin Corry
2006-06-23 3:49 ` Andrew Morton
2006-06-23 10:01 ` Christoph Hellwig
2006-06-23 10:00 ` Christoph Hellwig
[not found] ` <20060623032108.28debec2.akpm@osdl.org>
2006-06-23 13:13 ` Milan Broz
2006-06-22 13:21 ` Alasdair G Kergon
2006-07-05 3:22 ` Arnd Bergmann
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=449A51A2.4080601@redhat.com \
--to=mbroz@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@osdl.org \
--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 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.