One more thought -- I realized that even separating out "functionality"
for driver names will fly in the face of current emerging trends towards
"convergence". For example, new hardware from emulex, qlogic, and
others support HBA functionality *and* NIC functionality on the same
part. ConnectX parts from Mellanox can be used as a 10GbE, a
fibre-channel HBA, or an Infiniband HCA. Where do you put these?
driver/storage/... driver/network/.... driver/infiniband/... ?!?
Noting that the Solaris kernel *requires* that all kernel drivers have a
unique name (for the name_to_major mapping), maybe the simplest naming
format is driver/<driver> -- for example driver/hme or driver/hermon.
- Garrett
On 02/ 5/10 09:15 AM, Garrett D'Amore wrote:
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
