Artem Kachitchkine <[EMAIL PROTECTED]> wrote:
>
> > And hopefully, it will work better than HAL and DBUS on Linux where the
> > system is responsible for cdrecord problems.
> >
> > See e.g. this thread:
> >
> > http://groups.google.de/group/linux.kernel/browse_thread/thread/4b411559689e26a3/ab3bb2a38a5ed122?lnk=st&q=cdrecord&rnum=40&hl=de#ab3bb2a38a5ed122
If the discussion mentiones all important issues, then the problem, that
caused the problem from the Linux thread, is that Linux does not implement
an orthogonal device handling and that you need-to/may open (possibly different)
high level interfaces that all do ithings at open time that are inadequate
for generic SCSI. Ibn order to tease cdrecord, Linux even hides important
imformation from user space that could allow mapping.
> Yes, the easiest would be for cdrecord to lock the device through HAL
> (by calling the Device.Lock() method) for the duration of the burning
> process. All other solutions seem too complicated and/or error-prone.
cdrecord is not based on high level device interfaces but on libscg that
runs in native mode when using /dev/scg and in emulatiom mode when using USCSI.
Most OS do not even allow you to use high level interfaces for
libscg/cdrecord's tasks (e.g. MS-WIN, FreeBSD, ...).
I suspect that HAL on the other side deals with high level device interfaces
and will not be able to map from/to low level SCSI generic.
If you like to have a fool-proof implementation with no limitations, we would
need to implement the 'integraded' /dev/scg that I did propose 2 years ago
while talking to FritS and that I recently mentioned in this list.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
[email protected]
