Date: Wed, 29 Jan 1997 16:38:00 -0800 From: Julian Elischer <julian@whistle.com> To: Simon Shapiro <Shimon@i-Connect.Net> Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI Driver Open/Close Routines Message-ID: <32EFED68.2F1CF0FB@whistle.com> References: <XFMail.970129152040.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon Shapiro wrote:
>
> Hi there...
>
> We observe that in scsi/scsiconf.h the scsi_adapter definition for the
> (entry points) open /close do not take any arguments, unless the bus is
> PC98.
>
> In the case of PC98, open takes a scsi_link as an argument, but still no
> argument for close.
>
> What we need is two things:
>
> 1. We need to be able to open the individual controller, and close it.
> We need to maintain control over the exact state of each controller,
> Is it open, closed, etc.
Adapters are neither open or closed.
they just "are".
An adapter takes asynchronous commands fro higher level device
drivers but keeps almost no state itself 9except as to how many
more simultanious operations it can support (known as "opennings")
> This control extends to IF and when a SCSI
> bus or device are reset and other such details. Part of this need is
> to be able to communicate with the controller via several methods.
what do you need totalk to the adapter for fro raid setup?
does the adapter do the raid itself?
> Things we need to do are RAID setup, firmware configuration, SNMP and
> others. The mechanism we see today in FreeBSD does not seem to allow
> it in the scsi_adapter entry points. Can someone help us understand it?
My sugestion is to attach a scsi device to the ADAPTER's scsi sddress in
the
devices array.
this device could use a differnt 'adapter entrypoint structure,
to call differnt routines .
>
> 2. We need to be able to precisely control the access to every device on
> any SCSI bus on any HBA. This includes allowing/barring access, putting
> devices in R/O or R/W mode, resetting and blocking resets. The entry
> points in scsi_device allow that. We also understand from having
> scsi_device defined for an adapter that the adapter can appear as a
> device. Question: What will this device be in /dev? Major, minor,
> naming convention, etc.
whatever you define it to be
you haven't written the driver for it yet :)
we just provided the hooks.. you supply the driver..
the major is just an nteger to indentify your driver..
it's assigned to you..
teh minor is passed to the driver..
you can define it to be used in any way you want..
usually some bits are reserved to specify a unit number.
Other uses include: using some bits to define operating mode,
or using some bits to indicate debug features..
that's totally up to you..
we just pass it straight to you..
>
> ..but; For both scsi_adapter and scsi_device, in the drivers code we saw,
> there is a single, scalar declaration of scsi_adapter and scsi_device.
> We would like to be able to turn these into arrays (logically). So each
> HBA is its own scsi_adapter and each HBA is its own scsi_device, with the
> associated /dev/ entries, as above.
each adapter driver has an array of entry points for both adapter-side
and device-side(never used yet, you might be the first) functions
to call. However this is only referenced via the scsi_link structure
associated with the calling device.
There is nothing to say that you might not have MORE THAN ONE set of
entry points, and that the differnt devices (each device has it's own
scsi-link) might not point to difernt entry points to get diferent
behaviour. How you set thes up is a different question..
There is also a separate scsibus_data[] structure allocated
for each BUS and there could be several busses per adapter.
basically each of the following has it's own information:
the adapter type: the driver has an array of entrypoints
and things that are invariant.
the specific adapter: keeps track of things that change
(e.g. opennings)
the scsi bus: keeps track of what's attached where
the device type: has a structure of entrypoints etc.
each device instance: has information about where it's
attached (invariant) and dynamic info.
the scsi_link structure links all these different
pieces together, (hence it's name).
none of these items access the other directly.
they ALWAYS go via the scsi_link. If you change
a scsi_link, you change reality..
julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?32EFED68.2F1CF0FB>