From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCHv2 1/8] Introduce deriver_name field to DeviceInfo structure. Date: Fri, 05 Nov 2010 15:14:20 +0100 Message-ID: References: <1288525209-3303-1-git-send-email-gleb@redhat.com> <1288525209-3303-2-git-send-email-gleb@redhat.com> <20101104094244.GC6018@redhat.com> <20101104154454.GB14910@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: blauwirbel@gmail.com, alex.williamson@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58350 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752177Ab0KEOO1 convert rfc822-to-8bit (ORCPT ); Fri, 5 Nov 2010 10:14:27 -0400 In-Reply-To: <20101104154454.GB14910@redhat.com> (Gleb Natapov's message of "Thu, 4 Nov 2010 17:44:54 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov writes: > On Thu, Nov 04, 2010 at 03:58:03PM +0100, Markus Armbruster wrote: >> Gleb Natapov writes: >>=20 >> > On Thu, Nov 04, 2010 at 10:20:18AM +0100, Markus Armbruster wrote: >> >> Gleb Natapov writes: >> >>=20 >> >> > Add "deriver_name" to DeviceInfo to use in device path building= =2E In >> >>=20 >> >> Typo "deriver". Same in subject. >> >>=20 >> > Heh. >> > >> >> > contrast to "name" "driver_name" should refer to functionality = device >> >> > provides instead of particular device model like "name" does. >> >>=20 >> >> Why is that useful in a device path? >> >>=20 >> > Sometimes it is sometimes it is not. Lets look at path like that: >> > /pci@i0cf8/ethernet@4/ethernet-phy@0 >> > >> > It is important to have pci in the fist path element since it defi= nes >> > what kind of bus addressing is used by next element ethernet@4. >>=20 >> It is for consumers that don't know what's sitting at i0cf8 on the >> system bus. > Yes. Same firmware may support different boards that have same pci > controller but on different addresses. Device name may even contain > manufacturer ID, so firmware will be able to find matching driver and > support more board without recompiling. "pci" tells us it's some kind of PCI host bridge. Why is that enough? Why don't we have to identify the particular host bridge, such as "i440FX-pcihost"? >> > 4 = is >> > slot number in case of pci bus. On the other hand ethernet part is= not >> > important since OS can figure it out by looking in pci config spac= e. >>=20 >> The OS does know what's sitting in slot 4 on the PCI bus. >>=20 > Yes, and? That what I wrote above. "ethernet" part is redundant in ca= se > of PCI bus. A little bit of redundancy will not hurt and required by = the > spec. > >> If the OS number doesn't know what's sitting at i0cf8, why is "pci" >> sufficient information? Why don't we have to distinguish between th= e >> different PCI host bridges? > Manufacturer ID may be put along with pci. Full FDT contains much mor= e > information about each node though. It may even list compatible HW. H= ere > we are concerned with device paths only. > >>=20 >> >> I'm afraid "driver_name" is too confusing, because we already use >> >> "driver" and "name" for the name of the device model: DeviceInfo = member >> >> name, and qemu_device_opts option name "driver". >> > I use "driver_name" here since I am coding to Open Firmware spec n= ow >> > and this element in device path is called driver_name by the spec. >>=20 >> Why is it different from our DeviceInfo member name? >>=20 >> We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do w= e >> need a third? > I haven't noticed we have alias! What is it used for? I think I can u= se > it instead. > >>=20 >> Do you envisage different device models sharing the same driver_name= ? >>=20 > Yes. isa-ide, piix3-ide, piix4-ide all provides exactly same ata bus. But they're different devices! Isn't Open Firmware's "driver name" meant to identify a device type unambigously? Consider the case of an ISA soundcard providing an IDE channel. Want t= o call it "ata", too? >> [...] >> >> Do we want a free-for-all ad hoc set of values for driver_name? = The >> >> values become ABI instantly... Can we adopt some existing set of= names >> >> for device classes? Else, can we define our own with a bit more >> >> control? >> >>=20 >> > I am open to suggestion. Open firmware describes this field as: >> > >> > The driver name field is a sequence of between one and 31 letter= s, digits, >> > and punctuation characters from the set =E2=80=9C, . _ + - =E2=80= =9D. Uppercase and >> > lowercase characters are distinct. By convention, this name incl= udes >> > the name of the device=E2=80=99s manufacturer and the device=E2=80= =99s model name >> > separated by a =E2=80=9C,=E2=80=9D. (See the definition of =E2=80= =9Cname=E2=80=9D in annex A.) >> > Inclusion of the manufacturer name within driver name is especia= lly >> > important for devices intended to plug into standard buses, as t= his >> > minimizes the risk of accidental name collisions. It is somewhat= less >> > important for devices that are permanently attached to a particu= lar >> > system. If the manufacturer name component is omitted (i.e., th= ere is >> > no =E2=80=9C,=E2=80=9D within the driver name), the convention i= s to assume that >> > the manufacturer name is the same as that of the nearest ancesto= r node >> > (parent node, or grandparent node, etc.) that has an explicit ma= nufacturer >> > name component. >>=20 >> I suspect that's exactly what DeviceInfo member name is. >>=20 > In cases where this is the case I just use "name". > >> > I am looking on existing implementations an copy what they do. >> [...]