2.5.48 /proc/scsi directory missing

DISCUSSION Douglas Gilbert 4 participants 11 messages Nov 18, 2002 – Nov 19, 2002 SCSI

Share & tools

Douglas Gilbert

author

2002-11-18 23:45 UTC #0 lore raw

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

Patrick Mansfield

2002-11-19 01:14 UTC #1 lore raw

Quoted 6 lines · 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

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.

scsi.c renamed from drivers/scsi/scsi.c +4 -1

@@ -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;

Andre Hedrick

2002-11-19 06:13 UTC #2 lore raw

linux-2.4.18-modified-scsi-h.patch

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/

drivers/scsi/scsi.h renamed from drivers/scsi/scsi.h.orig +3 -0

@@ -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

Jeff Garzik

2002-11-19 06:22 UTC #3 lore raw

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

Quoted 34 lines · Andre Hedrick

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/
------------------------------------------------------------------------

drivers/scsi/scsi.h line 670

Quoted 4 lines

drivers/scsi/scsi.h renamed from drivers/scsi/scsi.h.orig +1 -0

@@ -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 */

drivers/scsi/scsi.h line 673

Quoted 3 lines

drivers/scsi/scsi.h renamed from drivers/scsi/scsi.h.orig +1 -0
 };
 
+#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

Andre Hedrick

2002-11-19 06:40 UTC #4 lore raw

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

Quoted 50 lines · Jeff Garzik

Quoted 34 lines · Andre Hedrick
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/
------------------------------------------------------------------------
drivers/scsi/scsi.h line 670
Quoted 4 lines
drivers/scsi/scsi.h renamed from drivers/scsi/scsi.h.orig +1 -0
@@ -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
drivers/scsi/scsi.h line 673
Quoted 3 lines
drivers/scsi/scsi.h renamed from drivers/scsi/scsi.h.orig +1 -0
 };
 
+#define MODIFIED_SCSI_H

Quoted 8 lines

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/

Douglas Gilbert

author

2002-11-19 10:06 UTC #5 lore raw

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

In reply to Andre Hedrick

Quoted 10 lines · Andre Hedrick

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.

Quoted 8 lines

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

Andre Hedrick

2002-11-19 12:09 UTC #6 lore raw

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

Quoted 20 lines · Douglas Gilbert

Quoted 10 lines · Andre Hedrick
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.
Quoted 8 lines
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.

Quoted 8 lines

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/

Patrick Mansfield

2002-11-19 18:34 UTC #7 lore raw

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

In reply to Douglas Gilbert

Quoted 20 lines · Douglas Gilbert

Quoted 10 lines · Andre Hedrick
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.
Quoted 8 lines
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.

Quoted 8 lines

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

Andre Hedrick

2002-11-19 18:48 UTC #8 lore raw

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

Quoted 28 lines · Patrick Mansfield

Quoted 27 lines · Douglas Gilbert
Quoted 10 lines · Andre Hedrick
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.
Quoted 8 lines
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.

Quoted 7 lines

Quoted 1 line
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/

Jeff Garzik

2002-11-19 18:42 UTC #9 lore raw

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

In reply to Andre Hedrick

Quoted 1 line · Patrick Mansfield

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

Andre Hedrick

2002-11-19 18:46 UTC #10 lore raw

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

Quoted 11 lines · Jeff Garzik

Quoted 1 line · Patrick Mansfield
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 ;-)

Quoted 4 lines

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/