With the previous commit that introduces the klist enhancements, we can
now re-do 2b7d6a8c again.

Revert commit 2b7d6a8c.

The "fix" was known to not even compile.  Duh.  That's not a fix.
That's just stupid.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Since the attribute container deletes from a klist while it's walking
it, it is vulnerable to the problem (and fix) here:

http://marc.theaimsgroup.com/?l=linux-scsi&m=112485448830217

The attached fixes this (but won't compile without the above).

It also fixes the logical reversal in the traversal loop which meant
that we were never actually traversing the loop to hit this bug in the
first place.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

One of the changes in the attribute_container code in the scsi-misc tree
was to add a lock to protect the list of devices per container.  This,
unfortunately, leads to potential scheduling while atomic problems if
there's a sleep in the function called by a trigger.

The correct solution is to use the kernel klist infrastructure instead
which allows lockless traversal of a list.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

If your transport class sets the ATTRIBUTE_CONTAINER_NO_CLASSDEVS flag,
then its configure method never gets called.  This patch fixes that so
that the configure method is called with a NULL classdev.

Also remove a spurious inverted comma in the transport_class comments.
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

I recently tried to construct a totally generic transport class and
found there were certain features missing from the current abstract
transport class.  Most notable is that you have to hang the data on the
class_device but most of the API is framed in terms of the generic
device, not the class_device.

These changes are two fold

- Provide the class_device to all of the setup and configure APIs
- Provide and extra API to take the device and the attribute class and
  return the corresponding class_device
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!