[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for cooperation with all burn backends



... But the trouble is that the other systems, other than Linux
that is, might and already do have own ways to serialize the access. It
might be impossible and/or simply inappropriate not to use these
mechanisms. Doesn't this kind of doom all "very portable" attempts as
simply unachievable?

"Very portable" almost alwas == "equally crippled on all platforms".
I'm so tired of 'very portable' software.

That's kind of what I wanted to say. I mean it's either "very portable" or "with explicit support for every system." But as it seems we're talking about one particular OS, Linux in this case, after all, we should abstain for using "very portable" term in context of this discussion. At least I will:-)

I like the idea of having a convention-- but I would argue against it
locking down devices against all access.

[Once again] given that we're talking about Linux, 2.6 O_EXCL serializes only O_EXCL opens. So the program that only wishes to query unit can do so, while program that wants to pull the data or modify page settings should rather adhere to O_EXCL to serialize the access.

A CDROM device is perfectly
capable of answering, eg, ' are you a cdrom?' whil e burning.

As far as I interpret Thomas' experience he has problems with growisofs performing recording on /dev/cdrom being disrupted by scan attempt on /dev/sg. This apparently turns to be far from simple "are you a cdrom?" question...

I
realize that deciding what access is 'safe' is underspecified right
now.

... because from personal experience I can tell that I've never had problems running dvd+rw-medianfo during ongoing growisofs recording. dvd+rw-medianfo does issue "are you a cdrom?" and a bunch of other queries. In other words unit *is* indeed capable to answer the limited amount of questions and the fact that Thomas reports problem indicates rather a kernel issue.

To summarize. My vote goes for block device addressing, back-porting of
O_EXCL to 2.4 and convincing auto-mounting/-playing developers to stick
to it.

I will not be obeying O_EXCL in cdparanoia, at least in its current
form.  However, I also want to make cdparanoia safe in the context of
cdrom devices [ripping] burning.

I don't quite understand why not adhere to O_EXCL when it actually comes to action. I mean you can perform initial open without O_EXCL so that you can pull TOC, offer options to user, etc, but just before you're about to modify page parameters and start pulling CDDA, you can as well claim O_EXCL... But once again, I don't see applications such as cdrskin or cdparanoia as biggest problem, because user still *controls* them, but [s]he does not control auto-mounting/-playing facilities. Cheers. A.



Reply to: