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

Mike Anderson

author

2003-04-14 18:37 UTC #0 lore raw

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
[email protected]

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Patrick Mochel

2003-04-14 23:02 UTC #1 lore raw

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

No. Period.

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

Quoted 6 lines

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

Quoted 6 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Mike Anderson

author

2003-04-14 23:47 UTC #2 lore raw

In reply to Mike Anderson

Quoted 4 lines · Patrick Mochel [[email protected]] 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.

Quoted 4 lines

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.

Quoted 3 lines

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
[email protected]

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Patrick Mochel

2003-04-14 23:48 UTC #3 lore raw

In reply to Mike Anderson

Quoted 9 lines · Mike Anderson

Quoted 4 lines · Patrick Mochel [[email protected]] 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.

Quoted 7 lines

Quoted 4 lines
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/

Quoted 5 lines

Quoted 3 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Mike Anderson

author

2003-04-15 00:25 UTC #4 lore raw

In reply to Mike Anderson

Quoted 6 lines · Patrick Mochel [[email protected]] wrote:

Quoted 3 lines
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.

Quoted 4 lines

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
[email protected]

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel