Persistent drive addresses and a method to leave all drives but one untouched

[scdbackup@…]

Problem:

The official method to address a drive with libburn is to call burn_drive_scan() with the consequence that function open() is applied to any device file that could lead to a burner. open() stalls with devices which are ill or busy even if they are no burners or not intended for use with libburn.

This mandatory systemwide bus scan with any use of libburn makes its usability clearly inferior to the one of cdrecord.

The need for the bus scan is builtin to the current concept of libburn because it does not provide means to depict a drive by a persistent address string. A simple change of device file access permissions is enough to change the burn_drive_scan() result numbering.

Possible solution:

- Define persistent address strings for drives which are only

supposed to change when the sysadmin knowingly manipulates the mapping of device addresses to physical devices.

- Provide API means to address a single drive without the risk

to open any other device file.

Proposal:

For the purpose of cdrskin i implemented a whitelist which has a very small footprint within existing libburn code:

- Persistent address is the device file address as found in

struct burn_drive_info.location .

- The desired drive address is put into a whitelist.

The (currently two) drive enumeration functions of libburn query the whitelist before applying open() to a device. If the whitelist is not empty and if the candidate device is not listed, then open() is skipped and the device gets handled as if it did not offer read-permission. If the whitelist is empty, then all enumerated drives get opened. Thus traditional operation of libburn is not affected as long as the whitelist API functions are not used by the application.

---

Sorry for the bad readability.

This is because the ticket software does properly respect neither newlines nor blanks nor tabs. (Shiny surface, though)

I wanted to attach the patch. But although it is readable in the edit window the Description Preview is quite misformatted. Where and how do i submit a patch generated by diff -puN ?

How to make plain text formatting show up in the Preview as it was typed into the editor window ?

[scdbackup@…]

Tested patch against libburn CVS version of february 2006

[blade@…]

Just let me say few words as user and packager:

Persistent names are good. They do not need to follow a bastardized scheme unique for 30 supported plattforms like some other infamous application, but something related to the native filesystem or the real device names would be great. Depending on this device specifications, libburn should take the most benefit from this spec while touching as few drives as possible.

For example, I have two devices, one from Lite-on and one from BENQ. Currently, cdrskin prints out the model names (apparently from procfs). I would like to be able to specify a certain drive saying: "--dev benq" and then libburn would pickup the device with the name matching the pattern /benq/. Or bail on on disambiguation.

OTOH when I as user say "--dev /dev/hdc" then only this device and nothing else should be touched. There is simply no reason to do that, user specified _enough_ information to construct a useable target out of it. Opening non-involved devices is a bad idea anyway (does libburn open them? If not, ignore this complaint). Imagine there is a burn process in progress, would it survive? (I know about O_EXCL but IIRC this is Linux-specific).

So, summary, IMO libburn should respect a such "whitelist" parameter, use it to go trough the list of "system-native device-names" (/dev/hd* and /dev/scd*, iscsi names, ...) and on match accept that name (or bail out because of disambiguation), then go trough the list of brands/model names and try to match there and map to the system-native device file.

[scdbackup@…]

Clarifying notes to strip off cdrskin specifics:

---

The --devices info printed by cdrskin stems from burn_drive_scan() which had put it into an array of struct burn_drive_info;

0 dev='/dev/sg0' rwrwrw : 'HL-DT-ST' 'DVDRAM GSA-4082B'

derived from:

array_index , .location , stat(.location) , .vendor , .product

---

Yes. libburn opens everything that looks like /dev/sg[0..31] or /dev/hd[a-z]. To be clear: nothing else. No HAL, no other device file names.

See libburn/sg.c : functions sg_enumerate() and ata_enumerate(). This is also where my patch intersects with existing libburn:

if (burn_drive_is_banned(fname)) continue;

Next line says: fd = open(...

---

Accessing struct burn_drive_info.vendor within libburn/sg.c in order to compare it with the whitelist items is not so easy, i fear.

Mainly because the whitelist query takes place within just the call of burn_drive_scan() which builds up the array of struct burn_drive_info . Although it does not have to be impossible, it might demand some unhealthy tangling within libburn.

Decisive for the mere possibility of implementation will be the availability of .vendor before opening the device files. I understand that .vendor comes from enumerate_common() and this is called *after* open() .

"Wer wagt es, Rittersmann oder Knapp' - zu tauchen in diesen Schlund ?"

("Who dares, knight or knave - to dive into this maw ?")

http://www.fln.vcu.edu/schiller/taucher_e.html

[pygi]

AFAICS, if the scan function uses O_RDONLY|O_NONBLOCK, it will only stumble over O_EXCL-opened devices (i. e. a currently progressing burning) And if the actual burning uses O_RDWR|O_EXCL|O_NONBLOCK, that should work fine everywhere and be on the safe side. (Just commenting :))

[scdbackup@…]

I checked out and (after some fight with my own tools) managed to diff it towards my own "CVS-0.2" version.

Looks good so far. I still have to bootstrap and so on in order to get a cdrskin binary based on this - but i'm optimistic.

We are not completely done for now because there remains a small diff which is a bit of a riddle to me:

libburn/libburn/libburn.h , line 26

+#if (_FILE_OFFSET_BITS != 64)

+#error "Incompatible file offset size. _FILE_OFFSET_BITS must be 64."

+#endif

(complete diff file will get attached next)

This code is in my version but it is not by me. Looks like icculus.org removed it between Feb 2006 and July 2006.

I can live without it because cdrskin takes care to use 64 bit file addressing. So it is up to the libburn team to decide wether this shall get into libburn (and possibly cause error reports).

Nevertheless i re-opened the ticket for this last bit to be resolved. (Give one short statement about the fate of above diff and it is solved.)

As for O_EXCL, O_NONBLOCK et al:

O_EXCL | O_NONBLOCK is to be the preferrable standard method of opening. Nevertheless the whitelist has slightly but significantly different consequences on the same topic:

What does not get touched cannot get spoiled on the first hand. cdrecord in normal daily operation (i.e. not -scanbus or so) does touch only the desired drive. This keeps any concurrency problem contained to that single drive. Not knowing about O_EXCL i once decided to make this an essential feature to emulate. O_EXCL experiments and findings clearly justify that blind decision.

With O_EXCL semantics (which *i* cannot disable on *my* SuSE 9.0 !) we have a time window of various length where libburn occupies all CD drives which it is allowed to open. (I.e. eventually not a drive that is already busy.) That's what i call a "O_EXCL rogue".

Wether i can cut this window to a reasonably short timespan has still to be evaluated. Up to now, the whitelist saves cdrskin users from that by reducing the drive scope of the window to a single drive in all use cases where cdrskin runs for more than a few seconds.

We will not get around a certain small system disturbance during bus scans which are necessary for the user. But we will avoid the *chance* for systemwide disturbance in most use cases.

So in an hypothetical libburn tutorial text, i would strongly encourage any application to use the whitelist if it knows the desired drive address in advance (i.e. before bus scan). This advance knowledge with cdrecord is traditionally gained by running -scanbus and by memorizing the drive address of interest.

My tool scdbackup shows a scanbus result at configuration time. It then demands to know the drive address and will furtherly use it without doing a -scanbus in backup operations.

K3B on the other hand uses *own means* to compute a Joerg-style SCSI address (like "0,1,0") and uses this on cdrecord. Little cdrskin has to be programmed to translate such a fantasy address into a /dev/sgN or /dev/hdX at the time when you foist it to K3B. (I would stronly encourage cdrecord|cdrskin applications to use -scanbus on both programs and to work with the addresses which get reported.)

K3B stunt:

http://scdbackup.sourceforge.net/k3b_on_cdrskin.html

Configurable cdrskin address translation described in:

http://scdbackup.sourceforge.net/README_cdrskin_devel

[scdbackup@…]

Last remaining diff (but without upcoming O_EXCL diffs)

[scdbackup@…]

Haha.

The two variables removed from cdrskin on reports of -Wall are now missing for the CVS version. So far for my Oops-Hurry reflex.

It is about time that cdrskin consolidates itself to one single libburn.

[anonymous]

It works ! The following is no submission of code but an illustration of the remaining gap between libburn SVN-0.2 and cdrskin :

I start with libburn as checked out from today's svn.

cp -a libburn libburn-0.2.A60815

cd libburn-0.2.A60815

./bootstrap

./configure

make

cp /home/thomas/projekte/cdrskin_dir/libburn-0.2.ts.develop/README .

cp -r /home/thomas/projekte/cdrskin_dir/libburn-0.2.ts.develop/cdrskin cdrskin

./cdrskin/compile_cdrskin.sh -cvs_A60220

cdrskin/cdrskin is then ready for use

And i need breakfast.

[scdbackup]

This is done. We got an API function which takes persistent addresses to access a drive, we got the whitelist which gets fed with such addresses, and we got a function to inquire the persistent address from a drive.

Up to HAL support or so, this should suffice. And for then we are quite prepared by now.

[pygi]

Milestone 0.2.1 deleted

[pygi]

Milestone 0.2.2 deleted

[carlisle1981]

These beautiful jewelries can catch the eyes of women all the time since they always believe that the jewelries in the shop window are much better than those in their links of london box. Accordingly, the jewels with simple and traditional design as well as practical use are their best choice. What's more, it is suitable for them to wear emerald, moonstone, and white jade. By the reason of the dressed, if matched with a piece of proper jewel, will look much more attractive and tasteful. But it is a big question for many women to choose jewelries properly. Some professional tips are in the following in the hope that they have been of some help When choosing jewelries, you should pay great attention to the complexion, dressing, temperament, age, occasion, profession, etc. in order to stand out them better. The prime directive is make your jewels be neither too like your face shape nor too different from your face shape. As for square shape face, oval or oblong shaped charm bracelet work best. They soften the jaw line, giving it more definition and shape. Hooped earrings are also an excellent choice. The traditional bun matched with drop earrings will give others an impression of elegance. The extremely fashionable jewels should be avoided. In order to avoid conflict, the dresses with decorative border should match with simple style gold charm bracelets . When you are in an informal place, you can wear designed jewelry that have some color to fit your clothes, which will have a special kind of taste from your general wearing. However, red and other dark color could not be more suitable for people with fair skins. While tall and plump women decorated with silver links of london bracelet in large size will look better compare with the small ones. Simple and elegant jewels are always a good choice for fair ladies since they play an important role in display ladies' purity and beauty.