procfs support for sgiwd93

FYI and reviewing pleassure.

Author: Thiemo Seufer <[email protected]>
Date:   Tue Apr 12 14:00:38 2005 +0000

Enable proc support, minor code cleanup.

 drivers/scsi/sgiwd93.h |   24 ------------------------
 drivers/scsi/sgiwd93.c |    8 ++++----
 2 files changed, 4 insertions(+), 28 deletions(-)

Index: manual.git/drivers/scsi/sgiwd93.c
===================================================================
@@ -33,7 +33,6 @@
 #include "scsi.h"
 #include <scsi/scsi_host.h>
 #include "wd33c93.h"
-#include "sgiwd93.h"
 
 #include <linux/stat.h>
 

@@ -327,7 +326,6 @@ static int sgiwd93_bus_reset(Scsi_Cmnd *
  * on 64-bit systems with memory outside the compat address spaces.
  */
 static Scsi_Host_Template driver_template = {
-	.proc_name		= "SGIWD93",
 	.name			= "SGI WD93",
 	.detect			= sgiwd93_detect,
 	.release		= sgiwd93_release,

@@ -335,10 +333,12 @@ static Scsi_Host_Template driver_templat
 	.eh_abort_handler	= wd33c93_abort,
 	.eh_bus_reset_handler	= sgiwd93_bus_reset,
 	.eh_host_reset_handler	= wd33c93_host_reset,
-	.can_queue		= CAN_QUEUE,
+	.proc_info		= wd33c93_proc_info,
+	.proc_name		= "SGIWD93",
+	.can_queue		= 16,
 	.this_id		= 7,
 	.sg_tablesize		= SG_ALL,
-	.cmd_per_lun		= CMD_PER_LUN,
+	.cmd_per_lun		= 8,
 	.use_clustering		= DISABLE_CLUSTERING,
 };
 #include "scsi_module.c"

Index: manual.git/drivers/scsi/sgiwd93.h
===================================================================
@@ -1,24 +0,0 @@
-/* $Id: sgiwd93.h,v 1.5 1998/08/25 09:18:50 ralf Exp $
- * sgiwd93.h: SGI WD93 scsi definitions.
- *
- * Copyright (C) 1996 David S. Miller ([email protected])
- */
-#ifndef _SGIWD93_H
-#define _SGIWD93_H
-
-#ifndef CMD_PER_LUN
-#define CMD_PER_LUN 8
-#endif
-
-#ifndef CAN_QUEUE
-#define CAN_QUEUE   16
-#endif
-
-int sgiwd93_detect(Scsi_Host_Template *);
-int sgiwd93_release(struct Scsi_Host *instance);
-const char *wd33c93_info(void);
-int wd33c93_queuecommand(Scsi_Cmnd *, void (*done)(Scsi_Cmnd *));
-int wd33c93_abort(Scsi_Cmnd *);
-int wd33c93_host_reset(Scsi_Cmnd * SCpnt);
-
-#endif /* !(_SGIWD93_H) */

isn't this the wrong way around; eg afaik we're deprecating proc support from LLDD's...

No more ioctls for LLDDs, no more procfs, just a sysfs straight jacket; until sysfs goes the way of devfs ...

A subversive thought: a SAS LLDD supporting a SMP target (as well as the standard SSP,SMP and STP initiators). Then, via vendor specific SMP functions, control apps can access the HBA to do things that linux disallows or makes difficult :-)
[May not work unless HBAs have the equivalent of the network "lo" interface.]

Doug Gilbert

for this purpose sysfs and procfs are "enough the same" that it doesn't warrant the term "staight jacket" imo.
And /proc is realistically the wrong place for such info....

NACK, no more new procfs support for scsi driver.

The sgiwd93.h removal is fine, but please also mark all functions that were in it previously static.

It's not like this is really adding procfs support; it's more wiring up a function in sgiwd93.c that exists anyway in wd33c93.c.

Ralf

Which is bad enough. A patch to remove the procfs code code from wd33c93.c would be gentley accepted, though ;-)

James Bottomley,
Is there any such policy?

Christoph Hellwig previously has used this purported policy to reject scsi procfs bug fixes:
"[PATCH] scsi: /proc/scsi/scsi patch for large number of devices" As for alternate tools to 'cat /proc/scsi/scsi', I
am not aware of many distributions using lsscsi (debian and gentoo do), perhaps there are other tools. I suspect a lot of folks are still using 'cat /proc/scsi/scsi'.

Does Christoph Hellwig have the right to NACK/veto etc work that is not his when you are the SCSI maintainer?

Douglas Gilbert

Yes, there is. It's not actually mine, it's the direction coming out of several kernel summits. /proc is to be moved back to handling process information. /sys should be used for other ancillary information exporting.

This policy can be interpreted with some elasticity depending on what an author wants to do.

/proc/scsi/scsi has an awful lot of failure cases. The most annoying one seems to be periodically losing hot added devices.

The reason for not fixing something if it's not a severe bug is simply that if we keep /proc/scsi/scsi fully functional and up to date, then the distributions will have no incentive to move away from it.

Technically no-one truly gets a veto since there are many ways code can end up in the vanilla kernel; however, everyone gets to express their opinion ...

James