On 02/ 5/10 11:35 AM, [email protected] wrote:
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/... ?!?
Yes, there was one such package at the moment. I believe providing
some sort of functional boundary is still useful in the namespace. As
more such drivers are integrated, we can certainly carve out additional
namespace, or rely on some sort of ordering (namely if a driver
delivers both HBA and NIC functionality, put it under storage.)
I'm thinking fibre-channel breaks this as well. I realized just a few
minutes ago that there is an IP networking stack that can be used with
fibre-channel. The picture is already some what gray, and its just
going become more so as we move forward.
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.
Yes but it can be useful to use the namespace to list, for example, all
of the audio driver packages. I believe keeping that subcomponent in
the name is extremely useful.
I originally thought so too, I'm just not sure it really helps, and I
see potential issues like those I've already outlined. My opinion about
dropping the category isn't really strong, but I'm also a bit
unconvinced that we're really buying anything by having it.
I've included some changes to the proposed driver packages below. It's
important to note we know this isn't going to be perfect and that it's
certain we're going to need to rename many of these again at some point
(particularly as we refactor the packages themselves.) But now that we
have a proper rename facility in the packaging system, this should be
easier in the future.
Sure. I hpoe you don't mind if I give you some suggestions you can
implement immediately, though.
SUNWaudd driver/audio
This is better. After this integrates I'll split out the other
individual drivers into smaller packages.
SUNWadixp driver/audio/audioixp
SUNWaudiocmi driver/audio/audiocmi
SUNWaudioemu10k driver/audio/audioemu10k
SUNWaudiols driver/audio/audiols
SUNWaudiop16x driver/audio/audiop16x
SUNWaudiosolo driver/audio/audiosolo
SUNWad810 driver/audio/audio810
SUNWaudiohd driver/audio/audiohd
SUNWvia823x driver/audio/audiovia823x
SUNWaudiovia97 driver/audio/audiovia97
SUNWdcaf driver/crypto/dca
SUNWn2cp driver/crypto/n2cp
SUNWemlxs driver/fibre-channel/emlxs
SUNWfcip driver/fibre-channel/fcip
SUNWfcp driver/fibre-channel/fcp
SUNWfcsm driver/fibre-channel/fcsm
SUNWfctl driver/fibre-channel/fp
SUNWqlc driver/fibre-channel/qlc
SUNWqlcu driver/fibre-channel/qlc/qlc-mdb
Hmm... does it really make the most sense for mdb modules to be
categorized this way? How about system/mdb/qlc ? Just offering an
alternate suggestion for a somewhat less awkward name.
SUNW1394 driver/firewire
SUNWav1394 driver/firewire/av1394
SUNWfwdc driver/firewire/dcam1394
SUNWsbp2 driver/firewire/sbp2
SUNWscsa1394 driver/firewire/scsa1394
SUNWagp driver/graphics/agpgart
SUNWastfb driver/graphics/ast
SUNWatigfx driver/graphics/atiatom
SUNWdrmr driver/graphics/drm
NVDAgraphics driver/graphics/nvidia
SUNWefb driver/graphics/efb
SUNWkfb driver/graphics/kfb
SUNWfipe driver/i86pc/fipe
SUNWdcopy driver/i86pc/ioat
SUNWpsdcr driver/i86pc/platform
SUNWib driver/infiniband
SUNWarbel driver/infiniband/arbel
SUNWhermon driver/infiniband/hermon
SUNWipoib driver/infiniband/ibd
SUNWibdma driver/infiniband/ibdma
SUNWrds driver/infiniband/rds
SUNWrpcib driver/infiniband/rpcib
SUNWibsdp driver/infiniband/sdp
SUNWibsdpib driver/infiniband/sdpib
SUNWtavor driver/infiniband/tavor
SUNWafe driver/network/afe
SUNWamd8111s driver/network/amd8111s
SUNWarn driver/network/arn
SUNWatge driver/network/atge
SUNWatheros driver/network/ath
SUNWuath driver/network/uath
SUNWatu driver/network/atu
SUNWbfe driver/network/bfe
SUNWbge driver/network/bge
BRCMbnx driver/network/bnx
BRCMbnxe driver/network/bnxe
SUNWchxge driver/network/chxge
SUNWpcan driver/network/pcan
SUNWdmfe driver/network/dmfe
SUNWintgige driver/network/e1000g
SUNWigb driver/network/igb
SUNWipw driver/network/ipw
SUNWiwh driver/network/iwh
SUNWiwi driver/network/iwi
SUNWiwk driver/network/iwk
SUNWiwp driver/network/iwp
SUNWixgb driver/network/ixgb
SUNWixgbe driver/network/ixgbe
SUNWwpi driver/network/wpi
SUNWpcwl driver/network/pcwl
SUNWmxfe driver/network/mxfe
SUNWmwl driver/network/mwl
SUNWyge driver/network/yge
SUNWmyri10ge driver/network/myri10ge
SUNWxge driver/network/xge
SUNWntxn driver/network/ntxn
SUNWnge driver/network/nge
SUNWos86r driver/network/platform
Again, "sd" is in here (unless you moved it), and it has *nothing* to do
with networking. driver/platform/misc might be better. Ultimately this
package needs to go away, and broken into its constituent parts. I'll
help with that post integration.
SUNWpacket driver/network/pseudo/bpf
SUNWllc driver/network/pseudo/llc2
Interesting. I can't decide whether I like the "pseudo" component or
not... I think its fine for now though. (Do drivers like "vnic" also
have a similar naming component?)
SUNWralink driver/network/ral
SUNWrum driver/network/rum
SUNWrwd driver/network/rwd
SUNWrwn driver/network/rwn
SUNWural driver/network/ural
SUNWrge driver/network/rge
SUNWrtls driver/network/rtls
SUNWrtw driver/network/rtw
SUNWurtw driver/network/urtw
SUNWsfe driver/network/sfe
SUNWced driver/network/ce
SUNWerid driver/network/eri
SUNWged driver/network/ge
SUNWhmd driver/network/hme
I'll break this apart into driver/network/hme and driver/storage/fas later.
SUNWhmdu driver/network/hme/hme-header
Actually, this doesn't have any hme headers in it! It only has SCSI
headers for the "fas" SCSI controller. It either should be changed to
driver/storage/fas/header, or (better) just eliminated since nobody
really needs these headers on their end systems. (They are only used to
compile the "fas" driver itself, and not part of any public interface.)
SUNWhxge driver/network/hxge
SUNWniumx driver/network/niumx
SUNWnxge driver/network/nxge
SUNWqfed driver/network/qfe
SUNWvr driver/network/vr
SUNWzyd driver/network/zyd
SUNWpcmci driver/pcmcia
SUNWpsdpr driver/pcmcia/pcata
SUNWpcser driver/pcmcia/pcser
Hmm.... here we are categorizing driver by the bus they connect to
rather than the type of service they support. This is a bit
inconsistent. driver/network/pcan is for PCMCIA devices, but it isn't
here. I think I'd prefer not to name drivers for the bus they connect
to, but rather for the services they provide. So I'd rename these two
as driver/storage/pcata and driver/serial/pcser.
SUNWus driver/sparcv9/us
"sparcv9"? Would "driver/cpu/us" be better? (A single "cpu" category
for any other CPU specific drivers that we might want later?)
SUNWarcmsr driver/storage/arcmsr
SUNWspsv driver/storage/sv
SUNWbcmsata driver/storage/bcm_sata
SUNWfcoe driver/storage/fcoe
SUNWfcoei driver/storage/fcoei
SUNWfcoet driver/storage/fcoet
CPQary3 driver/storage/cpqary3
SUNWpsdir driver/storage/isa
"isa" isn't a storage driver. Its a bus driver for "ISA" bus. (ISA is
a system bus, sort of like PCI.) That said looking at the drivers that
are in here, I see "ata" and "pci-ide", and not "isa". Probably a
better name for this is driver/storage/ata -- the fact that pci-ide is
included in with ata is probably something we can overlook given that
the two have a close relationship.
SUNWsrpt driver/storage/srpt
SUNWlsimega driver/storage/lsimega
SUNWmegasas driver/storage/mega_sas
SUNWmptsas driver/storage/mpt_sas
SUNWmrsas driver/storage/mr_sas
SUNWpmcs driver/storage/pmcs
SUNWsmpd driver/storage/smp
SUNWahci driver/storage/ahci
SUNWmv88sx driver/storage/marvell88sx
SUNWnvsata driver/storage/nv_sata
SUNWsi3124 driver/storage/si3124
SUNWaac driver/storage/aac
SUNWadpu320 driver/storage/adpu320
SUNWamr driver/storage/amr
SUNWses driver/storage/ses
SUNWluxd driver/storage/sf
SUNWluxl driver/storage/socal
SUNWssad driver/storage/ssd
SUNWtpm driver/tpm
If driver/crypto were renamed to driver/security, then this could be
driver/security/tpm. It has a "crypto" component to it as well, but it
provides services beyond just acting as a KCF crypto provider.
SUNWusb driver/usb
SUNWuedg driver/usb/usbser_edge
SUNWukspfw driver/usb/usbs49_fw
SUNWuksp driver/usb/usbsksp
SUNWuprl driver/usb/usbsprl
SUNWuacm driver/usb/usbsacm
SUNWusbs driver/usb/usbser
SUNWugen driver/usb/ugen
SUNWuftdi driver/usb/usbftdi
SUNWusbvc driver/usb/usbvc
The same kind of comments I made about USB probably apply here. I'd
rename these as:
driver/usb/uedg -> driver/serial/usbser_edge
driver/usb/usbsksp -> driver/serial/usbsksp
driver/usb/usbs49_fw -> driver/serial/usbs49_fw (actually, this is
firmware for usbsksp, I'd probably recommend merging the packages!)
driver/usb/usbsprl -> driver/serial/usbsprl
driver/usb/usbftdi -> driver/serial/usbftdi
driver/usb/usbser -> driver/serial/usbser
driver/usb/usbsacm -> driver/serial/usbsacm
driver/usb/usbvc -> driver/video/usbvc (this is a video capture
device, not sure about the category)
You'd leave driver/usb/ugen unmodified, since it really is just a
general purpose USB driver. It might be a good idea to merge it into
driver/usb since it really represents core USB functionality.
(Specifically kernel support for libusb.)
SUNWxwdv driver/x11/winlock
SUNWxsvc driver/x11/xsvc
SUNWxvmpv driver/xvm/pv
Hope this helps a bit.
- Garrett
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
