. also detect the Phlips CDD2000; it's software-compatible with the HP part
Submitted by: cau@cc.gatech.edu (Carlos Ugarte)
. correct the blocksize handling for CD-DA tracks, and fix multitrack
handling
Submitted by: nsayer@quack.kfu.com (Nick Sayer)
2.2 candidates!
. remove some unused variables
. declare worminit() right this time, it's actually extern (?)
. use wormminphys(), now that it's already there (hope i've got this right)
Also declared worminit() to avoid a compiler warning. Seems that the
other SCSI drivers don't declare XXinit() yet, so perhaps we'd also
create a typedef for these func's.
The worm driver is alpha-usable! I've stuffed everything that is
needed into the kernel driver, including the logic to select
between different vendor's quirks.
Disclaimer: this has by now _only_ been tested on a heavily tweaked
2.0.5R system. I've done my best to retrofit it into -current, but
i don't have a chance yet to test it in a -current environment.
This makes it sorta usable, just for my ``proof-of-concept'' Perl
script i've been posting to freebsd-scsi. The driver will be
overhauled further, this is just to provide Jordan with a base to
perform testing of his own with his HP burner. Use entirely at your
own risk, expect a bunch of misburnt CD-R's when using it already in
this very green stage.
Note that by now the driver will only work when the CD-R has already
been in the drive at boot time.
most devsw referenced functions are now static, as they are
in the same file as their devsw structure. I've also added DEVFS
support for nearly every device in the system, however
many of the devices have 'incorrect' names under DEVFS
because I couldn't quickly work out the correct naming conventions.
(but devfs won't be coming on line for a month or so anyhow so that doesn't
matter)
If you "OWN" a device which would normally have an entry in /dev
then search for the devfs_add_devsw() entries and munge to make them right..
check out similar devices to see what I might have done in them in you
can't see what's going on..
for a laugh compare conf.c conf.h defore and after... :)
I have not doen DEVFS entries for any DISKSLICE devices yet as that will be
a much more complicated job.. (pass 5 :)
pass 4 will be to make the devsw tables of type (cdevsw * )
rather than (cdevsw)
seems to work here..
complaints to the usual places.. :)
That's EVERY SINGLE driver that has an entry in conf.c..
my next trick will be to define cdevsw[] and bdevsw[]
as empty arrays and remove all those DAMNED defines as well..
Each of these drivers has a SYSINIT linker set entry
that comes in very early.. and asks teh driver to add it's own
entry to the two devsw[] tables.
some slight reworking of the commits from yesterday (added the SYSINIT
stuff and some usually wrong but token DEVFS entries to all these
devices.
BTW does anyone know where the 'ata' entries in conf.c actually reside?
seems we don't actually have a 'ataopen() etc...
If you want to add a new device in conf.c
please make sure I know
so I can keep it up to date too..
as before, this is all dependent on #if defined(JREMOD)
(and #ifdef DEVFS in parts)
replacing them with TAILQ's as appropriate. The SCSI code is the
first to be changed -- until the changes are complete, both b_act and
b_actf will be in the buf structure. b_actf will eventually be removed.
o don't use polled mode after the device probe phase
o don't biodone() a NULL buffer pointer
o increase the timeout for scsi_read_capacity(); WORMs are slooow
o make WORMMs known to scsiconf at all
This brings the driver in a state where it at least doesn't
immediately panic, nor hangs the controller any more. Unfortunately,
at least the YAMAHA CDR100 i've been testing with answered my write
attempts with an "Incorrect command sequence" response. Perhaps other
CD burners might work however.
Reviewed by: dufault
loading kernel
worm.o: Undefined symbol `_STUNIT' referenced from text segment
I copied the STUNIT definition from the old scsiconf.c into this file to
work around this problem.
flags parameter to all xxstart routines so that the correct information can
be passed down into the device specific routines. This is needed to ensure
that ccb/scb allocation routines don't hang.
Submitted by: John Dyson
