Hi Zhongyuan.
Thanks for reviewing the interface spec. Moving to public forum.
> I've some comments on DDU library API--ddu_devscan() function.
> You've expanded this function to involve all devices found, it's
> good! While for the Return value, currently it only includes
> "compatible name" and "device descriptor" strings, It's not
> sufficient especially for GUI part:
>
> *For non-mission items
> (1)If the driver works fine,we need a "driver name" field.
>
OK
> (2)If the driver dos not works fine, wee need the driver instance
> ID and attachment status for this driver.
>
> Instance ID is a number get from system when driver attached. If
> you have 2 e1000g nic cards and they all have been attached
> properly, then they will get instance 0 and 1, while if the driver
> have not been attached properly or device have been installed
> properly, the instance ID will be <0 and attachment status will be
> "detached".
>
> DDU GUI version used "instance ID" and attachment status to give
> user a notification "driver missconfigured".
OK
>
> BTW, for both non-missing and missing device, I hope we can add
> "device category" argument to ddu_devscan function to indicate what
> type of category will be looked for(like "Audio"/"Network" etc). By
> default this argument can be set to "All" to look for all types of >
device.
OK.
> For both missing and non-missing items, we also need these fields
> at least:
> (1)"Vendor id"/"device id"/"classcode" to identify which category
> this device belongs to.
OK.
> (2)pci path to indicate this device's detail information.
> Hopefully this can be involved into ddu_devscan function.
OK.
These are a lot of changes for ddu_devscan() for the GUI. I propose
that ddu_devscan returns a list of dictionaries rather than a list of
tuples (as before). Dictionaries because there are a lot of items
returned. Also, not all fields will be used for all devices. (For
example, the driver_name field won't be used when a device is missing).
So this would translate into adding a signature of ddu_devscan() as follows:
Arguments:
- return_missing_only: Boolean; default value is True
- When True, ddu_devscan returns only the devices which are missing
drivers.
- When False, all devices found are returned.
- device_type: Type of devices to scan for. "All" to check all.
===> Please send the list of device types which are valid. "Audio" and
"Network" were mentioned earlier.
Returns:
A list of dictionaries, each dictionary representing a device. List can
be empty (possible only when Return_missing_only is True) to represent a
system with no missing drivers.
Items in each dictionary are:
- compatible: device compatible name string, a space-separated string of
all compatible names for a device. Compatible names in the string are
ordered from the most specific name to the most general name (i.e. the
"pciclass" definitions are listed last).
- It is OK if two list items have one or more compatible
names in common, but each list item should be unique.
- description: Device description. can be used for error messages and
status reporting.
- device_type: Type of device (e.g. "Audio", "Network")
- driver_name: Name of the driver operating the device. (Can be omitted
if driver is missing.)
- instance_ID: Instance ID assigned to the device. (Always present.
Will be <0 if no driver is attached to the device.)
- attach_status: Status of whether or not a driver is attached to the
device. (Always present. Will be "detached" if driver is not attached,
"attached" if driver is attached.
===> Any other statuses possible?
- vendor_id: Device's vendor ID. (Always present.)
- device_id: Device's device ID (Always present.)
- class_code: Device's class code (Always present.)
- pci_path: Device path (Always present.)
Please let me know by today COB (PRC time) the device types and if any
corrections are needed.
Thanks,
Jack
On 12/04/09 09:20, Jack Schwartz wrote:
> Hi everyone.
>
> FYI: Driver Update functional and programming interface specs have had
> a minor update. The items addressed deal either with subtleties
> missed during the main review but which came up during development, or
> other things we discovered were needed during development.
>
> Functional spec:
> - Clarify that any repo can be specified, not only repos which a
> system already
> knows about.
> - Clarify that it is an error if a publisher name is already mapped to
> a repo,
> and another repo with the same publisher name is requested.
> - Add publisher to AI searchall capability
>
> Interface spec:
> - Add arg to ddu_devscan() so that the function can return either all
> devices
> on a system, or only devices which are missing their driver.
>
> Links on the Driver Update page have been updated. Previous spec
> versions have been retained on that page for comparison purposes.
>
> Driver update page is at:
> http://hub.opensolaris.org/bin/view/Project+caiman/Driver_Update
>
> If there are any questions or comments please send them my way.
>
> Thanks,
> Jack
>
>
