[Libburn] Re: Cancelling an ongoing burn. Is this dangerous ?

[scdbackup at gmx.net]

Hi,

> > But i thought   burn_drive_info.location  was a part of the API.
> > After all i understand burn_drive_info as a kind of publisher
> > for some selected drive details.
> 
> The location is there for informative purposes, but not for selecting
> the drive. Or that was the original motivation.

I deduced from the current content that those are the
addresses of interest for the sysadmin and that therefore
i could assume a 1:1 association between drive and location
text. This assumed 1:1 mapping would allow me to identify
a drive via its location text. 

So if the intention of burn_drive_info.location is to
provide some unique drive identifier then it is an
API-conformant use to take it as pseudo-drive address,
i'd say.
If the intention is something else, then my design is
wrong, of course.


> > It is not necessary to use "/dev/..." but i need to have a kind of
> > persistent drive address.
> 
> I guess I need to find out if HAL can provide this for you, and if it
> is still/yet worth linking libburn to and using.
> http://freedesktop.org/wiki/Software_2fhal

The only documentation link seems to be
  http://www.ometer.com/hardware.html
I read sentences which do not look encouraging for my cause:

"It would be device-dependent which properties existed."

"Some useful properties to provide, again not all would be
 available for all devices:

    * Device description.
    * Name of the bus the device is on.
    * Major/minor numbers.
    * /dev file(s) if any.
    * Unique device instance serial number.
    * Type of device.
"
Yeah what a compilation of things. This looks like
Linus Torvalds and Joerg Schilling drinking sibirian
mushroom beer together.
Is this really ripe for consideration ?

To make this useable one should probably add a member
  .drive_id  to burn_drive_info and take care that this
always contains a unique identifier obtained from the hardware
access layer in some reproducible way. (However you plan to
cope with a API that flatly does not promise anything.)
For now one could just use the /dev/ address as in .location.
(Nevertheless, this imposes the question what .location
is officially good for.)

Elsewise my wish to directly address a drive would be
equivalent to the wish to define a query in the HAL database
which exactly yields one item as result.
If the libburn API offers such a query, i would use that.


Hehe ...  just read paragraph 4 of that article:
"Blacklists and Whitelists".
I am not the first one who sees the need for such. :))


Have a nice day :)

Thomas