On 02/ 5/10 01:48 PM, [email protected] wrote:
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.
This is an example of one of the easy refactoring (or in this case,
combining) that we want to do but for the moment, we're focusing given
our constraints on strictly renaming. My expectation is that SUNWqlcu
will cease to exist in the near future but we're not committing to
doing that right now.
(MDB modules are actually interesting because they're useful on systems
where the hardware may not be present or being used. But as they're
typically delivered with other parts of the "usr" package, they've
traditionally been included and presumedly they could be marked with a
"debugger" facet or the like.)
Agreed, we can examine this after the initial integration.
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.
Aye, this was a compromise since everything else in the package *is*
network related. And agreed, this whole package needs to be separated
into distinct driver packages but that's post the IPS transition.
In the meantime can we rename it to driver/platform/misc or somesuch?
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?)
I can go either way with respect to "pseudo" - since we're not carving
up "network" into things like "ethernet", "wireless", etc, perhaps it
should go.
With respect to "vnic", perhaps I'm misunderstanding the question -
that driver itself is part of SUNWckr (another package in need of
refactoring.)
vnic is a pseudo-network driver as well. Its in SUNWckr for good reason
-- its a part of the core networking stack. I can possibly see that
argument being made for the other two above, but it seems less clear.
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.)
Fair point - we'll change this is driver/storage/fas/fas-header for now
but eventually it should just be delivered with the refactored "fas"
package.
Ok. Actually, I'm pretty strongly in favor of not delivering
driver-specific private header files, and that's what these are. I
already removed the ones for "hme" itself, but I didn't feel confident
doing that for storage drivers at the time. Since then I've convinced
myself that this is the right thing to do, I just haven't got around to
it yet.
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.
This is another one of those packages that needs to be blown up with
all due force. I suspect the "isa" came from the description
originally. I'm fine with changing this to driver/storage/ata.
Actually, once you have done the rename, there won't be anything else in
there *except* the ata and pci-ide drivers. So blowing it up isn't the
right answer. Renaming it *is*, however. :-)
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.
How about we put this under driver/security/tpm and move the crypto
ones to driver/security/crypto/<whatever>.
Hmm... seems like two levels (security/crypto) might be awkward, and I'm
not entirely sure that there is any benefit to having it that way.
Alternatives:
driver/security/<driver> for all crypto and tpm drivers, or
driver/crypto/tpm (for just tpm)
I don't have a huge opinion about it one way or the other -- perhaps the
folks who work on this stuff will have a stronger opinion.
driver/usb/usbvc -> driver/video/usbvc (this is a video capture
device, not sure about the category)
The only related subcomponent would be "graphics" (and input graphics
device) but I'm not sure if that fits either. On the other hand, there
are graphics cards that do both video in/out so perhaps it does.
Yeah, the category to use wasn't immediately obvious to me.
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.)
Understood although we'll hold off on that until the refactoring work
begins.
Fair enough!
Hope this helps a bit.
Definitely. Thanks for the comments.
You're quite welcome!
- Garrett
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
