[Libburn] List of open decisions about my change proposals

[scdbackup at gmx.net]

Hi,

i have reviewed our recent discussion about my patch proposals
and made a list of things to be decided.
The motivations are discussed enough, i believe.

Five to seven bits. That's what is needed for now.

- Type for source sizes (or byte counts in general) :

  --- choose one of: --------------------------------------------
  [ ] off_t    with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
  [ ] int64_t  with the demand to use a modern compiler
               (my current SuSE Linux gcc 3.3.1 would do)


- Relation of burn_source, burn_source_file and the 
  upcoming (fd,size)-Addon :

  --- choose one of: --------------------------------------------
  [ ] fd source constitutes a new source class
  [ ] fd source will be united with file source
      --- in this case choose one of: ---------------------------
      [ ] burn_file_source_new() and burn_fd_source_new()
          coexist without calling each other
      [ ] burn_file_source_new() opens fds and then calls
          burn_fd_source_new(int fd1, int fd2, type_to_come size1)
          where size1 == 0 causes size determination by fstat(fd1)

  --- choose one of: --------------------------------------------
  [ ] fixed_size applies to all burn_sources
  [ ] fixed size applies only to fd (eventually united with file)


- Meaning of burn_drive_info.location now and in future :

  --- choose one of: --------------------------------------------
  [ ] .location will stay unique under all circumstances eventually
      at the risk of losing the capability to direct the sysadmin
      to the system management object of the drive.
  [ ] .location will be a system management hint. A new member
      .drive_id takes over the task of uniquely and persistently
      identifying a drive.


- Method of obtaining the scan information of only a single
  drive without risking to touch any others :

  --- choose one of: --------------------------------------------
  [ ] somebody found a better proposal about how to tackle the
      sticky drive problem but kept the solution secret up to now. 
  [ ] a new call is offered as alternative to burn_drive_scan():
      int burn_drive_scan_single(struct burn_drive_info *drives[], 
                                 const char *id);
      --- in this case choose one of: ---------------------------
      [ ] The new call gets implemented on top of the whitelist
          which has to be queried in the existing and future drive
          enumeration functions. For details see:
        http://lists.freedesktop.org/archives/libburn/2006-February/000371.html
      [ ] The new call gets implemented independently of
          burn_drive_scan() by circumventing existing enumeration
          and addressing the drive directly. That would probably 
          mean to move the code from inside the loops of sg_enumerate() 
          and ata_enumerate() into separate functions sg_enum_single()
          ata_enum_single(). Those get called by sg_enumerate(),
          ata_enumerate() and burn_drive_scan_single().
          burn_drive_scan_single() has to learn how to distinguish 
          between /dev/hdc , /dev/sg1 and future drive id types.


------------------------------------------------------------

It seems that  burn_source_file.subfd  is not associated
with any size determination, currently. I could not spot
a function which would fstat that file descriptor.
Derek, could you point me to an explanation for this sub thing 
in general ? In what use cases does it apply ?


Have a nice day :)

Thomas