> > This is a conceptual patch relative to cdrtools-1.10 which makes it > > possible to use cdrecord together with Solaris 8 Volume Manager. > > ... at this point you have to issue > > 'eject cdrom' after you burned it and push the tray back in order to > > get it mounted. > > Couldn't you use cdrecord's --eject option instead of eject cdrom? > Getting it back in could probably also be done with software.
It's not about mechanical movement of the tray, but about tricking /usr/sbin/vold to reread and remount the media. In more details. First note that once vold is running you can't open /dev/rdsk/cXtYdZs2 (Oh! I failed to mention that "volumized" cdrecord does not expect /dev/scg* to be present). So patched cdrecord finds its way to /vol/dev/rdsk/cXtYdZ/unknown_format instead. This in turn means that everything cdrecord throws at it passes Volume Management kernel driver (hereafter "the V-driver") which is free to do certain magic. Now 'cdrecord -eject/load' uses USCSI ioctls to open/clode tray which are passed through verbatim. 'eject cdrom' in turn uses DKIOCEJECT ioctl which also makes the V-driver throw an exception at vold which triggers it to do certain magic in the user-land. You may ask why not make cdrecord issue DKIOCEJECT to eject and then USCSI to load? Well, the problem is that once DKIOCEJECT passes the V-driver it (so to say) interrupts all communications and awaits for further instructions from vold, meaning that the "load" USCSI never gets through and you find yourself in "catch-22" situation... Cheers. Andy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
