qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]


From: Avi Kivity
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Mon, 15 Jun 2009 18:11:28 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

On 06/15/2009 06:07 PM, Anthony Liguori wrote:
Avi Kivity wrote:

I'd object to any implicit addressing rules. If we have to say target=2,lun=7,street=8,city=9,state=99,zip=12345 instead of index=8345345235 so be it.

The next observation is that while we expand the SCSI addressing, the current propose flattens the PCI hierarchy (i.e. pci_addr=00:01.0).

An alternative would be to either always expand or always flatten addressing. I think the later has a lot of merit. Consider:

-controller type=lsi1234,addr=00:01,name=blah
-controller-disk controller=blah,addr=00:01,name=sda

-controller type=ide,addr=00.02,name=ide
-controller-disk controller=ide,addr=3,name=hdd

-drive file=foo.img,controller-disk=sda
-drive file=bar.img,controller-disk=hdd

This means that addr's format depends on the parent device node which is a bit less explicit than the previous example. However, it is much more consistent and easier to implement. Basically, when adding a device to it's parent, you hand the parent the "addr" field and that lets you say where you want to sit on the bus.

I would prefer explicit names (pci_addr, lun, etc.) but would be okay with generic names too.

There's value in sticking to well-understood names and address formats.

--
error compiling committee.c: too many arguments to function





reply via email to

[Prev in Thread] Current Thread [Next in Thread]