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.
On Sat, Oct 06, 2001 at 12:02:18AM +0200, [email protected] 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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
> On Sat, Oct 06, 2001 at 12:02:18AM +0200, [email protected] 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' <[email protected]>
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, [email protected] 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' <[email protected]>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>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
> 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, [email protected] 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' <[email protected]>
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.
> >> 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' <[email protected]>
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.