Hi all,
Adding firewire (sbp) support to rtslib-fb has led me to look more
closely at them, and I'm not sure their complexity is justified by their
functionality.
First, they are in a config file format instead of native Python. This
limits their flexibility to such a degree that certain sections
requiring flexibility are defined to contain shell command snippets.
Wouldn't it be preferable to convert wwns to a canonical format in
Python, rather than shelling out to use sed?
sbp support cannot now be added simply by adding a spec -- Python
changes are needed.
Second, they are not located with the rest of the rtslib code, and are
loaded at runtime. This does seem somewhat nice in that support for
fabrics can be added or removed without modifying the rtslib Python
code, at least theoretically. But, is this flexibility needed? Aren't
.specs always bundled with rtslib? When would a user be expected to
write a new one? Wouldn't it be ok to require an updated rtslib to use a
new fabric?
My current opinion is that the flexibility issue be remedied by changing
each to be a Python module, but keep them as separate files and in
spec_dir for now.
Here's an example of a converted ib_srpt.spec:
# The fabric module feature set
features = ("acls",)
# Non-standard module naming scheme
kernel_module = "ib_srpt"
# wwns() generates valid wwns.
def wwns():
import glob
for wwn_file in glob.iglob("/sys/class/infiniband/*/ports/*/gids/0"):
yield "0x" + fread(wwn_file).strip(":")
# The configfs group
configfs_group = "srpt"
Not *too* different, but this would be flexible enough to handle
special-case fabrics like sbp, and also be likely to end up as less code
in rtslib/target.py.
Any comments or thoughts?
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
