Xen devel - Aug 2010 - hv block drivers

Hi Hank,

I wanted to follow up on the block device driver discussion we had at
LinuxCon, based on some other input I got.

What most people recommended was to make both the hv scsi and the
hv ata code scsi device drivers, *not* make them standalone block
drivers as I originally recommended.

The main reason for this is consistent naming of the devices. We
have a lot of user code that can deal with /dev/sd* devices, but
introducing the /dev/vd* devices for virtio caused a lot of pain
that you probably shouldn't have to go through.

I'm not sure whether the two should be one or two drivers. My
feeling here is that it might be nice to have a single scsi
host driver for both that has two modes of driving the device,
one sending the SCSI commands down the virtual bus, the other
one interpreting the SCSI commands in the same way that libata
does.

	Arnd

On 08/30/2010 07:43 AM, Arnd Bergmann wrote:
> Hi Hank,
>
> I wanted to follow up on the block device driver discussion we had at
> LinuxCon, based on some other input I got.
>
> What most people recommended was to make both the hv scsi and the
> hv ata code scsi device drivers, *not* make them standalone block
> drivers as I originally recommended.
>
> The main reason for this is consistent naming of the devices. We
> have a lot of user code that can deal with /dev/sd* devices, but
> introducing the /dev/vd* devices for virtio caused a lot of pain
> that you probably shouldn't have to go through.
We're having the same kind of problem with the Xen xvdX device naming. 
For a fully PV system it doesn't matter to much, but when you've got PV
drivers taking the place of a regular emulated hardware device it would
be nice to have a similar device name.

But there isn't a lot of similarity between the Xen block interface and
SCSI beyond the basic block transfer bits, so I was wondering how good a
match it would really be.

Have you investigated making virtio a scsi device?

    J