peripheral drivers can determine where in the devstat(9) list they are
inserted.
This requires recompilation of libdevstat, systat, vmstat, rpc.rstatd, and
any ports that depend on the devstat code, since the size of the devstat
structure has changed. The devstat version number has been incremented as
well to reflect the change.
This sorts devices in the devstat list in "more interesting" to "less
interesting" order. So, for instance, da devices are now more important
than floppy drives, and so will appear before floppy drives in the default
output from systat, iostat, vmstat, etc.
The order of devices is, for now, kept in a central table in devicestat.h.
If individual drivers were able to make a meaningful decision on what
priority they should be at attach time, we could consider splitting the
priority information out into the various drivers. For now, though, they
have no way of knowing that, so it's easier to put them in an easy to find
table.
Also, move the checkversion() call in vmstat(8) to a more logical place.
Thanks to Bruce and David O'Brien for suggestions, for reviewing this, and
for putting up with the long time it has taken me to commit it. Bruce did
object somewhat to the central priority table (he would rather the
priorities be distributed in each driver), so his objection is duly noted
here.
Reviewed by: bde, obrien
to release the probe ccb before taking down the periph.
Also, don't do cdscheduling if you're not going to
attach the device after all.
Reviewed by: ken@freebsd.org
for possible buffer overflow problems. Replaced most sprintf()'s
with snprintf(); for others cases, added terminating NUL bytes where
appropriate, replaced constants like "16" with sizeof(), etc.
These changes include several bug fixes, but most changes are for
maintainability's sake. Any instance where it wasn't "immediately
obvious" that a buffer overflow could not occur was made safer.
Reviewed by: Bruce Evans <bde@zeta.org.au>
Reviewed by: Matthew Dillon <dillon@apollo.backplane.com>
Reviewed by: Mike Spengler <mks@networkcs.com>
other problem.
- Hold onto splsoftcam() in the peripheral driver open routines until we
have locked the periph. This eliminates a race condition.
- Disallow opening the pass driver when securelevel > 1.
- If a user tries to open the pass driver with O_NONBLOCK set, return
EINVAL instead of ENODEV. (noticed by gibbs)
to a device failed.
In theory, the same steps that happen when we get an AC_LOST_DEVICE async
notification should have been taken when a driver fails to attach. In
practice, that wasn't the case.
This only affected the da, cd and ch drivers, but the fix affects all
peripheral drivers.
There were several possible problems:
- In the da driver, we didn't remove the peripheral's softc from the da
driver's linked list of softcs. Once the peripheral and softc got
removed, we'd get a kernel panic the next time the timeout routine
called dasendorderedtag().
- In the da, cd and possibly ch drivers, we didn't remove the
peripheral's devstat structure from the devstat queue. Once the
peripheral and softc were removed, this could cause a panic if anyone
tried to access device statistics. (one component of the linked list
wouldn't exist anymore)
- In the cd driver, we didn't take the peripheral off the changer run
queue if it was scheduled to run. In practice, it's highly unlikely,
and maybe impossible that the peripheral would have been on the
changer run queue at that stage of the probe process.
The fix is:
- Add a new peripheral callback function (the "oninvalidate" function)
that is called the first time cam_periph_invalidate() is called for a
peripheral.
- Create new foooninvalidate() routines for each peripheral driver. This
routine is always called at splsoftcam(), and contains all the stuff
that used to be in the AC_LOST_DEVICE case of the async callback
handler.
- Move the devstat cleanup call to the destructor/cleanup routines, since
some of the drivers do I/O in their close routines.
- Make sure that when we're flushing the buffer queue, we traverse it at
splbio().
- Add a check for the invalid flag in the pt driver's open routine.
Reviewed by: gibbs
well) Among them:
[ cd driver ]
1. Old labeling code was still there.
2. Error handling for dsopen() was broken (no test for the `error'
returned by dsopen(); bogus test of an `error' that is known to be 0).
3. cdopen() closed the physical device after certain errors although there
may still be open partitions on it.
4. cdclose() closed the physical device although there may still be open
partitions on it.
5. Some printf format fixes was incomplete or missing.
6. cdioctl() truncated unit numbers mod 256.
7. cdioctl() was missing locking.
[ da driver ]
1. daclose() closed the physical device although there may still be open
partitions on it. This was fixed many years ago in sd.c rev.1.57.
2. A minor optimization (the dk_slices != NULL test) in sdopen() became
uglier in daopen(). It is not worth doing. da only regressed compared
with od and my version of sd, since I never committed the change to sd.
daopen() should probably do less if some partition is already open.
This is not addressed by the diffs.
[ ... ]
5. "opt_hw_wdog.h" was not included, so the HW_WDOG code was unreachable.
- Added a getdev CCB call in the cdopen() and daopen() calls so that the
vendor name and device name are available for the disklabel. (suggested
by bde)
- Removed vestigal devfs support in both drivers, since we can't properly
work with devfs yet. (ask bde for details on this)
- Cleaned up the probe code in both drivers in the failure cases. There
were a number of things wrong here. The peripheral driver instances
weren't getting properly cleaned up. Sometimes the wrong probe message
would get printed out (with the failure message appended), so it wasn't
very clear that we failed to attach. SCSI sense information was printed,
even when the error in question wasn't a SCSI error. I put similar fixes
into the changer driver in revision 1.2 of scsi_ch.c.
Reviewed by: gibbs
Submitted by: bde (partially)
already allowed medium not present type errors (0x3a), but some Philips and
HP WORM drives return 0x04,0x00 when you issue a read capacity without
media in the drive.
flags on some of the operations in the driver weren't quite right. Also,
clean up scsi_cd.h, change u_char to u_int8_t.
I'm surprised this problem didn't show up sooner. (the code has been in
there almost a year and a half)
PR: 7996
Reviewed by: ken
Submitted (mostly) by: gibbs
a perfect world, we'd notice the UA and do some device validation to ensure
that the device hasn't changed. We may get this before the year ends,
but not before 3.0R. This change gives the adminstrator ample ammunition
to take off a foot or two, but hey this *is* UN*X.
