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
--

[ message continues ]

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
--

[ message continues ]

I doubt that there is much value in changing it now, and it's not something
I'd be interested in working on.

For the HyperV drivers, it probably makes sense because half of it is
trying to look like SCSI anyway, while the other half is trying to look
like ATA. For the ATA driver, the obvious choice would be to make it
a libata backend, though my impression from a brief look at the driver
was that it's better to copy some of the libata code and integrate it
into the hv SCSI driver.

	Arnd
--

[ message continues ]

Arnd,

Thanks for following up! I was cleaning up some other part of the drivers (not related to IDE/SCSI) 
And on my todo list is to clean up the IDE/SCSI drivers. I will go through the libata code and see
If there is anything in there that I can use to make these drivers somewhat saner.

I am not sure if I can combine them into one yet, Hyper-V treats both drivers differently. And there
Are some rumored changes to Hyper-V that would make these changes maybe even a bit more difficult.

I will use this mailing list to bounce ideas off of. 

I still need to clean up your other suggestion as well, the static declarations :)

For a more general question, When/if we make it out of staging, where should these drivers live?

	drivers/hyper-v or drivers/scsi and drivers/ide.

Is there a standard that is being followed?

Hank.

--

[ message continues ]

If they're not actually scsi/ide subsystem drivers, then drivers/block
would seem like the best place (and drivers/ide is truly ancient stuff,
I think).

    J
--

[ message continues ]

Agreed, although I was suggesting to make them SCSI drivers, so they
would go to drivers/scsi/ or a subdirectory of it in that case.

	Arnd
--

[ message continues ]

It's basically the same as the VMware PV SCSI driver, no? And that one is in drivers/scsi/vmw_pvscsi.c.


Alex

--

[ message continues ]