device_type = "ethernet", well, then it's ethernet. Which kind? Well, it's the
kind that can only be available on that particular combination of hardware. If
it is an MPC5200B chip or an MPC5200 chip, you can determine exactly which one
it is. If it is an MPC8349E or an MPC82xx or something, it may be different,
but in general you can determine the exact device you have much easier (one
register comparison..) than running through a null-terminated string list,
doing comparisons against another list, and you get a wealth of information
out of that single 32-bit register value of the SVR that you would not from
a simple name. This is where it differs from PCI devices which you can have
10 of them in the same box and need to work out which one came from where, and
what esoteric combination the user will use. The device tree is simply there
to inform you what is present and what is configured (especially in the case
when a unit can be configured as multiple devices and may be dangerous to
reconfigure) and on an SoC or even a northbridge or southbridge which
implements "non PCI" devices, you have plenty of options for determining
exactly what is in them (/builtin/ethernet@1 on Pegasos is the Marvell
controller, even though we use a chip with 2 ethernet controllers in it,
only one works - there is no PHY card for the other. However rather
scarily the option of 1 or 2 ethernet ports in Linux is defined by a
kernel config flag... so much for the device tree..)

I don't know where to begin to explain how wrong I think you are ...

To simplify, let's say that a device should be represented by a device
node that is pretty much self contained. There should be no need to go
look at anything else (processor node, SVR register, whatever). You
should be able to uniquely identify every device in the system based on
a few properties, and OpenFirmware provides precisely a mecanism to do
so.

This mecanism, is the "compatible" property.

If you look closely at the OF PCI binding (since PCI is one of your
examples), you'll notice that while pciDDDD,VVVV (device,vendor) is at
the beginning of the compatible list, pciCCCC (class) follows.

Again, same logic as explained earlier: you define your device from the
more specific to the more generic.

In many cases, a device programming interface is generic (for example,
the UHCI, OHCI and EHCI USB host controller drivers, on PCI, match based
on the class, not the vendor/device IDs. They only use the later for
identifying a handful a chips that need erratas/quirks, they do NOT have
and do not need a complete list of all the vendor/device ID combinations
for those types of controllers).

That sort of class level matching is also widely used for USB devices.

Thus, the driver -choses- at what level it wants to detect supported
devices, based on that, -and- can still explicitely look at the more
"precise" indentification when it needs to single out a given
revision/version of a piece of hardware.

So this mecanism is great and isn't actually that clumsy at all. What
might eventually be clumsy is purely the naming choice when the vendor
doesn't provide something nice/unique enough for a given part. For
example, in order to properly identify the 52xx "fec" ethernet part,
since we don't have a nice/unique codename for it, we use mpc52xx-fec.
it's good enough and it's our convention.

For PCI devices, the compatible property is defined to be a fairly long
list, which can contain vid/did pairs (and multiple ones as one device
cna be made HW compatible with another one) but goes down to class based
matching which is more useful for well defined programming interfaces.

Strings are perfect, much better than numbers, as long as we properly
define the content of the string.

Ben.