Remove unused device poll functions.

Also remove unneeded includes of <sys/poll.h> and <sys/select.h>.

Some addenda from jsg@.

OK miod@ mpi@

Constify struct cfattach.

ok visa@ a long time ago, ok krw@

Rename SID_INQUIRY_HDR (a.k.a. 5) to more explicit SID_SCSI2_HDRLEN and use it
to replace various uses of '5' when calculating the amount of data in the
INQUIRY response. Matches up more naturally wi

Rename SID_INQUIRY_HDR (a.k.a. 5) to more explicit SID_SCSI2_HDRLEN and use it
to replace various uses of '5' when calculating the amount of data in the
INQUIRY response. Matches up more naturally with SID_SCSI2_ALEN.

Also use to fix SCSIDEBUG display of INQUIRY responses to show correct count of
bytes received/available.

show more ...

Nuke unneeded 'sa_inqbuf' member of struct scsi_attach_args. It always
points to the inquiry data contained in the struct scsi_link pointed
to by the other member, sa_sc_link.

Nuke some unused variables, tweak some declarations and
variable names into a consistant idiom.

Remove the port id check entirely. We don't do anything with the port
id after that, so it seems like a silly reason to reject a target.

ok dlg@ deraadt@

hds arrays can have more ports now, apparently; this lets theo use 4 paths
to his array rather than just 2.

ok dlg@

More damned eye searing whitespace.

Remove some includes include-what-you-use claims don't
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.

ok tedu@ deraadt@

remove uneeded proc.h includes
ok mpi@ kspillner@

make the status handler more like rdac and emc. the big functional change
is to check xs->status on completion to make sure it worked.

massage the preferred path detection to happen when mpath asks for
a paths status, rather than on attach. the status it returns depends
on the type of device you have. hds provides two types of array

massage the preferred path detection to happen when mpath asks for
a paths status, rather than on attach. the status it returns depends
on the type of device you have. hds provides two types of arrays,
symmetric and asymmetric.

on a symmetric device you can shove io down any path to any port
on any controller and it will work. on symmetric devices we say all
paths are part of the same group, and unconditionally return active
path status to any check request.

on asymmetric devices we group paths by which controller in teh
array they connect to. the controllers return whether theyre providing
a preferred path via a couple of status bits in a hds specific vpd
page, so we query that and return the state of the bits.

unfortunately hds arrays dont report change of lun ownership in any
way, so we dont currently have any way of failing over at the moment.
ill have to think about the least worst way to handle that.

tested by deraadt@ on hppa

show more ...

Add a DVACT_WAKEUP op to the *_activate() API. This is called after the
kernel resumes normal (non-cold, able to run processes, etc) operation.
Previously we were relying on specific DVACT_RESUME op

Add a DVACT_WAKEUP op to the *_activate() API. This is called after the
kernel resumes normal (non-cold, able to run processes, etc) operation.
Previously we were relying on specific DVACT_RESUME op's in drivers
creating callback/threads themselves, but that has become too common,
indicating the need for a built-in mechanism.
ok dlg kettenis, tested by a sufficient amount of people

show more ...

fix format string; OK deraadt@

make path driver match routes return 8 so they will definitely be higher
than the real device drivers. ses returns 3 on some dells, which could be
confusing for autoconf if it has to decide between t

make path driver match routes return 8 so they will definitely be higher
than the real device drivers. ses returns 3 on some dells, which could be
confusing for autoconf if it has to decide between that and a path driver.

show more ...

get rid of the different path scheduler types, which simplifies the
code that picks the next path. we assume roundrobin within a group
of paths now. the asym sym(4) devices work around this by puttin

get rid of the different path scheduler types, which simplifies the
code that picks the next path. we assume roundrobin within a group
of paths now. the asym sym(4) devices work around this by putting
every path in its own group.

show more ...

these were forgotten in the change from pointing paths to groups instead
of devices. fixes compilation when theyre enabled.

how embarrassment.

when i first imagined how paths on mpath worked, i thought the
midlayer would be able to call things on paths to explicitely online
or offline them. turns out thats not how the Real World(tm) works,

when i first imagined how paths on mpath worked, i thought the
midlayer would be able to call things on paths to explicitely online
or offline them. turns out thats not how the Real World(tm) works,
instead its better to wait for failure and probe for the status of
paths, and pick the active group of paths from that. there's even
evidence that the mechanisms for forcing controllers into active/passive
roles from the scsi initiator are being deprecated. they expect
hosts to be able to cope with arbitrary controller role changes and
failover
accordingly.

this replaces the online and offline function pointers in the path_ops
structure with a status check function pointer. instead of returning a
state, the checker is expected to call mpath_path_status() when its
finished figuring out what the state is.

show more ...

checksense handlers in path drivers can return MPATH_SENSE_DECLINED
(who can tell ive spent time in web servers) to say they decline
interpreting the sense data, or MPATH_SENSE_FAILOVER to say the
se

checksense handlers in path drivers can return MPATH_SENSE_DECLINED
(who can tell ive spent time in web servers) to say they decline
interpreting the sense data, or MPATH_SENSE_FAILOVER to say the
sense data is from the controller saying its failed over.

all path drivers currently decline handling sense data.

show more ...

introduce the idea of groups of paths. mpath had stuff to managed
devices and paths. devices are what mpath presents as targets on
its scsibus, and paths are the things attached to hardware controlle

introduce the idea of groups of paths. mpath had stuff to managed
devices and paths. devices are what mpath presents as targets on
its scsibus, and paths are the things attached to hardware controllers
that are available to shove io down to the actual real target. all
paths were considered usable for handling io on behalf of a device.

this adds groups in between devices and paths. only paths on the
first group in the list will now be used to handle io now.

sym devices will only have one group. asym devices will treat each
path as a different group. rdac, emc, and hds will group paths based
on which controller in the array theyre connected to.

in the future we will intercept sense data from passive controllers
and use that to start running checks to pick a new primary group
so we can handle controller failover situations.

the group id in hds(4) is currently busted, everything else should
be correct.

show more ...

support "failover" style access to volumes, ie, only use one active
path when talking to an array until it goes away, then you fail
over to the next active path.

im using this to talk to ses(4) in m

support "failover" style access to volumes, ie, only use one active
path when talking to an array until it goes away, then you fail
over to the next active path.

im using this to talk to ses(4) in my dell, and allows us to support
arrays that have multiple controllers but have no way of reporting
which one is active. using the MRU semantic means we can talk to
them without them flipping the active role between its controllers
all the time. claudios transtec iscsi box is like this.

show more ...

Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thing
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.

ok deraadt@, dlg@; miod@ al

Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thing
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.

ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it
up a few weeks ago

show more ...

print which ldev, controller, port, and whether we're asymmetric or
symmetric.

dont leak bufs on xs failure and make sure we free the buf back to the
right dma pool.

check the preferred path ownership bit rather than assuming that odd luns
like to be talked to on odd paths, and even luns like being talked to
on even paths.

clean up the path ops struct a bit. the path drivers init their xsh with
their start routines, they dont have to pass pointers to them in the
ops struct.