Part of lp.hardwaredb.scripts.hwdbsubmissions View In Hierarchy
Known subclasses: lp.hardwaredb.scripts.hwdbsubmissions.HALDevice, lp.hardwaredb.scripts.hwdbsubmissions.UdevDevice
Method | __init__ | Undocumented |
Method | addChild | Add a child device and set the child's parent. |
Method | device_id | A unique ID for this device. |
Method | pci_class | The PCI device class of the device or None for Non-PCI devices. |
Method | pci_subclass | The PCI device sub-class of the device or None for Non-PCI devices. |
Method | usb_vendor_id | The USB vendor ID of the device or None for Non-USB devices. |
Method | usb_product_id | The USB product ID of the device or None for Non-USB devices. |
Method | scsi_vendor | The SCSI vendor name of the device or None for Non-SCSI devices. |
Method | scsi_model | The SCSI model name of the device or None for Non-SCSI devices. |
Method | vendor | The vendor of this device. |
Method | product | The vendor of this device. |
Method | vendor_id | The vendor ID of this device. |
Method | product_id | The product ID of this device. |
Method | vendor_id_for_db | The vendor ID in the representation needed for the HWDB tables. |
Method | product_id_for_db | The product ID in the representation needed for the HWDB tables. |
Method | driver_name | The name of the driver contolling this device. May be None. |
Method | scsi_controller | Return the SCSI host controller for this device. |
Method | translateScsiBus | Return the real bus of a device where raw_bus=='scsi'. |
Method | translatePciBus | Undocumented |
Method | is_root_device | Return True is this is the root node of all devicese, else False. |
Method | raw_bus | Return the device bus as specified by HAL or udev. |
Method | real_bus | Return the bus this device connects to on the host side. |
Method | is_real_device | True, if the HAL device correspends to a real device. |
Method | getRealChildren | Return the list of real child devices of this devices. |
Method | has_reliable_data | Can this device be stored in the HWDB? |
Method | getScsiVendorAndModelName | Separate vendor and model name of SCSI decvices. |
Method | getDriver | Return the HWDriver instance associated with this device. |
Method | ensureVendorIDVendorNameExists | Ensure that a useful HWVendorID record for self.vendor_id exists. |
Method | createDBData | Create HWDB records for this HAL device and its children. |
Method | createDBDriverData | Create HWDB records for drivers of this device and its children. |
USB and PCI IDs are represented in the database in hexadecimal, while the IDs provided by HAL are integers.
The SCSI vendor name is right-padded with spaces to 8 bytes.
USB and PCI IDs are represented in the database in hexadecimal, while the IDs provided by HAL are integers.
The SCSI product name is right-padded with spaces to 16 bytes.
The kernel uses the SCSI layer to access storage devices
connected via the USB, IDE, SATA buses. See is_real_device
for more details. This method determines the real bus
of a device accessed via the kernel's SCSI subsystem.
Returns | A bus as enumerated in HWBus or None, if the bus cannot be determined. |
True, if the HAL device correspends to a real device. In many cases HAL has more than one device entry for the same physical device. We are only interested in real, physical, devices but not in the fine details, how HAL represents different aspects of them. For example, the HAL device node hiearchy for a SATA disk and its host controller looks like this: HAL device node of the host controller udi: .../pci_8086_27c5 HAL properties: info.bus: pci pci.device_class: 1 (storage) pci.device_subclass: 6 (SATA) info.linux.driver: ahci HAL device node of the "output aspect" of the host controller udi: .../pci_8086_27c5_scsi_host HAL properties: info.bus: n/a info.driver: n/a info.parent: .../pci_8086_27c5 HAL device node of a hard disk. udi: .../pci_8086_27c5_scsi_host_scsi_device_lun0 HAL properties: info.bus: scsi info.driver: sd info.parent: .../pci_8086_27c5_scsi_host HAL device node of the "storage aspect" of the hard disk udi: .../storage_serial_1ATA_Hitachi_HTS541616J9SA00_SB... HAL properties info.driver: n/a info.parent: .../pci_8086_27c5_scsi_host_scsi_device_lun0 HAL device node of a disk partition: udi: .../volume_uuid_0ee803cf_... HAL properties info.driver: n/a info.parent: .../storage_serial_1ATA_Hitachi_HTS541616J... (optionally more nodes for more partitions) HAL device node of the "generic SCSI aspect" of the hard disk: udi: .../pci_8086_27c5_scsi_host_scsi_device_lun0_scsi_generic info.driver: n/a info.parent: .../pci_8086_27c5_scsi_host_scsi_device_lun0 This disk is _not_ a SCSI disk, but a SATA disk. In other words, the SCSI details are in this case just an artifact of the Linux kernel, which uses its SCSI subsystem as a "central hub" to access IDE, SATA, USB, IEEE1394 storage devices. The only interesting detail for us is that the sd driver is involved in accesses to the disk. Heuristics: - Most real devices have the property info.bus; we consider only those devices to be real which have this property set. - As written above, the SCSI bus often appears as an artifact; for PCI host controllers, their properties pci.device_class and pci.device_subclass tell us if we have a real SCSI host controller: pci.device_class == 1 means a storage controller, pci.device_subclass == 0 means a SCSI controller. This works too for PCCard controllers, which use the PCI device class numbers too. - The value "usb_device" of the HAL property info.bus identifies USB devices, with one exception: The USB host controller, which itself has an info.bus property with the value "pci", has a sub-device with info.bus='usb_device' for its "output aspect". These sub-devices can be identified by the device class their parent and by their USB vendor/product IDs, which are 0:0. Several info.bus/info.subsystem values always relate to HAL nodes which describe only "aspects" of physical devcies which are represented by other HAL nodes: - bus is None for a number of "virtual components", like /org/freedesktop/Hal/devices/computer_alsa_timer or /org/freedesktop/Hal/devices/computer_oss_sequencer, so we ignore them. (The real sound devices appear with other UDIs in HAL.) XXX Abel Deuring 20080425: This ignores a few components like laptop batteries or the CPU, where info.bus is None. Since these components are not the most important ones for the HWDB, we'll ignore them for now. Bug 237038. - 'disk' is used udev submissions for a node related to the sd or sr driver of (real or fake) SCSI block devices. - info.bus == 'drm' is used by the HAL for the direct rendering interface of a graphics card. - info.bus == 'dvb' is used by HAL for the "input aspect" of DVB receivers - info.bus == 'memstick_host' is used by HAL for the "output aspect" of memory sticks. - info.bus == 'net' is used by the HAL version in Intrepid for the "output aspects" of network devices. - 'partition' is used in udev submissions for a node related to disk partition - 'scsi_disk' is used in udev submissions for a sub-node of the real device node. info.bus == 'scsi_generic' is used by the HAL version in Intrepid for a HAL node representing the generic interface of a SCSI device. info.bus == 'scsi_host' is used by the HAL version in Intrepid for real and "fake" SCSI host controllers. (On Hardy, these nodes have no info.bus property.) HAL nodes with this bus value are sub-nodes for the "SCSI aspect" of another HAL node which represents the real device. 'scsi_target' is used in udev data for SCSI target nodes, the parent of a SCSI device (or LUN) node. 'spi_transport' (SCSI Parallel Transport) is used in udev data for a sub-node of real SCSI devices. info.bus == 'sound' is used by the HAL version in Intrepid for "aspects" of sound devices. info.bus == 'ssb' is used for "aspects" of Broadcom Ethernet and WLAN devices, but like 'usb', they do not represent separate devices. info.bus == 'tty' is used for the "output aspect" of serial output devices (RS232, modems etc). It appears for USB and PCI devices as well as for legacy devices like the 8250/16450/16550 controllers. info.bus == 'usb' is used for end points of USB devices; the root node of a USB device has info.bus == 'usb_device'. 'usb_interface' is used in udv submissions for interface nodes of USB devices. info.bus == 'video4linux' is used for the "input aspect" of video devices. 'ac97' is used in submissions with udev data for a sub-node of sound devices. 'hid' is used in submissions with udev data for a sub-node of USB input devices. 'drm_minor', 'pci_express', 'tifm_adapter', 'gameport', 'spi_host', 'tifm', 'wlan' are used in submissions with udev data for sub-nodes of PCI devices. 'pcmcia_socket' is used in submissions with udev data for a sub-node of PC Card and PCMCIA bridges. 'ieee80211' is used in submissions with udev data for sub-nodes IEEE 802.11 WLAN devices. 'host', 'link' are used in submissions with udev data for sub.nodes of bluetooth devices. 'usb_host' and 'usbmon' are used in submissions with udev data for sub-nodes of USB controllers. 'usb_endpoint', 'usb-serial', 'lirc' are used in submissions with udev data for sub-nodes of USB devices. 'enclosure' is used in submissions with udev data for a sub.node of SCSI devices. 'graphics' is used in submissions with udev data for a sub-node of graphics cards. 'hwmon' is is used in submissions with udev data in many sub-nodes. 'sas_phy', 'sas_device', 'sas_end_device', 'sas_port', 'sas_host' is used in submissions with udev data for details of SAS controllers. 'mISDN' is used in submissions with udev data for the I/O aspects of ISDN adapters. 'pvrusb2' is used in submissions with udev data for the input aspect of some DVB adapters. 'memstick' is used in submissions with udev data for the I/O aspect of memory stick controllers. 'bttv-sub' is used in submissions with udev data for the I/O aspects of some TV receivers. 'scsi_tape' is used in submissions with udev data for details of SCSI tape drives.
The list of real child devices consists of the direct child devices of this device where child.is_real_device == True, and of the (recursively collected) list of real sub-devices of those child devices where child.is_real_device == False.
Devices are identifed by (bus, vendor_id, product_id). At present we cannot generate reliable vendor and/or product IDs for devices with the following values of the HAL property info.bus resp. info.subsystem.
info.bus == 'backlight' is used by the HAL version in Intrepid for the LC display. Useful vendor and product names are not available.
info.bus == 'bluetooth': HAL does not provide any vendor/product ID data, so we can't store these devices in HWDevice.
info.bus == 'input' is used by the HAL version in Intrepid for quite different devices like keyboards, mice, special laptop switches and buttons, sometimes with odd product names like "Video Bus".
info.bus == 'misc' and info.bus == 'unknown' are obviously not very useful, except for the computer itself, which has the bus 'unknown'.
info.bus in ('mmc', 'mmc_host') is used for SD/MMC cards resp. the "output aspect" of card readers. We do not not have at present enough background information to properly extract a vendor and product ID from these cards.
info.bus == 'platform' is used for devices like the i8042 which controls keyboard and mouse; HAL has no vendor information for these devices, so there is no point to treat them as real devices.
info.bus == 'pnp' is used for components like the ancient AT DMA controller or the keyboard. Like for the bus 'platform', HAL does not provide any vendor data.
info.bus == 'power_supply' is used by the HAL version in Intrepid for AC adapters an laptop batteries. We don't have at present enough information about possible problems with missing vendor/product information in order to store the data reliably in the HWDB.
raw_bus == 'acpi' is used in udev data for the main system, for CPUs, power supply etc. Except for the main sytsem, none of them provides a vendor or product id, so we ignore them.
raw_bus == 'video_output', 'thermal', 'vtconsole', 'bdi', 'mem', 'ppp', 'vc', 'dmi', 'hidraw', 'hwmon', 'heci', 'rfkill', 'i2c-adapter', 'ttm', 'ppdev', 'printer', 'cardman_4040', 'msr', 'ieee1394_protocol', 'dahdi', 'atm', 'asus_oled', 'pktcdvd' is used in submissions with udev data for virtual devices.
'pci_bus' is used in submissions with udev data for a node describing a PCI bus.
'leds' is used in submissions with udev data to describe LEDs.
XXX Abel Deuring 2008-05-06: IEEE1394 devices are a bit nasty: The standard does not define any specification for product IDs or product names, hence HAL often uses the value 0 for the property ieee1394.product_id and a value like "Unknown (0x00d04b)" for ieee.product, where 0x00d04b is the vendor ID. I have currently no idea how to find or generate something that could be used as the product ID, so IEEE1394 devices are at present simply not stored in the HWDB. Otherwise, we'd pollute the HWDB with unreliable data. Bug #237044.
While PCMCIA devices have a manufacturer ID, at least its value as provided by HAL in pcmcia.manf_id it is not very reliable. The HAL property pcmcia.prod_id1 is too not reliable. Sometimes it contains a useful vendor name like "O2Micro" or "ATMEL", but sometimes useless values like "IEEE 802.11b". See for example drivers/net/wireless/atmel_cs.c in the Linux kernel sources.
Provided that a device is not excluded by the above criteria, ensure that we have vendor ID, product ID and product name.
SCSI devcies are identified by an 8 charcter vendor name and an 16 character model name. The Linux kernel use the the SCSI command set to access block devices connected via USB, IEEE1394 and ATA buses too.
For ATA disks, the Linux kernel sets the vendor name to "ATA" and prepends the model name with the real vendor name, but only if the combined length if not larger than 16. Otherwise the real vendor name is omitted.
This method provides a safe way to retrieve the the SCSI vendor and model name.
If the vendor name is 'ATA', and if the model name contains at least one ' ' character, the string before the first ' ' is returned as the vendor name, and the string after the first ' ' is returned as the model name.
In all other cases, vendor and model name are returned unmodified.
Create a HWDriver record, if it does not already exist.
A vendor ID is associated with a vendor name. For many devices we rely on the information from the submission to create this association in the HWVendorID table.
We do _not_ use the submitted vendor name for USB, PCI and PCCard devices, because we can get them from independent sources. See l/c/l/doc/hwdb-device-tables.txt.
A HWDevice record for (bus, vendor ID, product ID) of this device and a HWDeviceDriverLink record (device, None) are created, if they do not already exist.
A HWSubmissionDevice record is created for (HWDeviceDriverLink, submission).
HWSubmissionDevice records and missing HWDeviceDriverLink records for known drivers of this device are created.
createDBData is called recursively for all real child devices.
This method may only be called, if self.real_device == True.