Re: Question on /proc API & bug in sysctl

Michael Neuffer (neuffer@goofy.zdv.uni-mainz.de)
Sat, 23 Mar 1996 17:33:45 +0100 (MET)


On Fri, 22 Mar 1996 eranian@chorus.fr wrote:

> While looking at the code of the sysctl in /proc I found several
> problems. The interface provided is buggy. By this I mean that it
> does not respect the interface for file access. There should be
> no difference between accessing a normal file in an ext2 filesystem
> (for instance) and a file in /proc.
>
> To show the bug, just try to do a simple dd in /proc/sys/kernel/ostype
> (for instance):
> dd if=/proc/sys/kernel/ostype of=/dev/tty bs=1 skip=3
>
> You will see that whatever skip you provide you will always get
> the string from the beginning. THIS IS NOT CORRECT AND DOES NOT
> RESPECT THE INTERFACE.
>
> I know this a kind of details but you may come to a problem when
> new BIG entries will be added to this directory aalong with
> companion program to display contents.

The reason for this behaviour is that most /proc entries do NOT support
lseek().

I implemented lseek() for /proc/scsi but the implementation has a
problem:

Since the data is beeing generated on the fly, it is not
known how long the generated file will be.
For this reason lseek has to read the complete file to find out it's
length if a lseek(fd, offset, SEEK_END) is requested. This causes a
race condition: If the length of the file changes in the time between the
point where the file length has been determined and the the application
does the read() it is quite possible that you won't get the data back as
you expected it. (The data might be shifted by a number of bytes)

That's why all drivers in /proc/scsi/<driver> have to return fixed length
fields.

Mike

Michael Neuffer i-Connect.Net, a Division of iConnect Corp.
mike@i-Connect.Net 13455 SW Allen Blvd., Suite 140 Beaverton OR 97008