On Tue, 4 Oct 2016 10:57:49 +0200 Kevin Wolf <kw...@redhat.com> wrote:
> Am 03.10.2016 um 13:07 hat Tomáš Golembiovský geschrieben: > > > > > > + if (((bs->drv != &bdrv_file) || !bs->read_only) && > > > > > > > > > > Why the check against bdrv_file ? > > > > > > > > To limit it only to files. Maybe there is better way to do that? The > > > > devices have a nasty habit to change the size. Sure, this can happen to > > > > file too, e.g. if somebody truncates the file outside QEMU. But that's > > > > rather a bad behaviour. For devices changing the size may be perfectly > > > > valid operation, e.g. replacing CD in drive or card in a card reader. > > > > > > > > > > The raw driver is usable over any storage backend (file, rbd, iscsi, > > > etc, etc) and it is valid to want to use a offset/size parameter in > > > combination with any of them. So we should not restrict it to just > > > files. > > Just to clear up some confusion here: There are the file/host_device/... > protocol drivers, which only access local files. These are implemented > in raw-posix.c, i.e. the file that this patch is touching. raw-win32.c > implements the same kind of file access for Windows. > > And then there is the raw image format driver, which is raw_bsd.c. This > one is what is layered on top of any of the protocol drivers, including > raw-posix, raw-win32 and all the network protocols. > > This is why implementing the feature in the raw format driver would make > it so much more useful. You could use it with any backend then. > Thanks Kevin, this really helped. I have to admit the naming is quite confusing. > > > > If we go with the second option then I have a another question. How > > > > strict is (or should be) qemu about the sizes being block aligned? I'm > > > > still little bit fuzzy on that. Somewhere it is assumed that the size is > > > > multiple of 512, sometimes qemu automatically rounds up if it isn't and > > > > sometimes it seems to me that the size can be arbitrary. > > Traditionally, the qemu block layer worked in 512 byte units and you > still see places where this is true. But we're in a process of > converting things to use bytes everywhere (which saves a lot of > conversion back and forth and simplifies the code), and the basic > read/write functions in the primary block drivers (raw, qcow2, file) can > all work with byte granularity today. Again thanks for clearing that up a bit. Tomas -- Tomáš Golembiovský <tgole...@redhat.com>