On Wed, 14 May 2008, Chris Lalancette wrote:
> Ug. Yeah, that will do it. What kernel version are you running that your sysfs
> looks like that?
I already send a message to open-iscsi group. Fix is trivial and even more
simple. I'm running 2.6.21-xen (gentoo) with open-iscsi-2.0.869.2.
Fix:
snprintf(sysfs_path, PATH_MAX,
"/sys/class/iscsi_session/session%s/device/"
"target%d:%d:%d/%d:%d:%d:%d",
session, target, channel, id, target, channel, id, lun);
(so remove /block)
/* OK, not . or ..; let's see if it is a SCSI device */
if (len > 8 &&
block_dirent->d_name[0] == 'b' &&
block_dirent->d_name[1] == 'l' &&
block_dirent->d_name[2] == 'o' &&
block_dirent->d_name[3] == 'c' &&
block_dirent->d_name[4] == 'k' &&
block_dirent->d_name[5] == ':' &&
block_dirent->d_name[6] == 's' &&
block_dirent->d_name[7] == 'd') {
/* looks like a scsi device, smells like scsi device; it must be
a scsi device */
dev = (char *) calloc(sizeof(char), len - 5);
strncpy(dev, &(block_dirent->d_name[6]), (len - 6));
I guess that can be come a strncmp. And for sake of memory management an
if (dev != NULL) would be good too.
> It seems we have been shoved into a corner; we can't rely on the output of the
> iscsiadm tools, since we have already seen those change between versions. And
> apparently we can't rely on sysfs paths to stay stable either. Either we need
> some iscsiadm command with a known, stable output that we can call, or we need
> some sort of iSCSI API that we can call to get this information. Either way, I
> think we need help from the iSCSI people, because the current position seem to
> be untenable.
I would love to see something like a iSCSI API. The parsing looks really
cute, but as you say it is so unreliable.
Next to this:
/* the 0'th LUN isn't a real LUN, it's just a control LUN; skip it */
I think this is also a very strange idea of LUNs.
Stefan
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list