2003-03-03 19:52:59

by Kenn Humborg

Subject: [PATCH] make f_pos accessible via /proc/PID/fd/N

The attached patch sets the "size" for the /proc/PID/fd/N entries
to the current file position (file->f_pos).

In proc_lookupfd(), I fill inode->i_size with file->f_pos. Then
in pid_fd_revalidate(), I refresh it again.

I would find this useful to be able to tell, for example, how far
a large outgoing SMTP transfer has got (so I can avoid rebooting
if it's almost finished), or how far a customer download from our
FTP server has got to.

Was there any particular reason for fixing the "size" of these
files at 64? Are there any tools that depend on this?

Patch is against 2.5.63.

Later,
Kenn


--- /home/kenn/linux-vax/lxr/2.5.63/src/fs/proc/base.c Tue Feb 18 00:25:22 2003
+++ base.c Mon Mar 3 19:55:15 2003
@@ -819,8 +819,11 @@
atomic_inc(&files->count);
task_unlock(task);
if (files) {
+ struct file *f;
read_lock(&files->file_lock);
- if (fcheck_files(files, fd)) {
+ f = fcheck_files(files, fd);
+ if (f) {
+ dentry->d_inode->i_size = f->f_pos;
read_unlock(&files->file_lock);
put_files_struct(files);
return 1;
@@ -926,7 +929,7 @@
read_unlock(&files->file_lock);
put_files_struct(files);
inode->i_op = &proc_pid_link_inode_operations;
- inode->i_size = 64;
+ inode->i_size = file->f_pos;
ei->op.proc_get_link = proc_fd_link;
dentry->d_op = &pid_fd_dentry_operations;
d_add(dentry, inode);

2003-03-11 12:38:11

by Paul Jakma

Subject: Re: [PATCH] make f_pos accessible via /proc/PID/fd/N

On Mon, 3 Mar 2003, Kenn Humborg wrote:

> The attached patch sets the "size" for the /proc/PID/fd/N entries
> to the current file position (file->f_pos).
>
> In proc_lookupfd(), I fill inode->i_size with file->f_pos. Then
> in pid_fd_revalidate(), I refresh it again.
>
> I would find this useful to be able to tell, for example, how far
> a large outgoing SMTP transfer has got (so I can avoid rebooting
> if it's almost finished), or how far a customer download from our
> FTP server has got to.

Cute little addition. This would be very useful to have.

> Was there any particular reason for fixing the "size" of these
> files at 64? Are there any tools that depend on this?

If not it'd be very nice to have in the kernel.

> Patch is against 2.5.63.
>
> Later,
> Kenn

regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
warning: do not ever send email to [email protected]
Fortune:
Numeric stability is probably not all that important when you're guessing.