A little utility (needing supporting kernel system call) that took a
process id as input then dumps to stdout the total hardware stack
supporting every handle currently open to that process -- would be very
nice. If it already exists please let me know and forgive the newbie
mistake.
Please consider a whether a new member of the family
open/close/seek/read/write/ioctl is in order, whether its own call or a
new systemwide ioctl.
The main need is to provide a reliable way to know the
make/model/serial#" of each element of the hardware stack supporting an
open handle managed by local devices and drivers. Seems all I can find
are a pastiche of sporadically implemented IOCTL calls that vary
depending on the nature of the device (e.g. try to get the serial number
of an arbitrary USB device given an open handle, for instance) , or
really code-maintenance uber-unfriendly invitations to recover and parse
filename paths, cope with links, then rummage about in /proc /sys and dmesg.
So, something like:
handle = open("any file or device here",O_YourChoiceHere);
read_hardware_chain(handle,char *buffer,int buffersize);
Upon successful return "buffer" would contain one line for each bit of
physical technology used to provide access to handle.
"Vendor-lowest
level","Model-lowest-level","Serial-lowest-level","/sys/full-path-to-most-specific-info"\n
for example: handle=open("USB device X",O_RDONLY);
read_hardware_chain(handle,buffer,4096);
buffer gets set to:
"USB device vendor","Usb device model","usb device serial
#","/sys/more/info/here"\n
"Usb controller vendor","USB model","l","/sys/more/info/here"\n
"PCI bus bridge chip vendor","bridge chip model","","/sys/more/info/here"\n
"Southbridge vendor","Southbridge model","serial","/sys/more/info/here"\n
"Northbridge vendor","Northbridge model","northbridge
serial","/sys/more/info/here"\n
"Memory vendor","Memory model","Serial numbers of
chips","/sys/more/info/here"\n
"Processor vendor","Processor model/stepping","CPUID if
supported","/sys/more/info/here"\n
"distro name","kernel name","kernel versions","/sys/lotsaluck"\n
"Bios vendor","bios version","Bios serial","/sys/more/info/here"\n
"Overall system vendor","Overall system model","Overall system
serial#/support id tag","/sys/no/joy"\n
2 motivations:
Motivation 1: You have many device X's out there attached to various
boxen which come and go way more frequently than device X does, and all
the X's reports to and are controlled by a database. Each device X has
its own serial number which is the only reasonable choice to provide
access to X without making X management code have to know what host X is
plugged into for net access from moment to moment. You don't like the
really hackish looking code that has to text munge around both /proc and
/sys to try to tease out X's serial number, and having to examine every
new kernel for formatting changes in both those structures in order to
maintain X device support. And you don't want to have every driver
create its own non-standard internal IOCTL call number and format for
reporting config details and a second one for 'here's the path to my
parent device'. And you certainly don't want production code trying to
parse dmesg output messages looking for load time 'I found this
model/serial/brand/withcool-blue-lights, mounted on /dev/zippyhummer,
excelsior!' announcements.
Motivation2: Support help. Make more efficient the presently too
frequent reporting exchange "Accessing Foo is flaky when I do this"
"send a dmesg output" "where is foo loaded, which plug did you
use","Well, its a symbolic link that pointed to a CD yesterday but now
which LVM RAID did that get mounted on?" or "which USB device number is
that this boot - depends on whether the other cable was loose during the
udev scan" get a whole lot simpler.
Harry Coin
Quietfountain LLC
Bettendorf, Iowa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/