You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A recent kernel change made one of the attributes that targetcli cares about write-only, causing saveconfig to fale if there were any targets. This came about because of linux kernel commit:
6baca7601bde ("scsi: target: drop unused pi_prot_format attribute storage")
This commit was quickly fixed with another commit:
b6cd7f34ba135 ("scsi: target: make the pi_prot_format ConfigFS path readable")
but it pointed out that possibility of write-only sysfs attributes.
Because of this rtslib-fb was updated with 3 new commits to address this possibility:
6f17cf775ca9 Add 'readable' param to Group list_*() methods
ee005008acfe Handle write-only parameters like attributes
03c8c15983a2 Handle write-only attributes.
My question for you all is: Should we updated targetcli-fb to use this functionality?
There are several places in configshell-fb and targetcli-fb where it is just assumed that all attributes can be read, even if read-only. Looking at the code, it seems like it would take a bit of effort in both packages to handle this generic aberration, i.e. write-only attributes.
So does anyone think this is worth the effort of changing right now, considering the scarcity of such write-only attributes in the wild? It would be nice to know, since I'm a bit too busy to work on something that's not a real problem, even if interesting.
The text was updated successfully, but these errors were encountered:
A recent kernel change made one of the attributes that targetcli cares about write-only, causing saveconfig to fale if there were any targets. This came about because of linux kernel commit:
This commit was quickly fixed with another commit:
but it pointed out that possibility of write-only sysfs attributes.
Because of this rtslib-fb was updated with 3 new commits to address this possibility:
My question for you all is: Should we updated targetcli-fb to use this functionality?
There are several places in configshell-fb and targetcli-fb where it is just assumed that all attributes can be read, even if read-only. Looking at the code, it seems like it would take a bit of effort in both packages to handle this generic aberration, i.e. write-only attributes.
So does anyone think this is worth the effort of changing right now, considering the scarcity of such write-only attributes in the wild? It would be nice to know, since I'm a bit too busy to work on something that's not a real problem, even if interesting.
The text was updated successfully, but these errors were encountered: