[vbox-dev] Storage Question: --device parameter redundant ?

[Klaus Espenlaub]

On 11.03.2011 00:59, Alexey Eromenko wrote:
> On Tue, Mar 8, 2011 at 4:20 AM, Alexey Eromenko<al4321 at gmail.com>  wrote:
>> I added a new hard disk to my VM:
>> C:\Program Files\Oracle\VirtualBox>VBoxManage storageattach "Other-Test VM" --st
>> oragectl "IDE Controller" --port 0 --device 1 --type hdd --medium F:\myvdi.vdi
>>
>> Why is --device parameter even needed ?
>> Only for IDE controller?
>> Other controllers (SATA) do not have it anyway, and it's functionality
>> can be mapped to --port parameter.
>>
>> Old behavior:
>> --port 0 --device 0 = Primary Master
>> --port 0 --device 1 = Primary Slave
>> --port 1 --device 0 = Secondary Master
>> --port 1 --device 1 = Secondary Slave
>>
>> Since in VBox IDE controller consists of 4 ports, it can be mapped to
>> --port parameter, as follows:
>> --port 0 --device 0 = Primary Master
>> --port 1 --device 0 = Primary Slave
>> --port 2 --device 0 = Secondary Master
>> --port 3 --device 0 = Secondary Slave
>>
>> Isn't it easier to remove --device altogether in future version of
>> VirtualBox, in favor of using only --port ?
>>
>> In real hardware IDE controller consists of 2 IDE devices, not 4 IDE devices.
>>
>> A standard PC has 2 such IDE controllers in chipset (total 4 IDE
>> devices), but then if VBox will want to have several IDE controllers
>> in future, --storagectl could be used to address this.
>> Anyway --device parameter looks redundant to either --port or to --storagectl.
>>
>
> So... any opinions ?

If only it were easy... technically the single device PCI we implement 
contains two IDE controllers with two devices each. There are no IDE 
controllers with 4 ports. 2 ports is and always was the maximum.

So the proper modelling would be to have 0-2 IDE controllers in the VM 
config, and then it really would be a matter of having only one option 
since the rest would be covered by the controller name. This is a lot of 
work, and means complicated config file changes... which is why this 
doesn't look attractive at all. Weeks to months of work for no 
significant behavior change.

Your suggestion is less work, but adds more hacks to code which isn't 
the way it should be, making the proper solution more work.

Klaus