lshwd - lists hardware devices and their approp modules.
currently supports pci and usb devices, using pcilib and usblib. program also uses pcitable & usbtable files (can be located at same directory or /usr/share/hwdata) for displaying extended description and module names. module names are then parsed for generic names and changes accordingly.
hmm... out of bordem? mostly for knowledge :-)
lshwd is a basic device lister with some very handy options. ideally, its functionality should be similiar to kudzu/hwsetup but without the lag. when used with '-a' (once implemented...) it should auto-load approp modules. lshwd is intended for anyone who wants to quickly check for his hardware specific modules without too much hastle, for quick live-cds auto-detection and configure, 1st time linux n00bs, etc.
lshwd tried to mimic the lsxxx tools family (lspci,lsusb) output when no commandline is specified. using '-cc' option provides a more "user-friendly" output.
- add pcmcia support
- add device id display (minor stuff)
- add auto-modprobe (should be minor stuff...)
lshwd [-a] [-c] [-cc] [-d] [-id] [-m] [-n]
-a auto-modprobe (not yet implemented)
-c categorized output
-cc colorized & categorized output
-d display default description
-id display hardware id (not yet implemented)
-m machine readable format
-n no duplicates
+ usb recoded, now using usblib
+ changed usb class names (hopefully correct this time)
+ minor bugs fixes and code cleaning (code size reduced)
+ added usb devices detection
+ changed and added some commandline options
+ changed output formats
+ changed default options
+ added new output formats
+ added new commandline options
+ added psaux mouse detection
+ tries to mimic lsxxx tools look-n-feel on default
+ pci devices supported
+ ansi output
visit the hwd forum here
or email me to z4ziggy at bliss-solutions dot org
for latest cvs snapshot, check out http://www.bliss-solutions.org/archlinux/webpm/
(use guest/guest for user/pass)
this is my 1st ever open-source project and my 1st ever linux coding experience... please - be gentle... :twisted:
although it doesn't pretain to me, maybe firewire scanning in addition to usb?
and don't be afraid to pawn some minor work and/or reasearch off on me, as I posted in the hwd forums... I'm busy but I can do minor stuff in me free time
damn right man, and tnx, surely i'll bug u with testing/debugging stuff. i totally forgot about firewire... :oops: i'll dl whatever lib/headers are needed and start to play. i just need to sort out some new bug in the usb output... u kill one, two of them shows up... :?
...i totally forgot about firewire...
I hope you get it to work. In earlier hwd-3.x included this feature. But when detecting even there is no firewire, it was removed ... blame the Knoppix.
any idea how to enum the firewire devices? in kudzu there seems to be a very simple/basic firewire.c which browses "/proc/bus/ieee1394/devices" and only supports 1 driver : "sbp2". i dont know if thats sufficient, and i cant test it since i dont have firewire on my pc.
there is raw1394 which is a complete API and lib set for ieee1394 but its a module by itself, and i dont think normal firewire users actually install it, so i prefer not using it to eliminate dependency problems.
also, i cant seem to find any firewire modules file to associate a device with its kernel module (like pcitable & usbtable files) - any info on this subject will be greatly appreciated too. kudzu btw, simply formats the info found on "/proc/bus/ieee1394/devices" but i dont know if thats sufficient, specially if those devices are only shown once the module is loaded, which basicly makes using "/proc/bus/ieee1394/devices" useless (lshwd should display hardware devices, even if modules are not loaded).
It appears that detection isn't needed, but I only read it quickly
* Brief Description: * * This driver implements the Serial Bus Protocol 2 (SBP-2) over IEEE-1394 * under Linux. The SBP-2 driver is implemented as an IEEE-1394 high-level * driver. It also registers as a SCSI lower-level driver in order to accept * SCSI commands for transport using SBP-2. * * Driver Loading: * * Currently, the SBP-2 driver is supported only as a module. Because the * Linux SCSI stack is not Plug-N-Play aware, module load order is * important. Assuming the SCSI core drivers are either built into the * kernel or already loaded as modules, you should load the IEEE-1394 modules * in the following order: * * ieee1394 (e.g. insmod ieee1394) * ohci1394 (e.g. insmod ohci1394) * sbp2 (e.g. insmod sbp2) * * The SBP-2 driver will attempt to discover any attached SBP-2 devices when first * loaded, or after any IEEE-1394 bus reset (e.g. a hot-plug). It will then print * out a debug message indicating if it was able to discover a SBP-2 device. * * Currently, the SBP-2 driver will catch any attached SBP-2 devices during the * initial scsi bus scan (when the driver is first loaded). To add or remove * SBP-2 devices after this initial scan (i.e. if you plug-in or un-plug a * device after the SBP-2 driver is loaded), you must either use the scsi procfs * add-single-device, remove-single-device, or a shell script such as * rescan-scsi-bus.sh. * * The easiest way to add/detect new SBP-2 devices is to run the shell script * rescan-scsi-bus.sh (or re-load the SBP-2 driver). This script may be * found at: * http://www.garloff.de/kurt/linux/rescan-scsi-bus.sh * * As an alternative, you may manually add/remove SBP-2 devices via the procfs with * add-single-device <h> <b> <t> <l> or remove-single-device <h> <b> <t> <l>, where: * <h> = host (starting at zero for first SCSI adapter) * <b> = bus (normally zero) * <t> = target (starting at zero for first SBP-2 device) * <l> = lun (normally zero) * * e.g. To manually add/detect a new SBP-2 device * echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi * * e.g. To manually remove a SBP-2 device after it's been unplugged * echo "scsi remove-single-device 0 0 0 0" > /proc/scsi/scsi * * e.g. To check to see which SBP-2/SCSI devices are currently registered * cat /proc/scsi/scsi * * After scanning for new SCSI devices (above), you may access any attached * SBP-2 storage devices as if they were SCSI devices (e.g. mount /dev/sda1, * fdisk, mkfs, etc.). * * * Module Load Options: * * The SBP-2 driver now has a number of module load parameters available for use * in debugging/testing. Following are the valid parameters * * no_bus_scan - Skip the initial scsi bus scan during module load * (1 = skip bus scan, 0 = perform bus scan, default = 0) * * mode_sense_hack - Emulate mode sense for devices like 1394 memory stick readers * (1 = emulate/fake mode sense, 0 = do not emulate/fake mode sense, default = 0) * * max_speed - Force max speed allowed * (0 = 100mb, 1 = 200mb, 2 = 400mb, default = auto configure) * * serialize_io - Force scsi stack to send down one command at a time, for debugging * (1 = serialize all I/O, 0 = do not serialize I/O, default = 1) * * no_large_packets - Force scsi stack to limit max packet size sent down, for debugging * (1 = limit max transfer size, 0 = do not limit max packet size, default = 0) * * (e.g. insmod sbp2 no_bus_scan=1) * * * Current Support: * * The SBP-2 driver is still in an early state, but supports a variety of devices. * I have read/written many gigabytes of data from/to SBP-2 drives, and have seen * performance of more than 16 MBytes/s on individual drives (limit of the media * transfer rate). * * Following are the devices that have been tested successfully: * * - Western Digital IEEE-1394 hard drives * - Maxtor IEEE-1394 hard drives * - VST (SmartDisk) IEEE-1394 hard drives and Zip drives (several flavors) * - LaCie IEEE-1394 hard drives (several flavors) * - QPS IEEE-1394 CD-RW/DVD drives and hard drives * - BusLink IEEE-1394 hard drives * - Iomega IEEE-1394 Zip/Jazz drives * - ClubMac IEEE-1394 hard drives * - FirePower IEEE-1394 hard drives * - EzQuest IEEE-1394 hard drives and CD-RW drives * - Castlewood/ADS IEEE-1394 ORB drives * - Evergreen IEEE-1394 hard drives and CD-RW drives * - Addonics IEEE-1394 CD-RW drives * - Bellstor IEEE-1394 hard drives and CD-RW drives * - APDrives IEEE-1394 hard drives * - Fujitsu IEEE-1394 MO drives * - Sony IEEE-1394 CD-RW drives * - Epson IEEE-1394 scanner * - ADS IEEE-1394 memory stick and compact flash readers * (e.g. "insmod sbp2 mode_sense_hack=1" for mem stick and flash readers)) * - SBP-2 bridge-based devices (LSI, Oxford Semiconductor, Indigita bridges) * - Various other standard IEEE-1394 hard drives and enclosures * * * Performance Issues: * * - Make sure you are "not" running fat/fat32 on your attached SBP-2 drives. You'll * get much better performance formatting the drive ext2 (but you will lose the * ability to easily move the drive between Windows/Linux). * * - In ohci1394.h, remove the IEEE1394_USE_BOTTOM_HALVES #define, and rebuild. * This will give you around 30% to 40% performance increase. * * * Current Issues: * * - Currently, all I/O from the scsi stack is serialized by default, as there * are some stress issues under investigation with deserialized I/O. To enable * deserialized I/O for testing, do "insmod sbp2 serialize_io=0" * * - Hot-Plugging: Need to add procfs support and integration with linux * hot-plug support (http://linux-hotplug.sourceforge.net) for auto-mounting * of drives. * * - Error Handling: SCSI aborts and bus reset requests are handled somewhat * but the code needs additional debugging. * * - IEEE-1394 Bus Management: There is currently little bus management * in the core IEEE-1394 stack. Because of this, the SBP-2 driver handles * detection of SBP-2 devices itself. This should be moved to the core * stack. * * - The SBP-2 driver is currently only supported as a module. It would not take * much work to allow it to be compiled into the kernel, but you'd have to * add some init code to the kernel to support this... and modules are much * more flexible anyway. ;-) * * - Workaround for PPC pismo firewire chipset (enable SBP2_PPC_PISMO_WORKAROUND * define below).
EDIT: switched from "quote" to "code" due to escaping some text as bold tags...
1st, tnx for the (damn) quick reply!
about the site - for some reason it wont load. ive been trying since yesterday, dunno if its an isp related problem... might try to use proxy l8r to make sure.
anyway, about the sbp2, if i understand correctly, this is a module for communicating with ieee1394 devices plus scsi support, which also provides a /proc/scsi dir for those devices. are modules "iee1384" "ohci1394" "sbp2" are -all- modules which are needed for -all- firewire devices? no specific modules per device?
also, is sbp2 is the standard for ieee1394, ie, all firewire users simply use it to use their firewire devices? again, i never used firewire so i might have some problems on this subject...
1. rasat sent me the rescan-scsi-bus.sh script, which browses /proc/scsi dir, im guessing because of the bsd2 behavior.
2. the usb bug in ver 0.4 was squashed, hopefully for good this time... will update cvs soon.
i haven't seen this thread before,
nice little project to rewrite hwd in c
it works pretty good and the -cc option looks great
it shows that i use "usb-uhci" but i think it should be "uhci-hcd"
it could be a bug,
keep it up,
arch + gentoo + initng + python = enlisy
i've fixed the 2.4/2.6 usb modules naming in latest version (0.5), and added pcmcia support.
hopefully soon firewire will be added to close the deal...
yes, it works now,
arch + gentoo + initng + python = enlisy
project updated : version 1.0-rc1
+ fixed mouse issue
+ added comments to code
+ added xinfo output (saved to /tmp/xinfo)
+ added attached usb communication device
+ minor bugs fixes
if all goes well, we will release version 1.0 shortly and move on