On 02/ 5/10 12:30 PM, [email protected] wrote:
On Fri, Feb 05, 2010 at 09:42:43AM -0800, [email protected] wrote:
1) drive/network/<vendor>/<driver> (for example
driver/network/sun/hme) is IMO an absolutely terrible idea -- it
flies in the face of my experience with NIC drivers.
Specifically, its often the case that a driver supports parts from
multiple vendors, or that a vendor is renamed, disbanded, or
acquired. (For example, would driver/network/digital/dnet make
sense? Even knowing that the dnet parts were *most recently* an
Intel product, and that the driver could theoretically support
>from dozens of other vendors of tulip workalikes? Or what about
SUNWafe -- I don't see it in the above list, but
driver/vendor/admtek/afe makes no sense at all, since ADMtek was
acquired by Infineon. It also potentially creates problems for
vendor names that really should have weird capitalization, etc.)
Upshot, I'd *strongly* suggest dropping the<vendor> component,
and just leave the<driver> suffix.
2) I'd make the same comment about other packages like
driver/storage/sas/pmc-sierra/pmcs or
driver/fibre-channel/qlogic/qlc. Drop the<vendor> component from
the package name. The<driver> component has to be unique to
operate correctly on the system anyway, so I don't see how a
<vendor> component helps anyone.
3) The same thing can be said about graphics drivers.
The intent of the vendor subcomponent wasn't necessarily to capture the
vendor producing the chipsets but rather the one who owns the
specification.
That said, I'm certainly not wedded to keeping the vendor name there
particularly if others have related concerns.
What's our plan to cope with different vendors that deliver equivalent
drivers? It doesn't seem all that far fetched to have
driver/network/sun/e1000g and driver/network/intel/e1000g.
Isn't that handled by the (elided) supplier component of the package
name? I.e. as I understand the package name will actually be
opensolaris.org somesuch...
Note that for drivers, having different vendors supply different drivers
for the same *hardware* (with either the same name or a different name)
is particularly problematic -- it leads to lots of confusion and support
headaches -- resolving incompatible bindings between such packages can
be troublesome -- because at the end of the day the kernel can only bind
*one* driver to a specific piece of hardware.
If this sounds like a recommendation to vendors to avoid shipping
unbundled binaries to "override" system supplied drivers.... well it is!
- Garrett
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
