[RFC] scsi host sysfs support [0/4]

[RFC] scsi host sysfs support [0/4]

[Mike Anderson]

This patch set is against 2.5.67 current. It will not apply to scsi-miscs-2.5
as the decl_subsys macro has added a third argument.

This patch set changes the sysfs support for scsi hosts.
- Removes the previous support of shost_devclass device class.

- Modifies scsi_debug to support the new order of object cleanup and also
  changes the structure of sdebug_host_info to help in object cleanup.

- Creates a scsi subsystem. This is rooted at the top of the sysfs tree.

- Creates a scsi_host subsystem under the scsi subsystem. Modified the
  cleanup in scsi remove host. Switched to a kobject embedded in
  scsi_host. If a driver has not be converted to the driver model or does
  not use the scsi_set_device call it will still show up in the scsi_host
  subsystem, but will not have a symlink to the parent.

The usage of driver model classes for scsi hosts was removed because many
of our drivers have not been converted to the driver model so this gave an
inconsistent model to count on for cleanup and migration of some the
procfs support. I tried adding some fake structures to use classes, but it
failed to cleanup properly do to asymmetric cleanup interfaces in the core
code and also did not seem like the correct direction to go.

This change allows for host cleanup when sysfs references drop to zero
(there still needs be work done on scsi mid get / put calls).

I have tested the insmod / rmmod cycle with scsi_debug and booted with the
ips and aic drivers.

Current Known Issues:
	- Current users of scsi_remove_host will need to have there
	  cleanup reordered to support the restoration of the call to the
	  Scsi_Host_Template release.
	- Callers of scsi_set_device should be migrated off this interface
	  if possible.
	- Need better name for symlink than adapter.
	
Example tree:

[root@elm3a49 sys]# tree -d scsi
scsi
`-- scsi_host
    |-- host0
    |   |-- 0:0:0:0
    |   |   |-- 0:0:0:0:gen
    |   |   `-- block -> ../../../../block/sda
    |   |-- 0:0:15:0
    |   |   `-- 0:0:15:0:gen
    |   |-- 0:0:1:0
    |   |   |-- 0:0:1:0:gen
    |   |   `-- block -> ../../../../block/sdb
    |   |-- 0:1:15:0
    |   |   `-- 0:1:15:0:gen
    |   `-- adapter -> ../../../devices/pci0/00:09.0
    |-- host1
    |   `-- adapter -> ../../../devices/pci1/01:03.0
    |-- host3
    |   |-- 3:0:0:0
    |   |   |-- 3:0:0:0:gen
    |   |   `-- block -> ../../../../block/sdc
    |   `-- adapter -> ../../../devices/pseudo_0/adapter0
    `-- host4
        |-- 4:0:0:0
        |   |-- 4:0:0:0:gen
        |   `-- block -> ../../../../block/sdd
        |-- 4:0:4:0
        |   |-- 4:0:4:0:gen
        |   |-- 4:0:4:0:mt
        |   |-- 4:0:4:0:mta
        |   |-- 4:0:4:0:mtan
        |   |-- 4:0:4:0:mtl
        |   |-- 4:0:4:0:mtln
        |   |-- 4:0:4:0:mtm
        |   |-- 4:0:4:0:mtmn
        |   `-- 4:0:4:0:mtn
        |-- 4:0:5:0
        |   |-- 4:0:5:0:gen
        |   `-- block -> ../../../../block/sr0
        `-- adapter -> ../../../devices/pci1/01:03.1

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] scsi host sysfs support [0/4]

[Patrick Mochel]

On Mon, 14 Apr 2003, Mike Anderson wrote:

> This patch set is against 2.5.67 current. It will not apply to scsi-miscs-2.5
> as the decl_subsys macro has added a third argument.
> 
> This patch set changes the sysfs support for scsi hosts.
> - Removes the previous support of shost_devclass device class.
> 
> - Modifies scsi_debug to support the new order of object cleanup and also
>   changes the structure of sdebug_host_info to help in object cleanup.
> 
> - Creates a scsi subsystem. This is rooted at the top of the sysfs tree.

No. Period. 

This will not fly. Not now, and not ever. 

> - Creates a scsi_host subsystem under the scsi subsystem. Modified the
>   cleanup in scsi remove host. Switched to a kobject embedded in
>   scsi_host. If a driver has not be converted to the driver model or does
>   not use the scsi_set_device call it will still show up in the scsi_host
>   subsystem, but will not have a symlink to the parent.
> 
> The usage of driver model classes for scsi hosts was removed because many
> of our drivers have not been converted to the driver model so this gave an
> inconsistent model to count on for cleanup and migration of some the
> procfs support. I tried adding some fake structures to use classes, but it
> failed to cleanup properly do to asymmetric cleanup interfaces in the core
> code and also did not seem like the correct direction to go.


Then you need to fix the code, or do some work to fix up the class 
support. You have no right to promote scsi to a top-level subsystem, and I 
will not support. I'll not even read the rest of the patches. 

I realize that block and net are top-level subsystems. They are there for 
two reasons - 1) they _are_ that important, and 2) they're temporary steps 
to them being converted to classes. 

I realize that you think SCSI is just as important as block devices or net 
devices, but it's just not true for most systems, and I will not open the 
flood gates for you to abuse even more interfaces.

Thanks,


	-pat



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] scsi host sysfs support [0/4]

[Mike Anderson]

Patrick Mochel [mochel@osdl.org] wrote:
> Then you need to fix the code, or do some work to fix up the class 
> support. You have no right to promote scsi to a top-level subsystem, and I 
> will not support. I'll not even read the rest of the patches. 
> 

To fix the LLDDs would force drivers that have a parent bus not converted
to the driver model to take on a excessive amount of code to show up as a
class (properly).

I also believed the "pseudo" driver I had to create to use classes was a
abuse of the interface. I will look into the changes happening with
classes.

> I realize that block and net are top-level subsystems. They are there for 
> two reasons - 1) they _are_ that important, and 2) they're temporary steps 
> to them being converted to classes. 
> 

Where are the attributes written down for evaluating important vs not
important subsystems.

> I realize that you think SCSI is just as important as block devices or net 
> devices, but it's just not true for most systems, and I will not open the 
> flood gates for you to abuse even more interfaces.

What interfaces am I abusing. I have used api's documented by you.

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] scsi host sysfs support [0/4]

[Patrick Mochel]

On Mon, 14 Apr 2003, Mike Anderson wrote:

> Patrick Mochel [mochel@osdl.org] wrote:
> > Then you need to fix the code, or do some work to fix up the class 
> > support. You have no right to promote scsi to a top-level subsystem, and I 
> > will not support. I'll not even read the rest of the patches. 
> > 
> 
> To fix the LLDDs would force drivers that have a parent bus not converted
> to the driver model to take on a excessive amount of code to show up as a
> class (properly).

Then convert them to the driver model. 

> > I realize that block and net are top-level subsystems. They are there for 
> > two reasons - 1) they _are_ that important, and 2) they're temporary steps 
> > to them being converted to classes. 
> > 
> 
> Where are the attributes written down for evaluating important vs not
> important subsystems.

They're not - they're completely subjective, and I reserve the right to 
reserve that right. Basically, only subsystems that are always present 
should be in the top-level directory. 

Sure, networking may not always be present, but that case is rare, and as 
I said before, it's on its way to becoming a device class. 

But, taking a step back, is SCSI a bus type? Yes, then it should go under 
bus/scsi/. You can implement an object under there, just as you would 
under scsi/ 

> > I realize that you think SCSI is just as important as block devices or net 
> > devices, but it's just not true for most systems, and I will not open the 
> > flood gates for you to abuse even more interfaces.
> 
> What interfaces am I abusing. I have used api's documented by you.

Hopefully none ATM, though that doesn't count the code I've seen in the 
past.


	-pat



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [RFC] scsi host sysfs support [0/4]

[Mike Anderson]

Patrick Mochel [mochel@osdl.org] wrote:
> > To fix the LLDDs would force drivers that have a parent bus not converted
> > to the driver model to take on a excessive amount of code to show up as a
> > class (properly).
> 
> Then convert them to the driver model. 
> 

In past evaluations this looked like a large task, and was not a
requirement for getting the ref counting / release capabilities we
needed. Even though you did not like where the kobject was rooted the
parent / child and release functionality appears to be working.

> But, taking a step back, is SCSI a bus type? Yes, then it should go under 
> bus/scsi/. You can implement an object under there, just as you would 
> under scsi/ 
> 

Ok I could root scsi_host under /bus/scsi. 

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel