On 11.03.2011 00:59, Alexey Eromenko wrote:
On Tue, Mar 8, 2011 at 4:20 AM, Alexey Eromenko<[email protected]> 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
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
