proc file system

proc file system

[Srinivas Surabhi]

hi everybody,


   kindly give me a idea  how to write a file into proc filesystem.
i.e functions to be used?system calls to be be called?

adv .thanks for giving imm. reply

srinivas

proc file system

[Dattatray Kulkarni]

    
> Hi,
> Where Can I get full documentation about proc file system in linux?
> regards,
> dattatray.
> 

proc file system

[Christian Widmer]

i need to report more then 4KB of data to the /proc and found a short
note in "linux device drivers 2" how to do. so i wrote some functions
that look like that one below.

static int my_read_proc(char *page, char **start, off_t offset,
                       int count, int *eof, void* data)

{
  static int  myIndex = 0, done = 0;
  int en = 0, max = count - 256;

  for(;myIndex < MAX_INDEX; myIndex++){
	len += sprintf(page+len, "hier some info of dynamic length\n");
	if(len > max){		// still data left
           (*start) = page;
            return len;
         }	
  }
  myIndex = 0;			// all data out
  *eof = 1
  done   = 1;
  return len;
}

not all of my output gets printed. looks like the data from the last 
call to my function disapiers. thats wy i thought to delay the eof
one call by:

static int my_read_proc(char *page, char **start, off_t offset,
                        int count, int *eof, void* data)

{
  static int  myIndex = 0, done = 0;
  int len = 0, count = offset - 256;
  if(done){				// now we say that we are done
    *eof = 1;
    done = 0;
    return 0;
  }
 for(;myIndex < MAX_INDEX; myIndex++){
	len += sprintf(page+len, "hier some info of dynamic length\n");
	if(len > max){			//more data left
           (*start) = page;
            return len;
         }	
 }
 (*start) = page;			//were done (but we dont say)
 myIndex = 0;
 done   = 1;
 return len;
}

it does not cut any more some of my data. but endlessly dumping my data to 
the terminal. after delaying the reset of 'done' as long as offest dont get
back to 0 it seems to work.

  if(done & offset){			// wait until linux seems to have the
					// same view of the proc-files state
    *eof = 1;
    return 0;
  }else done = 0;



can anybody tell me wats going on here - i'm confused what do i not know?

proc file system

[llx]

i've written a prog interface for my logger utility to make it easy
to transport my logging information from kernel to userspace using
shell commands. now i want to use tail -f /prog/<mylogfile>. what
do i have to do for that to work. when using tail my loginfo gets
read form my ringbuffer, but nothing gets printed in the terminal.

Re: proc file system

[Erik Mouw]

On Sat, Oct 06, 2001 at 12:02:18AM +0200, llx@swissonline.ch wrote:
> i've written a prog interface for my logger utility to make it easy
> to transport my logging information from kernel to userspace using
> shell commands. now i want to use tail -f /prog/<mylogfile>. what
> do i have to do for that to work. when using tail my loginfo gets
> read form my ringbuffer, but nothing gets printed in the terminal.

I think you actually want a character device instead of a /proc file.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: proc file system

[Jan Hudec]

> On Sat, Oct 06, 2001 at 12:02:18AM +0200, llx@swissonline.ch wrote:
> > i've written a prog interface for my logger utility to make it easy
> > to transport my logging information from kernel to userspace using
> > shell commands. now i want to use tail -f /prog/<mylogfile>. what
> > do i have to do for that to work. when using tail my loginfo gets
> > read form my ringbuffer, but nothing gets printed in the terminal.
> 
> I think you actually want a character device instead of a /proc file.

Could you please explain why? I can't see the advantage (read and write
are fileops; you can have them exactly the same for proc file and device).

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

Re: proc file system

[Steve Brueggeman]

Well, to get tail -f to work, minimally you'll have to support
maintaining a fileposition, so tell() and seek() have something useful
to work on.  It's been a while since I looked at the source for tail,
pretty much for similar reasons (wanted to follow a /proc file).  Most
/proc files are considered (relatively) fixed-length files, who's
contents get updated.  tail -f expects to follow a file that is
growing in size.

I don't have sources in front of me, so hopefully someone else will
step-up and provide more detail than I have.

Steve Brueggeman


On Tue, 9 Oct 2001 15:41:34 +0200, you wrote:

>> On Sat, Oct 06, 2001 at 12:02:18AM +0200, llx@swissonline.ch wrote:
>> > i've written a prog interface for my logger utility to make it easy
>> > to transport my logging information from kernel to userspace using
>> > shell commands. now i want to use tail -f /prog/<mylogfile>. what
>> > do i have to do for that to work. when using tail my loginfo gets
>> > read form my ringbuffer, but nothing gets printed in the terminal.
>> 
>> I think you actually want a character device instead of a /proc file.
>
>Could you please explain why? I can't see the advantage (read and write
>are fileops; you can have them exactly the same for proc file and device).
>
>--------------------------------------------------------------------------------
>                  				- Jan Hudec `Bulb' <bulb@ucw.cz>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: proc file system

[Jan Hudec]

> Well, to get tail -f to work, minimally you'll have to support
> maintaining a fileposition, so tell() and seek() have something useful
> to work on.  It's been a while since I looked at the source for tail,
> pretty much for similar reasons (wanted to follow a /proc file).  Most
> /proc files are considered (relatively) fixed-length files, who's
> contents get updated.  tail -f expects to follow a file that is
> growing in size.

... thus it won't work on char dev at all;-) (but simple cat will do
lot better). Well, it does not matter what proc files are supposed to
be, they can behave any way you want. They can even behave like devices.
(And it even shouldn't be more work)

AFAIK the only differences remaining are that devices can initialize module
autoloading and that you can put device node anywhere.

> I don't have sources in front of me, so hopefully someone else will
> step-up and provide more detail than I have.
> 
> Steve Brueggeman
> 
> 
> On Tue, 9 Oct 2001 15:41:34 +0200, you wrote:
> 
> >> On Sat, Oct 06, 2001 at 12:02:18AM +0200, llx@swissonline.ch wrote:
> >> > i've written a prog interface for my logger utility to make it easy
> >> > to transport my logging information from kernel to userspace using
> >> > shell commands. now i want to use tail -f /prog/<mylogfile>. what
> >> > do i have to do for that to work. when using tail my loginfo gets
> >> > read form my ringbuffer, but nothing gets printed in the terminal.
> >> 
> >> I think you actually want a character device instead of a /proc file.
> >
> >Could you please explain why? I can't see the advantage (read and write
> >are fileops; you can have them exactly the same for proc file and device).
> >
--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

Re: proc file system

[Riley Williams]

Hi Jan.

>>>>> I've written a prog interface for my logger utility to make it
>>>>> easy to transport my logging information from kernel to userspace
>>>>> using shell commands. now i want to use tail -f /prog/<mylogfile>.
>>>>> what do i have to do for that to work. when using tail my loginfo
>>>>> gets read form my ringbuffer, but nothing gets printed in the
>>>>> terminal.

>>>> I think you actually want a character device instead of a /proc file.

>>> Could you please explain why? I can't see the advantage (read and
>>> write are fileops; you can have them exactly the same for proc file
>>> and device).

>> Well, to get tail -f to work, minimally you'll have to support
>> maintaining a fileposition, so tell() and seek() have something
>> useful to work on.  It's been a while since I looked at the source
>> for tail, pretty much for similar reasons (wanted to follow a /proc
>> file).  Most /proc files are considered (relatively) fixed-length
>> files, who's contents get updated.  tail -f expects to follow a file
>> that is growing in size.

> ... thus it won't work on char dev at all;-)

Why won't it?

> (but simple cat will do lot better).

> Well, it does not matter what proc files are supposed to be, they
> can behave any way you want. They can even behave like devices. (And
> it even shouldn't be more work)

How about the aspects of /proc files that are outside of your driver's
control...

 1. The actual size of the /proc file is controlled by a variable that
    your driver sets. Your driver gets no indication whatsoever as to
    when that variable is read.

 2. Your driver is required to recreate the ENTIRE /proc file every
    time a read() call is made, and gets NO indication as to which
    part of the file is actually returned to the caller.

Compare these to the requirements of a character device...

 1. There is no actual size stored anywhere - and, as a matter of fact,
    the whole concept of file size is meaningless.

 2. When your driver gets a read() call, it is only required to return
    data that has never before been returned, and not data that has
    been previously read. Indeed, it is an error to return the same
    data twice.

...and the differences you've overlooked become obvious, as does the
reason why your choice of a /proc file is not appropriate for your
stated application.

> AFAIK the only differences remaining are that devices can initialize
> module autoloading and that you can put device node anywhere.

You forgot the above.

>> I don't have sources in front of me, so hopefully someone else will
>> step-up and provide more detail than I have.

An obvious source of relevant information is the klogd kernel log tool,
which already does precicely what you're proposing to do. Indeed, I'd
tend to replace your entire logging module with calls to printk() that
specify a unique logging facility.

Best wishes from Riley.

Re: proc file system

[Jan Hudec]

> >> Well, to get tail -f to work, minimally you'll have to support
> >> ...
> 
> > ... thus it won't work on char dev at all;-)
> 
> Why won't it?

Well, I didn't look thoroughly, so it might. But - it uses stat and
stat stats the device inode, not the device itself.

> > (but simple cat will do lot better).

But you really don't care about tail -f neither with device, nor with
/proc file. Because you can do cat and block the reads in kernel.

> How about the aspects of /proc files that are outside of your driver's
> control...
> 
>  1. The actual size of the /proc file is controlled by a variable that
>     your driver sets. Your driver gets no indication whatsoever as to
>     when that variable is read.

AFAICS (from source), neither can you with character device. You can't
set size for character device at all.

>  2. Your driver is required to recreate the ENTIRE /proc file every
>     time a read() call is made, and gets NO indication as to which
>     part of the file is actually returned to the caller.

AFAIK You have a control of both file and inode operations for proc file.  It's
your inode and you can set whatever you want there. On the other hand with
device you can only set file_operations (you can't touch the inode structure or
you might confuse the fs driver).

Just there are default proc file and inode operations that are used for
most purposes (there is the /proc/kcore, which is like /dev/kmem - they
work simlarly (neither can create it's content to a buffer), but only
/proc/kcore has meaningful size.

> Compare these to the requirements of a character device...
> 
>  1. There is no actual size stored anywhere - and, as a matter of fact,
>     the whole concept of file size is meaningless.

That's why you can't get tail -f (nor tail) work on a device.

>  2. When your driver gets a read() call, it is only required to return
>     data that has never before been returned, and not data that has
>     been previously read. Indeed, it is an error to return the same
>     data twice.

AFAIK, that's possible with /proc file too.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>

Re: proc file system

[Riley Williams]

Hi Jan.

>>>> Well, to get tail -f to work, minimally you'll have to support...

>>> ... thus it won't work on char dev at all;-)

>> Why won't it?

> Well, I didn't look thoroughly, so it might. But - it uses stat and
> stat stats the device inode, not the device itself.

I've just checked, and it hangs as you predicted, at least with
/dev/urandom (which is a char device).

However, this part of the discussion appears to be irrelevant to the
main thrust of your argument. As you appear to have problems with the
reasoning I've been offering as to why your argument is false, can I
offer you the challenge of writing a /proc file driver to satisfy a
simple program I've written? I've used /proc/dev as the /proc file in
question in this source code, but you can change that to match whatever
you decide to call it.

 Q> /* Test program to determine if /proc is the equivalent of /dev
 Q>  * (which I do not believe).
 Q>  */
 Q>
 Q> #include <stdio.h>
 Q> #include <stdlib.h>
 Q>
 Q> int main(void) {
 Q>     char test[256];
 Q>     FILE *fp = fopen("/proc/dev","r");
 Q>     int result = 0, N, P, count;
 Q>
 Q>     for (count=1; count<255; count++) {
 Q>         N = (int) (224.0 * rand() / (RAND_MAX + 1.0) + 1.0);
 Q>         fgets( test, N, fp );
 Q>         for (P=0; P<N; P++)
 Q>             if (test[P] != P+32 && )
 Q>                 result++;
 Q>     }
 Q>     fclose( fp );
 Q>     exit( result );
 Q> }

To succeed, it must exit with a return value of 0. The driver can make
the following assumption:

 1. The program will read a series of successive strings from the
    device, these strings being between 1 and 224 characters in
    length.

For the program to return a 0 value, the driver needs to make the
following guarantees:

 A. There will always be at least 224 characters available to read.

 B. No matter what position in the file the program reads from, it
    always receives the same sequence of bytes, where each byte
    contains the value that is 32 higher than its position in the
    string.

Nothing else needs to be guaranteed, and this is a trivial driver to
write as a /dev driver. However, I believe that with the current kernel
design, it is actually impossible to write this as a /proc file driver.

Comments?

Best wishes from Riley.