Artem Kachitchkine wrote:
>
> Maintaining good programming practices is largely orthogonal to the
> bundled/unbundled discussion. If it's easier for someone to think in
> terms of consolidations, recall that the driver consolidation has been
> on the table and imagine that it happened. If I can uninstall a driver
> package (and those that depend on it) and still end up with a
> perfectly functional system, consider it not an integral part of the
> core system and continue using DDI like any other disciplined driver
> developer, ON or not.
>
> -Artem
Heh. That's a nice theory. Except for one "itsy bitsy little issue".
Except for drivers for a few well known classes, you *cannot* adhere to
the DDI simply because there is no DDI compliant way to populate /dev!
The devfsadm plugin framework is clearly not public (and its entirely
unsuited to being so right now... take a look at a plugin if you want
proof). There is, I guess, /etc/devlink.tab, from legacy ... although I
don't know that it was ever "documented" as such, apart from the inline
contents in the file. (And folks aren't supposed to be using that
anymore, are they? devfsadm plugins is the "preferred" way, although
like GLDv3, and probably a bunch of other things besides, it remains
"undocumented".)
Believe me, I'm all for the DDI. You can go and look at afe, which
apart from being GLDv3 is DDI compliant. (It was previously a DDI
compliant GLDv2 driver... even passed DDICT.) I don't think this
particular fight (the one with /devices) is worth it, though.
Anyway, if the only reasonable way for the heci driver to expose itself
to userland is via /dev, requiring a devfsadm plugin (ugh), then so be
it. I'll withdraw my suggestion, and instead request that if we are not
to use /devices for "internal communication", then the devfs project
team needs to gives us an easier and documented way to publish devlinks.
-- Garrett
