I just heard about the details of the grand package renaming, and got
details from Alan C
at this URL:
http://defect.opensolaris.org/bz/attachment.cgi?id=3476
I wanted to share some thoughts I had:
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.
4) SUNWhmdu -- I think this package can simply be eliminated. In any
case, there are no more hme related headers in this package, so it would
be better to rename it to driver/storage/scsi/fas/header or somesuch.
(The headers are only for the "fas" SCSI driver.)
5) SUNWqfed -- I'd like to see this merged into driver/network/sun/hme
(without /sun of course) -- the qfe driver is a thin compatibility shim
around "hme".
6) SUNWhmd -- the "fas" SCSI driver in this package has nothing to do
with hme itself, but was delivered this way for historical reasons (the
SunSwift card that came with both the "fas" SCSI chip and the "hme" chip
on the same add-in card.) Probably "fas" should be broken into a driver
package of its own. (driver/storage/scsi/fas or somesuch.)
7) SUNWauda -- command/audio/audioplay isn't ideal. This package also
includes audiotest, audioctl, audioconvert, and audiorecord. I'd prefer
command/audio/utility or somesuch.
8) SUNWaudd -- driver/audio/misc isn't ideal. I'd actually preferred to
have split this package up into driver/audio/core (which would include
the "audio" and "ac97" modules), and separate packages for other drivers
like audiocs, audiopci, audioens, audiots, and audio1575. Only "audio"
and "ac97" are common dependencies for the other audio driver packages.
9) SUNWos86r -- actually this package delivers "sd", "etc/bootrc", and
"etc/mach". "sd" in particular is the *disk* driver generally used for
SATA and SCSI. So, I don't think driver/network/misc is good here. In
fact, I'd rather see "elxl", "iprb", "pcn", and "spwr" split into
separate packages. (Indeed, I've already done this for elxl in my
upcoming changes to deliver an open source replacement. Let me know if
you want to check the webrev on SWAN.)
10) I wish I could see the rest of the list... what about the other
driver packages for audio drivers, or some of the other NIC drivers
(SUNWafe, SUNWmxfe, etc.)?
Anyway, I hope this feedback is useful and helpful. Thanks.
- Garrett
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
