FreeBSD/alpha. The most significant item is to change the command
argument to ioctl functions from int to u_long. This change brings us
inline with various other BSD versions. Driver writers may like to
use (__FreeBSD_version == 300003) to detect this change.
The prototype FreeBSD/alpha machdep will follow in a couple of days
time.
Defer the WRITE SESSION command until the first write command, so that
it works like the prepare track command, allowing the device to be
closed after the command.
This introduce an xxxFS_BOOT for each of the rootable filesystems.
(Presently not required, but encouraged to allow a smooth move of option *FS
to opt_dontuse.h later.)
LFS is temporarily disabled, and will be re-enabled tomorrow.
under -current. The actual preparation of the next track will now be
deferred until just before the first write operation. Otherwise,
opening the device with write intent will cause the execution of
commands that are illegal in `limited command set mode' (i.e., after
the write channel has been opened).
While i was at it, cleaned up the worm_open() function a bit.
Removed the volume overflow pre-check in worm_strategy(). It was
time-consuming, and rather useless in many cases anyway (with the size
being reported for just the entire volume only), so we can as well let
the actual SCSI command fail instead, where it'll properly be reported
as EIO.
Partially submitted by & discussed with: jmz
unknown drive. Such a drive will be configured by worm(4)
nevertheless (albeit with a warning), but cannot be opened except of
the SCSI control device (so scsi(8) or cdrecord will continue to
work).
These commands are required for the "Disk-At-Once" write process:
WORMIOCREADSESSIONINFO returns the length of the lead-in and lead-out areas
and WORMIOCWRITESESSION is used to send the table of contents of the disk.
- remove all calls to scsi_stop_unit(). Some drives refuse commands when
stopped. This will fix the 'device not configured' message which was
cleared after opening/closing the tray.
- Never set the logical block address in the scsi_cmd struct when writing.
The computation was bogus for block sizes not a multiple of DEV_BSIZE.
(the bug is still there in the READ case)
- reset the block size to the 2048 bytes in finalize_track() track to avoid
an error when mounting a disk after an audio write.
- remove the WORMIOCQUIRKSELECT ioctl. Quirks are now recorded at probe time
(see scsiconf.c)
- change and expand the argument to the WORMIOCPREPTRACK ioctl. It now possible
to select more track options (copy bits, ISRC codes, track type,
track number)
- add an error handler to catch false errors (warnings in fact) and record
the error type.
- add an ioctl call (WORMIOERROR) to get more information on the nature of the
error when a command or a write failed.
- add an ioctl call (WORMIOCFINISHTRACK) to finalize a track without closing
the device (closing the device still finalize the track if the command was
not performed)
Approved by: joerg
the work is silly, and all this will be a moot point with Justin's CAM
driver, and there are still many ioctls missing -- but i need these
right now. It's silly to need to move the CD-R back to the other
drive in order to determine the session start info when burning multi-
session CD-Rs.
I got tired of not seeing my worm stats show up during a burn. :)
[Joerg, I just stapled in 1MB/sec for a bogus xfer rate and left seek = 1,
as suggested - I'm not going to dynamically calculate the xfer rate from
a known device spectable, OK? :-)]
Reviewed by: joerg
read-mode access to CD-ROM media in the worm(4) driver. No whistles
and bells yet, like all the CDIO* commands, but at least a start.
In order to do this, i had to slightly rearrange the semantics of an
open(2) on the worm driver: now, opening it with O_NONBLOCK set means
no actual IO operations will be intended but only ioctls are to be
processed. This mode is used by wormcontrol(8) to prepare a track
and/or session.
I have only been able to test this on a 2.2-GAMMA system by now, and
only the !DEVFS part is tested yet. Also, i have only done a dummy
burn so far, but wouldn't expect many surprises else. Report bugs to
me ASAP, if there's reasonable demand and i hear no objections, i
might consider merging it into the 2.2 branch as well.
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
. 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
Doug Rabson
Peter Wemm
Bruce Evans
Jean-Marc Zucconi
Eivind Eklund
Joerg Wunsch
Poul-Henning Kamp
Justin T. Gibbs
Jordan K. Hubbard
Marc G. Fournier
Garrett Wollman
Julian Elischer
John Dyson
Rodney W. Grimes