LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* proc file system
@ 2001-10-05 22:02 llx
  2001-10-06 15:30 ` Erik Mouw
  0 siblings, 1 reply; 11+ messages in thread
From: llx @ 2001-10-05 22:02 UTC (permalink / raw)
  To: linux-kernel

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-05 22:02 proc file system llx
@ 2001-10-06 15:30 ` Erik Mouw
  2001-10-09 13:41   ` Jan Hudec
  0 siblings, 1 reply; 11+ messages in thread
From: Erik Mouw @ 2001-10-06 15:30 UTC (permalink / raw)
  To: llx; +Cc: linux-kernel

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/

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-06 15:30 ` Erik Mouw
@ 2001-10-09 13:41   ` Jan Hudec
  2001-10-09 16:49     ` Steve Brueggeman
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Hudec @ 2001-10-09 13:41 UTC (permalink / raw)
  To: linux-kernel

> 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>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-09 13:41   ` Jan Hudec
@ 2001-10-09 16:49     ` Steve Brueggeman
  2001-10-10 17:04       ` Jan Hudec
  0 siblings, 1 reply; 11+ messages in thread
From: Steve Brueggeman @ 2001-10-09 16:49 UTC (permalink / raw)
  To: Jan Hudec; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-09 16:49     ` Steve Brueggeman
@ 2001-10-10 17:04       ` Jan Hudec
  2001-10-14 20:06         ` Riley Williams
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Hudec @ 2001-10-10 17:04 UTC (permalink / raw)
  To: linux-kernel

> 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>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-10 17:04       ` Jan Hudec
@ 2001-10-14 20:06         ` Riley Williams
  2001-10-15 15:02           ` Jan Hudec
  0 siblings, 1 reply; 11+ messages in thread
From: Riley Williams @ 2001-10-14 20:06 UTC (permalink / raw)
  To: Jan Hudec; +Cc: linux-kernel

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-14 20:06         ` Riley Williams
@ 2001-10-15 15:02           ` Jan Hudec
  2001-10-17 21:10             ` Riley Williams
  0 siblings, 1 reply; 11+ messages in thread
From: Jan Hudec @ 2001-10-15 15:02 UTC (permalink / raw)
  To: linux-kernel

> >> 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>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: proc file system
  2001-10-15 15:02           ` Jan Hudec
@ 2001-10-17 21:10             ` Riley Williams
  0 siblings, 0 replies; 11+ messages in thread
From: Riley Williams @ 2001-10-17 21:10 UTC (permalink / raw)
  To: Jan Hudec; +Cc: Linux Kernel

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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* proc file system
@ 2001-08-27 14:01 Christian Widmer
  0 siblings, 0 replies; 11+ messages in thread
From: Christian Widmer @ 2001-08-27 14:01 UTC (permalink / raw)
  To: linux-kernel

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?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* proc file system
@ 2001-08-08  8:04 Dattatray Kulkarni
  0 siblings, 0 replies; 11+ messages in thread
From: Dattatray Kulkarni @ 2001-08-08  8:04 UTC (permalink / raw)
  To: linux-kernel

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* proc file system
@ 2001-03-30 10:59 Srinivas Surabhi
  0 siblings, 0 replies; 11+ messages in thread
From: Srinivas Surabhi @ 2001-03-30 10:59 UTC (permalink / raw)
  To: linux-kernel


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



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2001-10-17 21:19 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-05 22:02 proc file system llx
2001-10-06 15:30 ` Erik Mouw
2001-10-09 13:41   ` Jan Hudec
2001-10-09 16:49     ` Steve Brueggeman
2001-10-10 17:04       ` Jan Hudec
2001-10-14 20:06         ` Riley Williams
2001-10-15 15:02           ` Jan Hudec
2001-10-17 21:10             ` Riley Williams
  -- strict thread matches above, loose matches on Subject: below --
2001-08-27 14:01 Christian Widmer
2001-08-08  8:04 Dattatray Kulkarni
2001-03-30 10:59 Srinivas Surabhi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).