SG_GET_ACCESS_COUNT ioctl problem

SG_GET_ACCESS_COUNT ioctl problem

[Mark Hounschell]

In the 2.4 kernel (not using devfs) the SG_GET_ACCESS_COUNT ioctl to an
sg device would report the correct/expected usage count when issued to a
sd disc that was mounted, accounting for the mount by the system. The
2.6 kernel does not. Is this now the expected behavior or is this a bug?

Mark

SG_GET_ACCESS_COUNT ioctl problem

[Mark Hounschell]

In the 2.4 kernel (not using devfs) the SG_GET_ACCESS_COUNT ioctl to an
sg device would report the correct/expected usage count when issued to a
sd disc that was mounted, accounting for the mount by the system. The
2.6 kernel does not. Is this now the expected behavior or is this a bug?

Mark

Re: SG_GET_ACCESS_COUNT ioctl problem

[Douglas Gilbert]

Mark Hounschell wrote:
> In the 2.4 kernel (not using devfs) the SG_GET_ACCESS_COUNT ioctl to an
> sg device would report the correct/expected usage count when issued to a
> sd disc that was mounted, accounting for the mount by the system. The
> 2.6 kernel does not. Is this now the expected behavior or is this a bug?

Mark,
I think you can consider that ioctl deprecated in the
lk 2.6 series. The implementation of that ioctl in
lk 2.6.15 is not very encouraging:

    case SG_GET_ACCESS_COUNT:
        /* faked - we don't have a real access count anymore */
        val = (sdp->device ? 1 : 0);
        return put_user(val, ip);

which will yield 1 in almost all cases. In the lk 2.6 series
sysfs ** is meant to take over those sort of functions from
the sg driver. However struct scsi_device (one instance per
scsi device (normally a logical unit)) no longer seems to
maintain an access count.


I have written about the SG_IO ioctl and its various
implementations in the lk 2.6 series at:
http://www.torque.net/sg/sg_io.html

However I haven't addressed the status of the lesser used
sg ioctls (e.g. SG_GET_ACCESS_COUNT) in the lk 2.6 series.


** ..._GET_ACCESS_COUNT is more of a job for procfs than
   sysfs.

Doug Gilbert

Re: SG_GET_ACCESS_COUNT ioctl problem

[Mark Hounschell]

> Mark,
> I think you can consider that ioctl deprecated in the
> lk 2.6 series. The implementation of that ioctl in
> lk 2.6.15 is not very encouraging:
> 
>     case SG_GET_ACCESS_COUNT:
>         /* faked - we don't have a real access count anymore */
>         val = (sdp->device ? 1 : 0);
>         return put_user(val, ip);
> 
> which will yield 1 in almost all cases. In the lk 2.6 series
> sysfs ** is meant to take over those sort of functions from
> the sg driver. However struct scsi_device (one instance per
> scsi device (normally a logical unit)) no longer seems to
> maintain an access count.
> 
> 
> I have written about the SG_IO ioctl and its various
> implementations in the lk 2.6 series at:
> http://www.torque.net/sg/sg_io.html
> 
> However I haven't addressed the status of the lesser used
> sg ioctls (e.g. SG_GET_ACCESS_COUNT) in the lk 2.6 series.
> 
> 
> ** ..._GET_ACCESS_COUNT is more of a job for procfs than
>    sysfs.
> 

So how can one safely open an sg device that happens to be a disk? I can
find no combination of open flags that will cause an open to fail if the
disk happens to be mounted? You imply this ioctl is a "lesser used"
ioctl? What 'was' the prefered method of doing this? It's the only
method I found short of writing code to xlate the sg device into an sd
device and attempting an open of that first. That's not good???

Thanks
Mark

Re: SG_GET_ACCESS_COUNT ioctl problem

[Douglas Gilbert]

Mark Hounschell wrote:
>>Mark,
>>I think you can consider that ioctl deprecated in the
>>lk 2.6 series. The implementation of that ioctl in
>>lk 2.6.15 is not very encouraging:
>>
>>    case SG_GET_ACCESS_COUNT:
>>        /* faked - we don't have a real access count anymore */
>>        val = (sdp->device ? 1 : 0);
>>        return put_user(val, ip);
>>
>>which will yield 1 in almost all cases. In the lk 2.6 series
>>sysfs ** is meant to take over those sort of functions from
>>the sg driver. However struct scsi_device (one instance per
>>scsi device (normally a logical unit)) no longer seems to
>>maintain an access count.
>>
>>
>>I have written about the SG_IO ioctl and its various
>>implementations in the lk 2.6 series at:
>>http://www.torque.net/sg/sg_io.html
>>
>>However I haven't addressed the status of the lesser used
>>sg ioctls (e.g. SG_GET_ACCESS_COUNT) in the lk 2.6 series.
>>
>>
>>** ..._GET_ACCESS_COUNT is more of a job for procfs than
>>   sysfs.
>>
> 
> 
> So how can one safely open an sg device that happens to be a disk? I can
> find no combination of open flags that will cause an open to fail if the
> disk happens to be mounted? You imply this ioctl is a "lesser used"
> ioctl? What 'was' the prefered method of doing this? It's the only
> method I found short of writing code to xlate the sg device into an sd
> device and attempting an open of that first. That's not good???

Mark,
In the lk 2.6 series you can open a disk directly
(e.g. /dev/sda) and send it SCSI commands using the
SG_IO ioctl. The situation is the same if you open
the corresponding sg device and send SCSI commands.

What is important is which SCSI commands are sent. There
is some crude filtering based on file permissions and
the SCSI command opcode. Other than that, the onus is
on the person sending the SCSI commands. Mounted file
systems can be seen in /proc/mounts ** .

The sg driver is a pass through. The SG_GET_ACCESS_COUNT
ioctl was a window to a variable which someone else removed
around 18 months ago. There is little I can do other
than try to explain ...


** the root file system device appears as "/dev/root"
   in my /proc/mounts . "/dev/root" is a symlink to
   the real thing.

Doug Gilbert

Re: SG_GET_ACCESS_COUNT ioctl problem

[Mark Hounschell]

Douglas Gilbert wrote:

> Mark,
> In the lk 2.6 series you can open a disk directly
> (e.g. /dev/sda) and send it SCSI commands using the
> SG_IO ioctl. The situation is the same if you open
> the corresponding sg device and send SCSI commands.
> 
> What is important is which SCSI commands are sent. There
> is some crude filtering based on file permissions and
> the SCSI command opcode. Other than that, the onus is
> on the person sending the SCSI commands. Mounted file
> systems can be seen in /proc/mounts ** .
> 
> The sg driver is a pass through. The SG_GET_ACCESS_COUNT
> ioctl was a window to a variable which someone else removed
> around 18 months ago. There is little I can do other
> than try to explain ...
> 

Understood and thanks for the info. I know about being having a limited
set of CDB opcodes available for the sd devices however it is much to
limited for me. It just doesn't make sense to me that the "window to the
variable" was closed without offerring a simple alternative.

An application that has been in use for years using a documented and
supported API now eats my root device if I run it???? I think sombody
wasn't thinking too clearly or took an easy way out to a problem they
didn't care to address.

Thanks again
Mark