A fresh look at the kernel's device model

I can see how this is possible. I'm having trouble seeing how it is useful. Is there an example I can look at?

I can almost imagine that a bus might be able to include some of its devices in one class and some in another class. But I think I would either just make them different types, or have two related devices, one in the bus one in the class. Maybe an example will help clarify for me.

Thanks!

Doesn't multi-path I/O break this constraint by having the same piece of hardware accessible through multiple hardware busses? Then a bus address identification no longer identifies an unique device, and there would possibly be fewer hardware devices than there are bus addresses associated with them. Conceptually there's little that stops a PCI-like hardware bus from being accessible through multiple bridges as well, e.g. in some weird-arse redundant cluster environment.

This whole set-up sounds like an ad-hoc reimplementation of a shitty Java, with "struct device" corresponding to the Object base class, and classes to interfaces, but only permitting one class per device (thereby e.g. splitting multi-class devices into many and a "parent" device that handles PM for them all). The temptation to tear it down for simplification's sake is obvious. However, there's a lot of good in having a structure that forbids explosions of abstract hierarchy wank during future development, especially when the obvious alternative would replace the structural hierarchy with a more homogenous structure (i.e. like Java, but not as shittily) and force a mild level of such wank for an ante to achieve functional parity.

Really the question is: what are the policies associated with the flexibly homogeneous substitute, and how do they combine to a better outcome in the next 15 years than the current status? Does having such policies, instead of program-defined structure, reduce the kernel's architectural strength? If so, shouldn't that policy be part of the kernel in some way that retains that strength (by e.g. being as much subject to debate as changes to code are) to the degree that historically-proven code does?

The "Unix way" is, roughly speaking, one where the kernel provides low-level mechanisms that arise from the combined natures of hardware and OS concepts, and lets consumers define policy to their detriment alone. With udev and the other freedesktop.org stuff we've seen over the past decade, this separation has become reversed: now userspace policy is entering the kernel and influencing its architecture. This trend is not currently showing signs of being about to reverse, so I question whether it should have a potential in-road to the eventual flattening (and thereby vendorization) of device drivers within the kernel.