It is not feasible to recreate the UDI strings
originally
generated by HAL, as HAL's internal structure is quite different than the
TDE HW backend. HAL uses many internal hacks/strings, which
contributed significantly to its unmaintainability and subsequent
deprecation; I do not want to repeat that mistake.
Sure, I understand. Let me explain differently. I am not suggesting we recreate the UDI
strings from the old mediamanagerrc, which are based upon how HAL works. I'm
suggesting we grep those strings to create the new TDEHW strings by extracting the UUID
related information.
TDE probably can already extract the UUID when I device is connected. TDEHW should use
that code. We then grep the old mediamanagerrc for that UUID and extract the related
information. For example, suppose I insert my Kingston 8GB flash drive. For that one
device my existing mediamnagerrc looks like this:
...
[/org/freedesktop/Hal/devices/volume_uuid_4CAB_C505]
atime=false
flush=true
mountpoint=/media/kingston_8gb
quiet=false
ro=false
shortname=lower
sync=false
uid=true
utf8=true
...
[UserLabels]
/org/freedesktop/Hal/devices/volume_uuid_4CAB_C505=Kingston 8GB USB
...
When I insert that device, TDE/TDEHW discovers the UUID, and then TDEHW greps
mediamanagerrc for that UUID. Then TDEHW, either through kreadconfig or its own code,
extracts the information. Rather than a [UserLabels] string that looks like this:
[UserLabels]
/sys/devices/pci0000:00/0000:00:0b.1/usb1/1-2/1-2:1.0/host7/target7:0:0/7:0:0:0/block/sdf/sdf1//dev/sdf1=Cruzer
16GB USB
Which changes when I insert the device into a different physical port, we create a strings
like this:
...
[volume_uuid_4CAB_C505]
atime=false
flush=true
mountpoint=/media/kingston_8gb
quiet=false
ro=false
shortname=lower
sync=false
uid=true
utf8=true
...
[UserLabels]
volume_uuid_4CAB_C505=Kingston 8GB USB
...
If whoever developed the code for mediamanagerrc under HAL had used this direct string
approach, we would not need to create new strings under TDEHW. :-) My point is that the
UUID is discoverable and dependable and can be used to create the new mediamanagerrc
strings.
Perhaps the first time TDE is started under TDEHW, TDEHW automatically updates
mediamanagerrc rather than wait for those devices to be inserted.
The loss of old media manager settings will exist with
any
replacement media backend unless great pains are taken to generate UDI
strings exactly the way HAL did; this issue is not unique to the TDEHWLib
backend.
Yes, I understand that mediamanagerrc will be a tad cluttered until we get this all
debugged. :-)
Darrell