The notes I read in the cdrecord man pages and readmes indicate that
the WORM identity with which older CD-r drives identify themselves is
completely erronious.  Since the traditional WORM devices are a far cry
from CD players, we should probably have a separate driver for them.  My
solution has ben not to worry about driver support under NetSBD per say and
let cdrecord figure it out.  The down side to this is that I cannot
actually read cds on the same drive on which I burn them.  To do taht, I'd
have to hack the code that assigns devices to drivers.  While that might be
fine for me, I don't think it would be a good idea to try and put code in
the NetBSD tre which would try to go beyond the device type code, which in
this case is WORM (4), and rely on huristics, a quirk table if you will,
which would assign devices to drivers.  CD-Rs under Unix are a little
esoterik anyway, and as such, deserve a little higher knowledge on the part
of the user.  That said, however, some documentation showing how this stuff
fits together would be nice.
-Brian

On Jan 14,  2:38pm, Chris Jones wrote:
} Subject: Re: CD-R with NetBSD-1.3?
} On Mon, 12 Jan 1998, Brian Buhrow wrote:
} > 	I believe cdrecord has its own SCSI level driver, so as long as you
} > can expose the SCSI layer to cdrecord, it should work.  This should be true
} > whether or not the device shows up as a cd or as uk.  The advantage of
} > having it show up as a cd is that you can use the cd driver to actually
} > read from the cds you burn rather than having to switch them to another cd
} > player to test them.
} 
} This is my impression, too.
} 
} > 	My Sony 920S shows up as device type 4 which I guess is WORM.  Since
} > the cd driver doesn't recognize this type of device as something it can
} > drive, the subsystem doesn't assign it to the cd driver.  Thus, I get uk0
} > at  target 5 lun 0.
} 
} My HP 4020i doesn't appear to have a mechanism allowing it to switch from
} type 5 to type 4.  Hmmph.
} 
} > 	For ease of use with cdrecord, I symlink /dev/scgx to /dev/uk0.  I
} > suspect that if this thing showed up as a cd, I could symlink /dev/scgx to
} > /dev/cdxa and it would work.  Incidentally, I burned my first cd last night
} > on  the Sony with cdrecord 1.6, NetBSD 1.2G and the uk device.  It worked
} > great.
} 
} Actually, I think you'd need to link it to cd0d.  I tried it with cd0a,
} and I couldn't even get inquiry info from the CD-R.  With cd0d, however,
} it works.  (That's probably cd0c on other ports.)  This guess is supported
} by something I saw in one of many man pages I browsed; maybe cd(4).
} 
} > 	I suspect your problem is some timing incompatibility between the SCSI
} > CD-R driver inside cdrecord and your actual device.  Is it possible that
} > the device you have is a different revision than the one used to develop
} > the driver?
} 
} I sort of doubt it, but it *is* possible.  According to the friend I
} borrowed this from, this is one of the very first CD-R drives that came
} out.  I would think that it would, therefore, be more likely to have code
} written for it.
} 
} Does anybody know if there's any reason why NetBSD doesn't have a WORM (or
} CD-R) driver?  Would such a thing even be necessary, or do people think
} it's a better idea to go with programs like cdrecord, which uses the
} generic scsi(4) interface?
} 
} Chris
} 
} -------------------------------------------------------------------------------
} Chris Jones                                      cjones@rupert.oscs.montana.edu
}            Mad scientist in training...
} "Is this going to be a stand-up programming session, sir, or another bug hunt?"
} 
>-- End of excerpt from Chris Jones