This patch was inspired by Al Viro, for simplifying and fixing the
retrieval of osd-devices by in-kernel users, eg: file systems.
In-Kernel users, now, go through the same path user-mode does by
opening a file on the osd char-device and though holding a reference
to both the device and the Module.

A file pointer was added to the osd_dev structure which is now
allocated for each user. The internal osd_dev is no longer exposed
outside of the uld. I wanted to do that for a long time so each
libosd user can have his own defaults on the device.

The API is left the same, so user code need not change.

It is no longer needed to open/close a file handle on the osd
char-device from user-mode, before mounting an exofs on it.
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
CC: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

... use kern_path() where possible

[folded a fix from rdd]
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Remove the creation of the symlink from the device to
it's class. On modern systems this is already created by
a udev rule and would WARN on load. On old systems it is
not needed, none of the current osd user-mode tools use
this link.
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Auto detect an OSDv2 or OSDv1 target at run time. Note how none
of the OSD API calls change. The tests do not know what device
version it is.

This test now passes against both the IBM-OSD-SIM OSD1 target
as well as OSC's OSD2 target.
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Reviewed-by: NBenny Halevy <bhalevy@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Kernel clients like exofs can retrieve struct osd_dev(s)
by means of below API.

+ osduld_path_lookup() - given a path (e.g "/dev/osd0") locks and
returns the corresponding struct osd_dev, which is then needed
for subsequent libosd use.

+ osduld_put_device() - free up use of an osd_dev.

Devices can be shared by multiple clients. The osd_uld_device's
life time is governed by an embedded kref structure.

The osd_uld_device holds an extra reference to both it's
char-device and it's scsi_device, and will release these just
before the final deallocation.

There are three possible lock sources of the osd_uld_device
1. First and for most is the probe() function called by
  scsi-ml upon a successful login into a target. Released in release()
  when logout.
2. Second by user-mode file handles opened on the char-dev.
3. Third is here by Kernel users.
All three locks must be removed before the osd_uld_device is freed.

The MODULE has three lock sources as well:
1. scsi-ml at probe() time, removed after release(). (login/logout)
2. The user-mode file handles open/close.
3. Import symbols by client modules like exofs.

TODO:
  This API is not enough for the pNFS-objects LD. A more versatile
  API will be needed. Proposed API could be:
  struct osd_dev *osduld_sysid_lookup(const char id[OSD_SYSTEMID_LEN]);
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>

Add a Linux driver module that registers as a SCSI ULD and probes
for OSD type SCSI devices.

When an OSD-type SCSI device is found a character device is created
in the form of /dev/osdX - where X goes from 0 up to hard coded 64.
The Major character device number used is 260.
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
Reviewed-by: NBenny Halevy <bhalevy@panasas.com>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>