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.. :)
to get the definitions of TRUE and FALSE which happen to be defined in
a deeply nested include.
Added nearby #includes of <sys/conf.h> where appropriate.
sscselect(). Use the standard dummies nostrategy(), noread(),
nowrite() and noselect() instead.
sscread() and sscwrite() returned bogus errnos. It isn't possible
to return an error from a select routine so noselect() is just as
bogus as sscselect() (it's equivalent to nullselect()).
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)
Convert the remaining sysctl stuff to the new way of doing things.
the devconf stuff is the reason for the large number of files.
Cleaned up some compiler warnings while I were there.
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.
These functions went away:
enosys (hasn't been used for some time)
enxio
enodev
enoioctl (was used only once, actually for a vop)
if_tun.c:
Continued cleaning up...
conf.h:
Probably fixed the type of d_reset_t. It is hard to tell the correct
type because there are no non-dummy device reset functions.
Removed last vestige of ambiguous sleep message strings.
to <machine/conf.h>. conf.h was mechanically generated by
`grep ^d_ conf.c >conf.h'. This accounts for part of its ugliness. The
prototypes should be moved back to the driver sources when the functions
are staticalized.
magneto-optical devices, it's scope can (and should) be widened to
cover all removable type 0 (direct) devices as well, since this class
of devices is sharing the same principles. Things like suport for
media eject etc. will be supported later. (Shunsuke is also working
on the problems arising out of the use of media with physical block
size != 512 bytes (which is not uncommon for MODs).
Submitted by: akiyama@kme.mei.co.jp (Shunsuke Akiyama)
itself. Will do this after this commit.)
Make scsiconf more flexible about recognizing ``foreign'' devices.
This part needs to be rewritten some day to allow for matches whithou
strict version number checks, but either Julian as Peter seem to be
too busy right now, so i'm finally commiting the version that's
working for me stable now for several months, as an interim
workaround.
Submitted by: akiyama@kme.mei.co.jp (Shunsuke Akiyama)
sometime around 1.51, the check for minphys dissappeared out of
transfers for disks..
we weren't hecking that the adapter could handle a transfer of
the size we were requesting..
Peter!?
:)
this explains the rash of failures I've seen reported recently
with "too many DMA segments" on raw devices
(added one for st as well)
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
This change forces the controller drivers to allocate a scsibus_data struct
via a call to scsi_alloc_bus(), fill in the adapter_link field, and optionally
modify any other fields of the struct. Scsi_alloc_bus() initializes all fields
to the default, so the changes in most drivers are very minimal. For drivers
that support Wide controllers, the maxtarg field will have to be updated to
allow probing of all targets (for an example, look at the aic7xxx driver).
Scsi_attachdevs() now takes a scsibus_data* as its argument instead of an
sc_link*. This allows us to expand the role of the scsibus_data struct for
other bus level configuration setings (max number of transactions, current
transaction opennings, etc for better tagged queuing support).
Reviewed by: Rodney Grimes <rgrimes>, Peter Dufault <dufault>, Julian Elischer <julian>
for the kernel, but gcc provides an inline version of it if the
kernel is compiled with -O.
The inline memcmp() is OK for small compares and is better than
the dumb kernel bcmp() in all cases, but it has been hiding the
library memcmp() which is 4 times faster for large compares.
This is performed by using a line similar to:
controller scbus0 at ahc0 bus 1
to wire scbus0 to the second bus on an adaptec 2742T controller.
Reviewed by: Peter Dufault(dufault@hda.com), Rod Grimes(rgrimes@FreeBSD.org)
probes). Apart from there being no reason to set SCSI_NOSLEEP on every
tape command, this prevents controller drivers from sleeping when resources
are fully utilized causing unecessary "Oops not queued" errors. This is
only noticed for controllers that can run out of resources like the
27/2842 adaptec controllers. Before this fix, it is almost impossible to
perform extended tape operations if more than one scsi disk is on the
bus with the tape drive with these controllers. This does not address a
similar problem that could occur if devices are probed while other targets
are active since SCSI_NOSLEEP will still be set in that case.
>Synopsis: Booting w/scsi tape in drive causes first use to fail
Booting with a tape in a SCSI tape drive will cause the first
use of the tape to fail with the following message:
st0: bad request, must be between 0 and 0.
Submitted by: mpp@legarto.minn.net (Mike Pritchard)
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.
Added CONTROL device that only does user-ioctl and nothing else;
Added protection so user-ioctl requires write access;
Clean up scsiconf.h a little. It needs more work.
user-level part has already been commited.)
Note that i've lost the "official" code for this; it went into the
system after 1.1.5.1. The commited code is my own version, but it has
proven to work for me for more than a year now.
