[PATCH] allow NULL dev argument to scsi_add_host

[PATCH] allow NULL dev argument to scsi_add_host

[Christoph Hellwig]

We need scsi_add_host sometimes without having a struct device (i.e.
eisa/vlb drivers, ieee1394 storage), so handle that case gracefully.


--- 1.41/drivers/scsi/hosts.c	Mon Dec 16 10:59:41 2002
+++ edited/drivers/scsi/hosts.c	Sat Jan 11 19:06:56 2003
@@ -314,9 +314,10 @@
  **/
 int scsi_add_host(struct Scsi_Host *shost, struct device *dev)
 {
-	dev->class_data = shost;
-	shost->host_gendev = dev;
-
+	if (dev) {
+		dev->class_data = shost;
+		shost->host_gendev = dev;
+	}
 	return __scsi_add_host(shost);
 }
 

Re: [PATCH] allow NULL dev argument to scsi_add_host

[Willem Riede]

On 2003.01.11 14:33 Christoph Hellwig wrote:
> We need scsi_add_host sometimes without having a struct device (i.e.
> eisa/vlb drivers, ieee1394 storage), so handle that case gracefully.
> 
Hmmm, I created a token device for ide-scsi (idescsi_primary) because
that null case wasn't handled. Should I delete it again?

Thanks, Willem Riede.

Re: [PATCH] allow NULL dev argument to scsi_add_host

[Mike Anderson]

Christoph Hellwig [hch@lst.de] wrote:
> We need scsi_add_host sometimes without having a struct device (i.e.
> eisa/vlb drivers, ieee1394 storage), so handle that case gracefully.
> 
> 
> --- 1.41/drivers/scsi/hosts.c	Mon Dec 16 10:59:41 2002
> +++ edited/drivers/scsi/hosts.c	Sat Jan 11 19:06:56 2003
> @@ -314,9 +314,10 @@
>   **/
>  int scsi_add_host(struct Scsi_Host *shost, struct device *dev)
>  {
> -	dev->class_data = shost;
> -	shost->host_gendev = dev;
> -
> +	if (dev) {
> +		dev->class_data = shost;
> +		shost->host_gendev = dev;
> +	}
>  	return __scsi_add_host(shost);
>  }
>  

This will cause all scsi device registers to show up in the root of the sysfs
tree. The goal was that children of the adapter would be equal to the
my_devices member. I also thought that callers of this interface would
be converted to support sysfs.

If there are going to be many pseudo adapters that do not want to go
through the overhead of creating a sysfs bus entry like ide-scsi
then maybe I should work on a sysfs SCSI sub-system like block and if
dev is null it means you are pseudo and we would create an entry for
the adapter under (? /sysfs/scsi/pseudo ?). This could then be the value
we stuff in host_gendev. Though the sysfs entry would not be much use to
the caller, but useful for SCSI.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] allow NULL dev argument to scsi_add_host

[Christoph Hellwig]

On Sat, Jan 11, 2003 at 05:17:20PM -0800, Mike Anderson wrote:
> This will cause all scsi device registers to show up in the root of the sysfs
> tree. The goal was that children of the adapter would be equal to the
> my_devices member. I also thought that callers of this interface would
> be converted to support sysfs.

I want to use this interface in driver that I can't support to the
device model yet (i.e. due to lack of eisa/vlb hardware I can't add
ldm support to them, but we have common drivers).

> If there are going to be many pseudo adapters that do not want to go
> through the overhead of creating a sysfs bus entry like ide-scsi
> then maybe I should work on a sysfs SCSI sub-system like block and if
> dev is null it means you are pseudo and we would create an entry for
> the adapter under (? /sysfs/scsi/pseudo ?). This could then be the value
> we stuff in host_gendev. Though the sysfs entry would not be much use to
> the caller, but useful for SCSI.

I'm all for useful entries in sysfs, but what about doing that
implicitly in scsi_add_host when dev is null?  (and getting rid of the
separate __scsi_add_host)

Re: [PATCH] allow NULL dev argument to scsi_add_host

[Mike Anderson]

Christoph Hellwig [hch@lst.de] wrote:
> > If there are going to be many pseudo adapters that do not want to go
> > through the overhead of creating a sysfs bus entry like ide-scsi
> > then maybe I should work on a sysfs SCSI sub-system like block and if
> > dev is null it means you are pseudo and we would create an entry for
> > the adapter under (? /sysfs/scsi/pseudo ?). This could then be the value
> > we stuff in host_gendev. Though the sysfs entry would not be much use to
> > the caller, but useful for SCSI.
> 
> I'm all for useful entries in sysfs, but what about doing that
> implicitly in scsi_add_host when dev is null?  (and getting rid of the
> separate __scsi_add_host)

Yes, This is what I meant in the previous comment about create it on
the fly if dev is null and clean it up on the scsi_remove_host post call
to scsi_forget_host.

Currently we have a couple of issues that might be solved by the creation of a
scsi subsystem in /sysfs/scsi:

	1. Non converted scsi hosts that need an entry in sysfs.
	2. The creation of a sg(n) to scsi_device relationship.

I will start working on a RFC patch for addition of a scsi sub-system.
Prior to getting this done the scsi sysfs nodes will just be inconstant
for hopefully a short period.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: [PATCH] allow NULL dev argument to scsi_add_host

[Andries Brouwer]

On Sun, Jan 12, 2003 at 11:40:30AM -0800, Mike Anderson wrote:

> Currently we have a couple of issues that might be solved by the creation of a
> scsi subsystem in /sysfs/scsi:

Is /sysfs/scsi better than /sysfs/devices/scsiX?

Andries

Re: [PATCH] allow NULL dev argument to scsi_add_host

[Mike Anderson]

Andries Brouwer [aebr@win.tue.nl] wrote:
> On Sun, Jan 12, 2003 at 11:40:30AM -0800, Mike Anderson wrote:
> 
> > Currently we have a couple of issues that might be solved by the creation of a
> > scsi subsystem in /sysfs/scsi:
> 
> Is /sysfs/scsi better than /sysfs/devices/scsiX?

The choice was not better it was just a difference of semantics. The
/sysfs/devices tree normal contains devices with an associated bus
(though you can set this to NULL).  The device tree was meant to contain
real devices. The support I added to scsi_debug was to emulate a real
device so the overhead was needed to try to match the call paths of
other LLDD like some of the converted pci's. The addition of ide-scsi to
the device tree was that there was no other option.

I hoped to get a smaller object to represent the emulated scsi hosts or
hosts that had not been converted in a /sysfs/scsi subsystem. I also
thought we might need other sysfs entries related to the SCSI subsystem
(scsi logging control, sg mapping solution, scsiX host mapping "The
scsi-host class I created sucks right now"). 

-andmike
--
Michael Anderson
andmike@us.ibm.com