[Libburn] How to proceed with my further changes ?

[scdbackup at gmx.net]

Hi,

i continued the development of cdrskin and made further 
changes to libburn in order to avoid the stalling of
burn_drive_scan() at program startup.

libburn expects the application to run  burn_drive_scan() 
in order to get ready for work. The procedure started by this
function enumerates all possible drive addresses and tries
to obtain information about the drive.
While the enumeration is harmless (up to now), the inquiry of
drive data can cause burn_drive_scan() to never come back
if there is a CD drive with r-permission but without w-permission
or having any other problem (i got a DMA-allergic DVD-ROM).
Of course, one shall not write CD via a drive with such properties,
but one cannot write CD via any other drive then.

I made three changes within sg.c and drive.c in order to protect
my users and their sysadmins from the woes of this approach.

Two of them are quite intrusive and clearly need approval and/or
modification by the libburn maintainers.
(A w-permission test in sg.c during enumeration and a timeout in
 burn_drive_scan_sync() to catch any other stall situation.)


The third change is a new feature which should not to cause any
negative effect on the existing scan procedure if it is not enabled
by the application: A whitelist of wanted drive addresses.
If this whitelist is not empty then a drive may only be enumerated
if its address is in the list. 

The number of possible list items is given by the new macro
  BURN_DRIVE_WHITELIST_LEN

The list may be created and expanded by a new call  
  int burn_drive_add_whitelist(char *device_address);

cleared by a new call
  void burn_drive_clear_whitelist(void);

and queried by a new call
  int burn_drive_is_banned(char *device_address)

This has been implemented in drive.c and libburn.h.
The existing sg.c functions  sg_enumerate()  and  ata_enumerate()
get enhanced by a call of  burn_drive_is_banned()  each.


Application usage:

If cdrskin encounters a particular device address among its arguments
then this gets added as first and only item to the whitelist.
Thus the enumeration will at most detect this single drive and
the scan cannot run into problems with any other drives.
It looks just like if all others don't offer r-permission.

If the drive is not given by a device address but by a libburn
drive number, or if the cdrskin options for bus scanning are
present, then the whitelist is left empty and all possible drives
may appear and perform their freak show. 

Other applications may have whitelists of more than one drive
from which a menu allows to choose.


All three changes are tested with the 0.2 tarball and with
the CVS version as of Dec 8, 2005.

What is the outlook for maintainer attention to my patches ?
(I'm slowly getting into newbie problems with how to handle
patches which affect patched files that have not been processed
by the maintainers yet. Shall i assume my older patches to
be accepted ? Shall i wait ? Shall i make a condensed patch 
of all pending change proposals ?)
The ongoing work can be watched at
  http://scdbackup.sourceforge.net/cdrskin_eng.html
(Pre-publish state, revisions are not counting up yet.)


Have a nice day :)

Thomas