Vladislav Bolkhovitin wrote:
Daniel Debonzi, on 04/16/2009 10:23 PM wrote:
Vladislav Bolkhovitin wrote:
Hi All,
Below is proposal for the SCST sysfs layout, which will replace
existing procfs-based infrastructure. Any comments, questions and
suggestions are welcome!
I. SCST sysfs layout.
Root would be /sys/scsi_tgt.
In the root there would be the following files and subdirectories:
- targets - subdirectory listing names of all registered target
drivers.
- devices - subdirectory listing all registered backend devices.
- sgv - subdirectory listing all existing SGV pools.
- drivers - subdirectory listing all loaded target and backend
drivers (dev handlers).
- threads - RW file listing number of global SCST threads. Writing
to that file would allow to change that value.
- trace_level - RW file listing SCST core logging level. Writing to
that file would allow to change that. Example content: "out_of_mem |
minor | pid | line | function | special | mgmt | mgmt_minor |
mgmt_dbg | retry". See current procfs implementation of this file for
more info.
- version - RO file listing version of SCST core and enabled compile
time features. Example content: "1.0.2, EXTRACHECKS,
DEBUG"
Based on all I read this last days, I believe we are not allowed to
include the directory scsi_tgt on /sys root. I think it has to be in a
existent directory reserved for this sort of application. I just
didn't figured out which one it would be.
/sys/class? It already has scsi_device, scsi_disk, scsi_generic and
scsi_host.
I don't think so because all the directories on /sys/class have symlinks
to the files somewhere else. However I noticed that many of them on my
system are on /sys/device/virtual
III. Implementation considerations
1. Top level subdirectories and files should be created by init_scst().
2. targets/target_driver_name drivers/target_driver_name and should
be created by scst_register_target_template() and removed by
scst_unregister_target_template().
3. targets/target_driver_name/target with sessions, luns and
ini_groups subdirectories should be created by scst_register() and
removed by scst_unregister().
4. targets/target_driver_name/target/sessions/session and below
should be created by scst_init_session() and removed by
scst_free_session().
5. Pass-through devices should be added to devices/ by
scst_register_device() and removed by scst_unregister_device().
Initially they should have "handler" link pointed to "none".
6. Virtual devices should be added to devices/ by
scst_register_virtual_device() and removed by
scst_unregister_virtual_device().
7. drivers/dev_handler_name should be added by
scst_register_dev_driver() or scst_register_virtual_dev_driver() and
removed by scst_unregister_dev_driver() or
scst_unregister_virtual_dev_driver().
8. It isn't clear how to best combine standard and custom entries in
targets/target_driver_name/target, devices/device,
drivers/target_driver_name and drivers/dev_handler_name, I don't know
sysfs interfaces sufficiently well. I can only suggest places, where
it should be done:
- For targets/target_driver_name/target a target driver after
scst_register() register call should call new function
scst_get_target_root() and add there new entries. Before
scst_unregister() call the target driver should remove them at first.
Similarly it should be done for drivers/target_driver_name and
drivers/dev_handler_name.
- For devices/device a dev handler should do it in attach() callback
and remove in detach() callback. Similarly to scst_get_target_root(),
the dev handler should get its sysfs root by calling
scst_get_dev_root().
Both should be made in some generic way to minimize duplicated code
between target drivers and between dev handlers.
Also based on what I read, the way to have data structures reflected
on sysfs is using kobjecs. I feel that the expected approach to have
it is to include a kobject (or kset depending on the case) on the
existent structures which will be reflected on the sysfs. I notice
that on the actual implementation all the proc interface is
implemented on scst_proc.c and I don't know if it will be possible to
keep having the access interfaces on a separated source file. We could
possible have the callback functions on a separated file but I can't
visualize it without start to touch it more deeply. Probably you guys
have a better view of this implementation possibilities.
All the above sysfs layout reflects internal SCST objects:
1. targets/target_driver_name and drivers/target_driver_name -> struct
scst_tgt_template
2. targets/target_driver_name/target -> struct scst_tgt
3. targets/target_driver_name/target/sessions/session -> struct
scst_session
4. targets/target_driver_name/target/ini_groups/group -> struct
scst_acg. (For targets/target_driver_name/target/luns each struct
scst_tgt would have internal struct scst_acg.)
5.
targets/target_driver_name/target/ini_groups/group/initiators/initiator
-> struct scst_acn
6. targets/target_driver_name/target/ini_groups/group/luns/lun and
targets/target_driver_name/target/luns/lun -> struct scst_acg_dev
7. devices/device -> struct scst_device
8. drivers/dev_handler_name -> struct scst_dev_type
9. sgv/pool -> struct sgv_pool
So, we should simply add kobjects in them. To manipulate with then
already there is an API, used by procfs, and should be also used by
sysfs. This API is completely out of scst_proc.c
great, this will save some time.
LAYOUT UPDATE.
Looks like it would be better to move entries from
drivers/target_driver_name to targets/target_driver_name to keep all the
related entries in one place. Then to reflect new state rename drivers/
to back_drivers/.
Ack.
Thanks,
Daniel Debonzi
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
