[...]
> Why is this different from the PCI-related tools?
As someone who might use this, I see some differences about USB:
* USB is _routinely_ hot-pluggable, typically by end users (although the
ability to
lock it down would certainly be desirable in some settings)
* it doesn't necessarily take a kernel driver to support a new device, they
could
be handled using libusb (or its successor) instead
That makes them a rather more dynamic situation in terms of new device support
on-the-fly
than most other interfaces, so something that focuses specifically on USB
devices, and
can obtain updated information on demand (together with what the devices
identify
themselves as) could be quite helpful.
Not having used usbutils on Linux, I'm not sure whether or not they're quite
quite I describe
here.
However, I think you have a point, in that if there were libusb and generic
driver equivalents
for FireWire and (eventually) Bluetooth, similar notions would apply to them as
well. Parallel
tools for them, such that they could all be (in a GUI context) submenus of a
menu of
hot-pluggable devices with potentially online support for additional {info,
drivers, ...}, would
probably be ideal.
Of course, 2008/504 looks like it's quite a bit broader than just e.g. USB, so
maybe there is
a place for One Tool to Rule Them All.
Given the apparent expectation that OpenSolaris (the distro) and/or
Solaris.next provide
a high level of Linux familiarity, perhaps the ideal would be to take a lot of
these things
(provided they met basic security, copyright, etc constraints) but take them
with the
advertised understanding that they were potentially transitory, and at the same
time try
and engage upstream (or implement independently if justifiable) to advance a
more
comprehensive and architecturally sound approach.
Or maybe one could move toward one infrastructure, with various
compatibility/familiarity
CLIs or GUIs to serve as migration aids.
The goals of looking a lot like something else and of doing things in the most
sound manner
possible are mutually exclusive _unless_ the former has a path to evolve into
the latter,
with the engagement of enough of a wider community that they too will start
working more
in terms of a bigger picture rather than their own individual project fiefdoms
and glory.
(ISTR a saying "lead, follow, or get the he** out of the way"; IMO that closely
models this
situation, particularly keeping in mind that leading effectively is no
cakewalk.)
This message posted from opensolaris.org
