Paul Brook wrote:
On Saturday 12 May 2007, Jonathan Phenix wrote:
Hi,
currently the block driver in qemu only handles blocks (or sectors)
which are 512 bytes long,
...
Then, each probe functions should be modified to reject sector size
which is not 512 bytes, except for the raw block driver, which will be
modified to accept any block sizes. This change would probably solve the
whole problem without having a negative impact on the rest of the code.
Is it the right way to solve the problem? If this solution is accepted,
I will code it and submit a patch.
Seems like it might just be simpler to have the qemu block ABI use bytes
rather than blocks. Maybe with some common helper functions for doing R/M/W
on hard sectored devices.
By adding variable sized sectors you're just shifting complexity from the
block backends to the device emulation.
No, it will not add complexity at all to the device emulation code,
perhaps I was not clear enough on what I was trying to describe.
Basically, the only change that would be needed to existing users of the
block driver is to change "bdrv_new(...)" to "bdrv_new(..., 512)" (it
could be also done with "bdrv_open" instead) and that's it. The only
other difference that the user code will see is that the buffer required
by bdrv_read, bdrv_write and friends must now be a multiple of the size
requested before, but that's to be expected. The block driver will
continue to deal with sectors as a base unit.
As for internal changes in the block driver, a new variable, let's call
it "requested_sector_size" will be added to the probe function of each
driver as well as the BlockDriver structure. We can simply do "if
(requested_sector_size != 512) return 0;" for all existing drivers for
now in their probe functions and implement it in the future if required.
I will add support for a sector_size that is different than 512 in the
raw driver, the image file produced by cdrdao is in raw format. Other
popular CD ripping tools for Windows also creates raw images, with very
slight variations, as far as I know.
Sounds good?
Regards,
Jonathan Phénix
Paul