2.5.48 /proc/scsi directory missing

2.5.48 /proc/scsi directory missing

[Douglas Gilbert]

That directory (and all who sail in her, e.g. /proc/scsi/scsi)
seems to have disappeared. When the scsi_debug module is
loaded a /proc/scsi_debug/0 entry appears (that used to be
/proc/scsi/scsi_debug/0).

Doug Gilbert

Re: 2.5.48 /proc/scsi directory missing

[Patrick Mansfield]

On Tue, Nov 19, 2002 at 10:45:25AM +1100, Douglas Gilbert wrote:
> That directory (and all who sail in her, e.g. /proc/scsi/scsi)
> seems to have disappeared. When the scsi_debug module is
> loaded a /proc/scsi_debug/0 entry appears (that used to be
> /proc/scsi/scsi_debug/0).
> 
> Doug Gilbert

It looks like the merge of Doug and Christoph's code dropped two calls
(unless the exit devfs_unregister was supposed to be removed).

Here's a patch for the addition of scsi_init_procfs, devfs_mk_dir and
bus_unregister calls, and a small reordering so calls in exit_scsi
match the reverse of those in init_scsi.

--- 1.67/drivers/scsi/scsi.c	Mon Nov 18 08:42:42 2002
+++ edited/scsi.c	Mon Nov 18 16:14:23 2002
@@ -2225,6 +2225,8 @@
 			printk(KERN_ERR "SCSI: can't init sg mempool %s\n", sgp->name);
 	}
 
+	scsi_init_procfs();
+	scsi_devfs_handle = devfs_mk_dir(NULL, "scsi", NULL);
 	scsi_host_init();
 	scsi_dev_info_list_init(scsi_dev_flags);
 	bus_register(&scsi_driverfs_bus_type);
@@ -2236,9 +2238,10 @@
 {
 	int i;
 
+	bus_unregister(&scsi_driverfs_bus_type);
+	scsi_dev_info_list_delete();
 	devfs_unregister(scsi_devfs_handle);
 	scsi_exit_procfs();
-	scsi_dev_info_list_delete();
 
 	for (i = 0; i < SG_MEMPOOL_NR; i++) {
 		struct scsi_host_sg_pool *sgp = scsi_sg_pools + i;

linux-2.4.18-modified-scsi-h.patch

[Andre Hedrick]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]


Greetings Doug et al.

Please consider the addition of this simple void ptr to the scsi_request
struct.  The addition of this simple void pointer allows one to map any
and all request execution caller the facility to search for a specific
operation without having to run in circles.  Hunting for these details
over the global device list of all HBA's is silly and one of the key
reasons why there error recovery path is so painful.


Scsi_Request    *req = sc_cmd->sc_request;
blah_blah_t     *trace = NULL;

trace = (blah_blah_t *)req->trace_ptr;


Therefore the specific transport invoking operations via the midlayer will
have the ablity to track and trace any operation.

It will save everyone headaches.

Cheers,


Andre Hedrick, CTO & Founder 
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

[-- Attachment #2: Type: text/plain, Size: 599 bytes --]

--- linux/drivers/scsi/scsi.h.orig	2002-10-31 01:45:39.000000000 -0800
+++ linux/drivers/scsi/scsi.h	2002-10-31 01:46:31.000000000 -0800
@@ -667,8 +667,11 @@
 	unsigned short sr_sglist_len;	/* size of malloc'd scatter-gather list */
 	unsigned sr_underflow;	/* Return error if less than
 				   this amount is transferred */
+	void *trace_ptr;	/* capable of cmd-cmnd-error tracing */
 };
 
+#define MODIFIED_SCSI_H
+
 /*
  * FIXME(eric) - one of the great regrets that I have is that I failed to define
  * these structure elements as something like sc_foo instead of foo.  This would

Re: linux-2.4.18-modified-scsi-h.patch

[Jeff Garzik]

Andre Hedrick wrote:

> Greetings Doug et al.
>
> Please consider the addition of this simple void ptr to the scsi_request
> struct.  The addition of this simple void pointer allows one to map any
> and all request execution caller the facility to search for a specific
> operation without having to run in circles.  Hunting for these details
> over the global device list of all HBA's is silly and one of the key
> reasons why there error recovery path is so painful.
>
>
> Scsi_Request    *req = sc_cmd->sc_request;
> blah_blah_t     *trace = NULL;
>
> trace = (blah_blah_t *)req->trace_ptr;
>
>
> Therefore the specific transport invoking operations via the midlayer will
> have the ablity to track and trace any operation.
>
> It will save everyone headaches.
>
> Cheers,
>
>
> Andre Hedrick, CTO & Founder
> iSCSI Software Solutions Provider
> http://www.PyXTechnologies.com/
>
>
> ------------------------------------------------------------------------
>
> --- linux/drivers/scsi/scsi.h.orig	2002-10-31 01:45:39.000000000 -0800
> +++ linux/drivers/scsi/scsi.h	2002-10-31 01:46:31.000000000 -0800
> @@ -667,8 +667,11 @@
>  	unsigned short sr_sglist_len;	/* size of malloc'd scatter-gather list */
>  	unsigned sr_underflow;	/* Return error if less than
>  				   this amount is transferred */
> +	void *trace_ptr;	/* capable of cmd-cmnd-error tracing */


ok


>  };
>
> +#define MODIFIED_SCSI_H


This falls into C style :)  Instead of this I would do

	#define HAVE_TRACE_PTR 1

just like we already do HAVE_xxx in include/linux/netdevice.h and other 
places.

	Jeff

Re: linux-2.4.18-modified-scsi-h.patch

[Andre Hedrick]

On Tue, 19 Nov 2002, Jeff Garzik wrote:

> Andre Hedrick wrote:
> 
> > Greetings Doug et al.
> >
> > Please consider the addition of this simple void ptr to the scsi_request
> > struct.  The addition of this simple void pointer allows one to map any
> > and all request execution caller the facility to search for a specific
> > operation without having to run in circles.  Hunting for these details
> > over the global device list of all HBA's is silly and one of the key
> > reasons why there error recovery path is so painful.
> >
> >
> > Scsi_Request    *req = sc_cmd->sc_request;
> > blah_blah_t     *trace = NULL;
> >
> > trace = (blah_blah_t *)req->trace_ptr;
> >
> >
> > Therefore the specific transport invoking operations via the midlayer will
> > have the ablity to track and trace any operation.
> >
> > It will save everyone headaches.
> >
> > Cheers,
> >
> >
> > Andre Hedrick, CTO & Founder
> > iSCSI Software Solutions Provider
> > http://www.PyXTechnologies.com/
> >
> >
> > ------------------------------------------------------------------------
> >
> > --- linux/drivers/scsi/scsi.h.orig	2002-10-31 01:45:39.000000000 -0800
> > +++ linux/drivers/scsi/scsi.h	2002-10-31 01:46:31.000000000 -0800
> > @@ -667,8 +667,11 @@
> >  	unsigned short sr_sglist_len;	/* size of malloc'd scatter-gather list */
> >  	unsigned sr_underflow;	/* Return error if less than
> >  				   this amount is transferred */
> > +	void *trace_ptr;	/* capable of cmd-cmnd-error tracing */
> 
> 
> ok
> 
> 
> >  };
> >
> > +#define MODIFIED_SCSI_H
> 
> 
> This falls into C style :)  Instead of this I would do
> 
> 	#define HAVE_TRACE_PTR 1
> 
> just like we already do HAVE_xxx in include/linux/netdevice.h and other 
> places.
> 
> 	Jeff

Works for me, just need to test the state of intelligence of the SCSI
stack and if it is possible to teach the old dog a new trick.  The ablitly
to logically seek an operation without chasing, the link list of devices
and outstanding commands, it tail!

Cheers,

Andre Hedrick, CTO & Founder 
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

Re: linux-2.4.18-modified-scsi-h.patch

[Douglas Gilbert]

Andre Hedrick wrote:
> Greetings Doug et al.
> 
> Please consider the addition of this simple void ptr to the scsi_request
> struct.  The addition of this simple void pointer allows one to map any
> and all request execution caller the facility to search for a specific
> operation without having to run in circles.  Hunting for these details
> over the global device list of all HBA's is silly and one of the key
> reasons why there error recovery path is so painful.
> 
> 
> Scsi_Request    *req = sc_cmd->sc_request;
> blah_blah_t     *trace = NULL;
> 
> trace = (blah_blah_t *)req->trace_ptr;
> 
> 
> Therefore the specific transport invoking operations via the midlayer will
> have the ablity to track and trace any operation.

Andre,
No need to convince me: I have already put a similar pointer
in that structure in lk 2.5 (for either sd, st, sr or sg to use).
In sg case's it saved some ugly looping in (what was formerly
called) the bottom half handler. Sounds like your motivation is
similar.

Doug Gilbert

Re: linux-2.4.18-modified-scsi-h.patch

[Andre Hedrick]

On Tue, 19 Nov 2002, Douglas Gilbert wrote:

> Andre Hedrick wrote:
> > Greetings Doug et al.
> > 
> > Please consider the addition of this simple void ptr to the scsi_request
> > struct.  The addition of this simple void pointer allows one to map any
> > and all request execution caller the facility to search for a specific
> > operation without having to run in circles.  Hunting for these details
> > over the global device list of all HBA's is silly and one of the key
> > reasons why there error recovery path is so painful.
> > 
> > 
> > Scsi_Request    *req = sc_cmd->sc_request;
> > blah_blah_t     *trace = NULL;
> > 
> > trace = (blah_blah_t *)req->trace_ptr;
> > 
> > 
> > Therefore the specific transport invoking operations via the midlayer will
> > have the ablity to track and trace any operation.
> 
> Andre,
> No need to convince me: I have already put a similar pointer
> in that structure in lk 2.5 (for either sd, st, sr or sg to use).
> In sg case's it saved some ugly looping in (what was formerly
> called) the bottom half handler. Sounds like your motivation is
> similar.
> 
> Doug Gilbert

Hey there!

Well it needs to be in all kernels regardless, and if it is in the
scsi_request it is transparent to any given personality device and the
caller may reserve the option to include other key information.  Simple
stats of what the queue depth of a given device is and a means to flush
out the commands to force a failure in the case of calling a device reset.

Without being to obvious or rude about the driver model being top down and
not the converse, hunting for given set of operation(s) will almost insure
a driver/device deadlock when racing against the done function.

I am pleased you and I are thinking in the same direction again!

Cheers,

Andre Hedrick, CTO & Founder 
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

Re: linux-2.4.18-modified-scsi-h.patch

[Patrick Mansfield]

On Tue, Nov 19, 2002 at 09:11:47PM +1100, Douglas Gilbert wrote:
> Andre Hedrick wrote:
> > Greetings Doug et al.
> > 
> > Please consider the addition of this simple void ptr to the scsi_request
> > struct.  The addition of this simple void pointer allows one to map any
> > and all request execution caller the facility to search for a specific
> > operation without having to run in circles.  Hunting for these details
> > over the global device list of all HBA's is silly and one of the key
> > reasons why there error recovery path is so painful.
> > 
> > 
> > Scsi_Request    *req = sc_cmd->sc_request;
> > blah_blah_t     *trace = NULL;
> > 
> > trace = (blah_blah_t *)req->trace_ptr;
> > 
> > 
> > Therefore the specific transport invoking operations via the midlayer will
> > have the ablity to track and trace any operation.
> 
> Andre,
> No need to convince me: I have already put a similar pointer
> in that structure in lk 2.5 (for either sd, st, sr or sg to use).
> In sg case's it saved some ugly looping in (what was formerly
> called) the bottom half handler. Sounds like your motivation is
> similar.
> 
> Doug Gilbert

So we should name it the same in 2.4 as in 2.5: upper_private_data, not
trace_ptr (thought it should really have been sr_upper_private_data,
like all the other fields in scsi_request).

I don't see why we need the #define, or is that another patch?

-- Patrick Mansfield

Re: linux-2.4.18-modified-scsi-h.patch

[Andre Hedrick]

On Tue, 19 Nov 2002, Patrick Mansfield wrote:

> On Tue, Nov 19, 2002 at 09:11:47PM +1100, Douglas Gilbert wrote:
> > Andre Hedrick wrote:
> > > Greetings Doug et al.
> > > 
> > > Please consider the addition of this simple void ptr to the scsi_request
> > > struct.  The addition of this simple void pointer allows one to map any
> > > and all request execution caller the facility to search for a specific
> > > operation without having to run in circles.  Hunting for these details
> > > over the global device list of all HBA's is silly and one of the key
> > > reasons why there error recovery path is so painful.
> > > 
> > > 
> > > Scsi_Request    *req = sc_cmd->sc_request;
> > > blah_blah_t     *trace = NULL;
> > > 
> > > trace = (blah_blah_t *)req->trace_ptr;
> > > 
> > > 
> > > Therefore the specific transport invoking operations via the midlayer will
> > > have the ablity to track and trace any operation.
> > 
> > Andre,
> > No need to convince me: I have already put a similar pointer
> > in that structure in lk 2.5 (for either sd, st, sr or sg to use).
> > In sg case's it saved some ugly looping in (what was formerly
> > called) the bottom half handler. Sounds like your motivation is
> > similar.
> > 
> > Doug Gilbert
> 
> So we should name it the same in 2.4 as in 2.5: upper_private_data, not
> trace_ptr (thought it should really have been sr_upper_private_data,
> like all the other fields in scsi_request).
> 
> I don't see why we need the #define, or is that another patch?

Hi Patrick,

The #define was as to determine or notify the driver at build time if it
had an enhanced capablity or legacy restrictions.  Obviously once it is
adopted regardless of form then a simple version check will work.

It was for testing purposes.


Cheers,

Andre Hedrick, CTO & Founder 
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/

Re: linux-2.4.18-modified-scsi-h.patch

[Jeff Garzik]

Patrick Mansfield wrote:

> I don't see why we need the #define, or is that another patch?



The define exists for the same reason that HAVE_xxx exists in 
include/linux/netdevice.h and other headers:  a feature test macro, so 
code using this pointer can detect its presence or absence.  The world 
of drivers is not all in the kernel tarball, ya know ;-)

But as I said, the macro is misnamed, it should be 
HAVE_UPPER_PRIVATE_DATA or similar.

	Jeff

Re: linux-2.4.18-modified-scsi-h.patch

[Andre Hedrick]

On Tue, 19 Nov 2002, Jeff Garzik wrote:

> Patrick Mansfield wrote:
> 
> > I don't see why we need the #define, or is that another patch?
> 
> 
> 
> The define exists for the same reason that HAVE_xxx exists in 
> include/linux/netdevice.h and other headers:  a feature test macro, so 
> code using this pointer can detect its presence or absence.  The world 
> of drivers is not all in the kernel tarball, ya know ;-)
> 
> But as I said, the macro is misnamed, it should be 
> HAVE_UPPER_PRIVATE_DATA or similar.
> 
> 	Jeff

Hey Jeff!

Works for me, has each HBA has the need to reserve local structs and not
pollute the basic kernel w/ bloat!

Cheers,

Andre Hedrick, CTO & Founder 
iSCSI Software Solutions Provider
http://www.PyXTechnologies.com/