Hello,
thanks for your fast responses.
I've also recognized flaws in my implementation, after your comments, so
I'll try to find a solution, that is acceptable, and create a better
patch. But first, I'll need to know if this approach is correct:
> my interpretation is that the SCSI "product" field data is identical
> to the ATAPI "model" field data.
> AFAICT, ATAPI doesn't provide a way to expose a vendor in string
> format. So I would say we accept 'product' for IDE, but reject
> 'vendor'
I would also say so.
Therefore I would need to expand the vendor field to 40 Chars, if a
SATA/IDE bus is selected. (current is 8 for SCSI).
about this:
> an IDENTIFY DEVICE / IDENTIFY PACKET DEVICE command on some *real*
> hardware
With hdparm -I /dev/sdX I got:
Model Number: TOSHIBA DT01ACA050
Model Number: Samsung SSD 850 EVO 250GB
I think hdparam just dumps the raw responses, but correct me if I'm wrong.
>> Therefore I would say, that vendor and product pretty much correlate
to the model field in QEMU,
>>This feels very subjective. Could you please add a better justification?
>>E.g. show how qemu formats the default vendor and product name?
QEMU formats the defaults as "QEMU HARDDISK" and "QEMU CD-ROM"
This was just an assumption, for which I didn't find any spec yet.
Since every disk I know is in the form of:
MANUFACTURER SOME OTHER MODEL NAME
Maybe it is just a convention, but I have no experience in that field.
In the Windows VM in device manager under the SATA device for
"QEMU HARDDISK" it shows as Device instance path
SCSI\DISK&VEN_QEMU&PROD_HARDDISK\, which also made me think that it is
the norm.
About the coding style, I'll fix those problems.
And thanks for reminding me of the memory leaks in C, im so accustomed
to writing in code that does not have them, that I almost forgot how
aware you must be of declaring pointers.
Sincerely,
Benedek
