Re: Request for cooperation with all burn backends
Hi,
> > which does not depend on hardly documented Linux O_EXCL ?
> > Something simple and very portable would be needed.
>
> - Linux has a silly problem caused by device aliasing:
Yeah. But *that* i could circumvent.
The drivers know the SCSI quatruple (Host,Channel,Id,Lun)
and by that i can determine the matching sr for my sg.
Now with that info in hand i would only need a central
instance which tells me wether some other burn process
works on a thing with the same info.
That's what O_EXCL fails to do on sr with my oldish kernel.
I want a new more reliable central instance for that
in user space. A convention of burn backends so they
don't spoil each others burn.
Of course that thing will not save us from automounters
as long as they do not join our convention. But how
should they - as long as there is no convention ?
> - Record Locking only works on files.
I would anyway prefer to have no system locking mechanism
involved but only vanilla file operations.
link(2) and rename(2) can make a file appear quite atomicly.
The only race condition would be the asynchronizity between
lookup of not-yet-existent lock file and creation of the own
lock file.
For that i got a solution from the mid 1980s.
A lock is obtained this way:
- lookup the lock file (have lost locking contest if it exists)
- create lock file with on id stamp as content
- wait three seconds
- lookup lock file and check wether own id is still there
(if not there any more: have lost locking contest)
The 3 seconds were sufficient for NFS on a 10 Mbit LAN
with 50 workstations of 25 MHz each. We could wait less
than a second for that.
Lock files have names of form:
/tmp/burner_backend_lock_${info_code}
Each burner device leads to a unique $info_code.
> If Linux would make [...]
Linux won't make. We need to make.
Linux is there and will be there.
The alternative is not Solaris but Vista, i fear.
HAL could probably do. Its server would be ideal.
But we should strive for something much more simple.
My porposal is:
- Above file synchronization protocol which will be
very portable.
- A info_code convention which for now covers:
- SCSI on Linux (and probably on most other systems)
${Host}_${Channel}_${Id}_${Lun}
All four numbers as plain decimals with no leading 0s.
- ATAPI on Linux (and on other systems ?)
${stat.st_rdev}
As hexadecimal number but without trailing "0x".
To my knowledge there is only one (Major,Minor) device
number pair per ATAPI burner in Linux.
- transports of your choice on systems of your choice
(currently i only have to deal with above two)
Thus if cdrecord wants to access burner "0,1,0" it looks up
${Host}_${Channel}_${Id}_${Lun} (how is channel+id related
to cdrecord target, btw ?) and attempts to lock via
/tmp/burner_backend_lock_0_0_1_0
growisofs using /dev/scd1 would obtain the same quatruple
by SCSI_IOCTL_GET_IDLUN and compute the same file address.
The same for cdrskin using /dev/sg1 .
With ATAPI, growisofs and cdrskin use both "/dev/hdc"
and would come by a simple stat(2) to a file address like
/tmp/burner_backend_lock_300
cdrecord would have to find a way to come from "ATA:1,0,0"
to "/dev/hdc" resp. the device number.
If you know a characteristic info of a ATAPI burner that
is easier to obtain for cdrecord: make a proposal.
> What you mentioned here is highly Linux specific and does nto help
> to find a OS independent way.
The info conventions for the file names can become OS specific,
i confess. Let's see how many OSes have no Host,Channel,Id,Lun
for SCSI and no unique device number for ATAPI burners.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to cdwrite-REQUEST@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@other.debian.org
Reply to: