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

Re: Linux problems



Hi,

> Did you try to understand why there are problems on Linux but not on
> Solaris?

I tried to understand why there are problems on Linux.
I did only watch one older instance of hald and i did
no research in Solaris. But i considered conflicts other
than those with hald.


> if you believe me where the problems are located and
> why a simple change at useer level does not help.

I believe you that at the Linux user level there is
no solution yet.
I also believe that a hald which is acting carefully
can ease the problem much.

But the decisive point for general cooperation is the
existence of a reliable locking mechanism for devices.
With one single nexus for each vulnerable burner device.
Not per device file path, not per inode, not per
major-minor device driver number, but per "Logical Unit"
as in SAM-3 resp. "multi-media (MM) device" as in MMC-5.
(I hope both mean the same thing.)

The problems with hald are a special case of the
overall problems with burner/reader devices.
Besides hald we got conflicts of interest with
libblkid and mutually between our burn programs.
Probably there are more such problem scenarios.

A common pattern is that concurrent instances are
sending SCSI commands to the burner while it is
in the vulnerable state of sequential writing.


Best for us would be if a shared lock would be
aquired automatically and mandatorily with any
call of open(). For vulnerable activities an
interested process should upgrade it to an exclusive
lock first (and downgrade to shared afterwards).
The shared lock ends only by close().

Bestest would be if an argument came to me which
has chances to convince the kernel emminencies.


Have a nice day :)

Thomas



Reply to: