use to synchornize and protect all data objects that are used for that
SIM. Drivers that are not yet MPSAFE register Giant and operate as
usual. RIght now, no drivers are MPSAFE, though a few will be changed
in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled.
The userland API has not changed, so tools like camcontrol do not need to
be recompiled.
Linux SCSI SG passthrough device API. The intention is to allow for both
running of Linux apps that want to talk to /dev/sg* nodes, and to facilitate
porting of apps from Linux to FreeBSD. As such, both native and linuxolator
entry points and definitions are provided.
Caveats:
- This does not support the procfs and sysfs nodes that the Linux SG
driver provides. Some Linux apps may rely on these for operation,
others may only use them for informational purposes.
- More ioctls need to be implemented.
- Linux uses a naming scheme of "sg[a-z]" for devices, while FreeBSD uses a
scheme of "sg[0-9]". Devfs aliasis (symlinks) are automatically created
to link the two together. However, tools like camcontrol only see the
native names.
- Some operations were originally designed to return byte counts or other
data directly as the syscall return value. The linuxolator doesn't appear
to support this well, so this driver just punts for these cases.
Now that the driver is in place, others are welcome to add missing
functionality. Thanks to Roman Divacky for pushing this work along.
flash card reader.
Also remove an 'Opened da0 -> <random number>' which is not needed on a daily
basis (available through bootverbose).
Reviewed by: phk, ken
MFC after: 1 week
the ORDERED tag. This recoups significant performance gains for many
arrays.
The default is still to send out the ORDERED tag periodically.
Reviewed by: scsi (justin+timeout)
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).
After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
REPORT LUNS command to a device.
camcontrol.[c8]: Implement reportluns. This tries to print the LUNs
out in a reasonable format. Only the periph
addressing method has been tested, since very little
hardware that I know of supports the other methods.
scsi_all.[ch]: Revamp the report luns CDB structure and helper
functions. This constitutes a little bit of an API
change, but since the old CDB length was 10 bytes,
and the REPORT LUNS CDB length is actually 12 bytes,
it's clear that no one was using this API in the
first place.
MFC After: 1 week
usage as of SPC2r20. Specifically, handle the BQueue
flag which will indicate that a device supports the
Basic Queueing model (no Head of Queue or Ordered tags).
When this flag is set, SID_CmdQueue is clear. This has
causes FreeBSD to assume that the device did not support
tagged operations.
MFC after: 1 month
This version of scsi_target.c removes all SMP locking until
we have a lock-aware CAM stack. This allows us to use KNOTE
without a panic at least.
It's not yet clear whether target mode is working yet or not.
Discussed with: Scott, Ken, Nate, Justin
return to user space w/o waiting for I/O to complete.
I tried to get several folks who know this code better than me to review it
with no luck. I *do* know that w/o this code, using the SCSI target driver
panics in userret (if it doesn't panic in knote first).
an application to upon a tape (yea, even the non-control device) even if
it cannot establish a mount session. If the open cannot establish a mount
session and O_NONBLOCK was specified, the tape becomes 'open pending mount'.
All I/O operations that would require access to a tape thereafter until
a close attempt to initiate the mount session. If the mount session succeeds,
the tape driver transitions to full open state, else returns an appropriate
I/O error (ENXIO).
At the same time, add a change that remembers whether tape is being opened
read-only. If so, disallow 'write' operations like writing filemarks that
bypass the normal read-only filtering operations that happen in the write(2)
syscall.
Reviewed by: ken, justin, grog
MFC after: 2 weeks
Suggested by: The Bacula Team
the underlying drive had been hot-unplugged from the system. Here
is a specific example. Filesystem code had opened /dev/da1s1e.
Subsequently, the drive was hot-unplugged. This (correctly) caused
all of the associated /dev/da1* entries to be deleted. When the
filesystem later realized that the drive was gone it closed the
device, reducing the write-access counts to 0 on the geom providers
for da1s1e, da1s1, and da1. This caused geom to re-taste the
providers, resulting in the devices being created again. When the
drive was hot-plugged back in, it resulted in duplicate /dev entries
for da1s1e, da1s1, and da1.
This fix adds a new disk_gone() function which is called by CAM when a
drive goes away. It orphans all of the providers associated with the
drive, setting an error condition of ENXIO in each one. In addition,
we prevent a re-taste on last close for writing if an error condition
has been set in the provider.
Sponsored by: Isilon Systems
Reviewed by: phk
MFC after: 1 week
event handler, dev_clone, which accepts a credential argument.
Implementors of the event can ignore it if they're not interested,
and most do. This avoids having multiple event handler types and
fall-back/precedence logic in devfs.
This changes the kernel API for /dev cloning, and may affect third
party packages containg cloning kernel modules.
Requested by: phk
MFC after: 3 days
- Introducing the possibility of using locks different than mutexes
for the knlist locking. In order to do this, we add three arguments to
knlist_init() to specify the functions to use to lock, unlock and
check if the lock is owned. If these arguments are NULL, we assume
mtx_lock, mtx_unlock and mtx_owned, respectively.
- Using the vnode lock for the knlist locking, when doing kqueue operations
on a vnode. This way, we don't have to lock the vnode while holding a
mutex, in filt_vfsread.
Reviewed by: jmg
Approved by: re (scottl), scottl (mentor override)
Pointyhat to: ssouhlal
Will be happy: everyone
