Henry Zhang writes: > > How does it compare with the existing prtconf and cfgadm interfaces? > prtconf and cfgadm can be used to get more information besides USB > devices, lsusb is only focus on usb devices information. In fact, you > can get lots of same information by prtconf.
It's hard to tell what the intended system architecture is supposed to look like. If we need to have separate "lsfoo" commands for each bus-type attachment technology, then I think that's probably a bad thing, and actually a regression from previous work where we tried to unify the tools. (Yes, I realize that you're "just" porting in an existing Linux utility.) > > What do you mean by "when building the source codes?" Are end users > > expected to recompile this utility on their own? If they're not, then > > why is that part of the delivery? > usb.ids is a simple list to record the vendor and product ID and name, I > just describe how usb.ids is created: it's installed into system when > build the source.. OK. > >>> /usr/share/usb.ids Project Private A list of all known USB ID > > > > I don't see how that's going to work. "/usr" is read-only inside > > sparse-root zones, and is generally unwritable to non-privileged > > users. > > > > "/var" sounds slightly better, given the nature of this file. > No, general user don't assume to write usb.ids, and it's read-only, not > everyone can change it, once you find there is new usb.ids, you may > download it from the webpage, then you have to su to root, and replace > the existed usb.ids file with the new one. Who does this? If it's the system administrator, then by doing this, he's breaking his packaging database. That's if he's able to do it at all -- if he's in a non-global zone with a sparse-root file system, then he's just plain stuck, and can't update the file himself. And when he next upgrades the system, his file will likely be reverted back to whatever is delivered with the package (unless you've made special provision for this to be writable, which itself argues for /var instead). How does the administrator know that he needs to do this and when to do it? Why is this different from the PCI-related tools? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
