On Wed, May 14, 2008 at 03:19:58PM +0200, Chris Lalancette wrote:
Stefan de Konink wrote:
> 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.
Yes, except the problem with your patch is that it will probably break the
kernel I made the fixes for originally, which was either 2.6.23 or 2.6.24 (and
which had the /sys/class/iscsi_session/session9/device/target9:0:0:0/
9:0:0:0/block/sdd type paths). We may be able to come up with a hybrid solution
that will work on both cases, though.
Before I ACK any patches to the iSCSI driver to deal with other kernel
versions I want a documentation patch describing the exact sysfs trees
we need to deal with for the particular kernel variants the future code
patch is intended to support. This is the only way we stand a chance of
being able to maintain this long term.
Dan.
--
|: Red Hat, Engineering, Boston -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|