Description of problem:

sg_map26 maps incorrectly tape drives with number >= 32

Version-Release number of selected component (if applicable):

All versions - the bug was present even in the latest upstream version, I contacted an upstream developer and he has provided a fix

How reproducible:


Steps to Reproduce:

1. 
(if you do not have a real host with > 32 tape drives)

# mknod /dev/nst32 c 9 384
# ls -l /dev/nst*
 crw-r--r-- 1 root root 9, 128 2008-10-08 09:42 /dev/nst0
 crw-r--r-- 1 root root 9, 384 2008-10-08 09:38 /dev/nst32

2. 
# sg_map26  -r 3 /dev/nst0
# /sys/class/scsi_tape/st0
# sg_map26  -r 3 /dev/nst32
 /sys/class/scsi_tape/st0
  
Actual results:

nst32 is mapped to st0

Expected results:

it should be mapped to st32

Analysis
========

2.6 kernels scatter the tape number between two bit ranges, the minor numbers
consist of the following bit fields:

dev_upper non-rew mode dev-lower
 20 -  8     7    6 5  4      0

So /dev/nst0-nst31 have minor 128-159, but /dev/nst32 will start using bits
20-8 and its minor will be 128+256=384

In sg_map26.c the tape drive minor is decoded incorrectly, by stripping all 
high bits using the mask 0x1f:

sg_map26.c:

map_st(...) {
  <snip>
        snprintf(name, sizeof(name), "%sst%d", sys_st_dir,
                 (mi & 0x1f));

which leaves only 5 bits. As a result sprintf will produce

    /sys/class/scsi_tape/nst0

_both_ for nst0 and nst32. After that we'll output nst0 instead of nst32.

The fix
=======

I have contacted the maintainer of sg3_utils (Douglas Gilbert) and he has provided a fix.

To decode the minor properly, we now use TAPE_NR(minor) macro, similar to 
what 'st' command does (this macro was copied from kernel sources).

Please find a diff and the fixed sg_map26.c attached, as received from Douglas. The fix has been tested on a real system with > 32 tape drives