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
On Monday 30 August 2010, Jeremy Fitzhardinge wrote:
> Have you investigated making virtio a scsi device?
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
>On Monday 30 August 2010 Arnd Bergmann wrote:
>>On Monday 30 August 2010, Jeremy Fitzhardinge wrote:
>> Have you investigated making virtio a scsi device?
>
>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,
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.
On 08/30/2010 10:31 AM, Hank Janssen wrote:
> 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?
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
On Monday 30 August 2010 19:35:35 Jeremy Fitzhardinge wrote:
> On 08/30/2010 10:31 AM, Hank Janssen wrote:
> > 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?
>
> 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).
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
On 30.08.2010, at 21:18, Arnd Bergmann wrote:
> On Monday 30 August 2010 19:35:35 Jeremy Fitzhardinge wrote:
>> On 08/30/2010 10:31 AM, Hank Janssen wrote:
>>> 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?
>>
>> 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).
>
> 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.
It's basically the same as the VMware PV SCSI driver, no? And that one is in drivers/scsi/vmw_pvscsi.c.
Alex