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: Thu, 04 Nov 2010 15:58:03 +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> 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]:60429 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752261Ab0KDO6K convert rfc822-to-8bit (ORCPT ); Thu, 4 Nov 2010 10:58:10 -0400 In-Reply-To: <20101104094244.GC6018@redhat.com> (Gleb Natapov's message of "Thu, 4 Nov 2010 11:42:44 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov writes: > 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. I= n >>=20 >> Typo "deriver". Same in subject. >>=20 > Heh. > >> > contrast to "name" "driver_name" should refer to functionality dev= ice >> > 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 defines > what kind of bus addressing is used by next element ethernet@4. It is for consumers that don't know what's sitting at i0cf8 on the system bus. > 4 is > slot number in case of pci bus. On the other hand ethernet part is no= t > important since OS can figure it out by looking in pci config space. The OS does know what's sitting in slot 4 on the PCI bus. 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 the different PCI host bridges? >> I'm afraid "driver_name" is too confusing, because we already use >> "driver" and "name" for the name of the device model: DeviceInfo mem= ber >> name, and qemu_device_opts option name "driver". > I use "driver_name" here since I am coding to Open Firmware spec now > and this element in device path is called driver_name by the spec. Why is it different from our DeviceInfo member name? We already have name (e.g. "lsi53c895a") and alias ("lsi"), why do we need a third? Do you envisage different device models sharing the same driver_name? [...] >> 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 na= mes >> 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 letters, = digits, > and punctuation characters from the set =E2=80=9C, . _ + - =E2=80=9D= =2E Uppercase and > lowercase characters are distinct. By convention, this name include= s > the name of the device=E2=80=99s manufacturer and the device=E2=80=99= s model name > separated by a =E2=80=9C,=E2=80=9D. (See the definition of =E2=80=9C= name=E2=80=9D in annex A.) > Inclusion of the manufacturer name within driver name is especially > important for devices intended to plug into standard buses, as this > minimizes the risk of accidental name collisions. It is somewhat le= ss > important for devices that are permanently attached to a particular > system. If the manufacturer name component is omitted (i.e., there= is > no =E2=80=9C,=E2=80=9D within the driver name), the convention is t= o assume that > the manufacturer name is the same as that of the nearest ancestor n= ode > (parent node, or grandparent node, etc.) that has an explicit manuf= acturer > name component. I suspect that's exactly what DeviceInfo member name is. > I am looking on existing implementations an copy what they do. [...]