From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: How to check when "raw" format driver uses a "regular" file?
Date: Mon, 25 Jan 2021 17:01:51 +0100 [thread overview]
Message-ID: <c53e6ff2-b09a-ee1e-110d-b64f23e7b609@redhat.com> (raw)
In-Reply-To: <20210125154316.GC7107@merkur.fritz.box>
On 1/25/21 4:43 PM, Kevin Wolf wrote:
> Am 25.01.2021 um 16:05 hat Philippe Mathieu-Daudé geschrieben:
>> Is it possible to restrict a block driver to a particular set of
>> options? In my case I'd like to restrict the raw driver to regular files.
>>
>> I noticed the NFS driver does it locally in nfs_client_open(),
>> and FUSE has is_regular_file() -- which is POSIX specific however.
>>
>> When a backend is a SCSI drive, the block layer provide the blk_is_sg()
>> method to test it.
>> 1/ Should I provide a similar blk_is_regular_file()?
>>
>> 2/ There is no oslib function to check for regular file,
>> should I add one too?
>
> I find this question confusing because on one hand you're talking about
> block driver implementations like NFS, but on the other hand about SCSI
> devices, which are users, not implementations of block drivers.
Sorry for the confusion and thanks for the quick answer :)
My question is confused because the problem is not clear to me...
> At which level is the code where you think you need to make this
> distinction?
(see below)
> The other problem is that "is this a regular file?" is probably not what
> you're really interested in. The content of an image can be spread
> across several files (for example, consider backing files) or not use a
> local file descriptor at all (network protocol drivers), and block layer
> functions should ideally make sense for all drivers unless something can
> only possibly make sense for a single driver (blk_is_sg might be a case
> of this).
>
> I assume that you are interested in some specific property that regular
> files happen to provide. If at all possible, we shouldn't check for a
> specific backend type, but for capabilities or properties of a given
> block node.
>
> So what are you really trying to do here?
Well, maybe this is more an emulation problem rather than a block
one. But system emulation consumes block layer :)
The problem is when emulating devices such NOR Flash (parallel mapping
or SD cards) we expect the block driver being a plain file (either "raw"
format or another) but a "regular" file. When an user passes something
else like a block device, odd things happen.
Well, I guess I self-restricted my question to device emulation. So
in the cases mentioned I would like to add a check in sd_realize()/
pflash_cfi0?_realize() for regular file when a block drive is provided.
Description of problematic user case:
* -pflash /dev/sda
* -sd /dev/mmcblk0
User runs emulation on top of hardware (maybe like passthru?), and
expect underlying block to be in correct state out of QEMU.
Thanks,
Phil.
next prev parent reply other threads:[~2021-01-25 16:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 15:05 How to check when "raw" format driver uses a "regular" file? Philippe Mathieu-Daudé
2021-01-25 15:43 ` Kevin Wolf
2021-01-25 16:01 ` Philippe Mathieu-Daudé [this message]
2021-01-25 16:06 ` Peter Maydell
2021-01-25 16:19 ` Kevin Wolf
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=c53e6ff2-b09a-ee1e-110d-b64f23e7b609@redhat.com \
--to=philmd@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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;
as well as URLs for NNTP newsgroup(s).