Re: Suggested dual human/binary interface for proc/devfs

From: Andrew McNabb (amcnabb@argus-systems.com)
Date: Tue Apr 11 2000 - 22:12:08 EST


On Tue, 11 Apr 2000 allbery@kf8nh.apk.net wrote:

> On 12 Apr, Peter Stuge wrote:
> | Will the values in .dump really BE atomic just because they're in the same
> | virtual file?
> | Aren't the strings still generated from kernel variables when I read()?
>
> I haven't looked recently, but IIRC each read() call regenerates *all*
> of the information in the file. A buffered read of a file <= PAGE_SIZE
> would therefore normally be atomic, because the kernel can't normally be
> preempted while the page is being filled.
>
> Conceivably a file in /proc could contain data which would take some
> time to collect, and which therefore might cause the kernel to
> reschedule while e.g. waiting for disk I/O. I wouldn't expect device
> information to be in this group, although process information might.

As others have pointed out, a read could be interrupted at any point, so
atomicity is not guaranteed. However, if you're opening a single file, it
will be much closer to atomic than if you have to open and read a bunch of
files. In any case, the whole process will be much faster than it would
be in the multi-file case.

But, if you're a human or a shell script, if you only need a few
values, or if you have to set values, the single-variable-per-file method
is _much_ more convenient. IMHO, the best way to go would be the dual
approach (1var/file + .dump).

----------------------------------------------
                Andrew McNabb
             Argus Systems Group
          amcnabb@argus-systems.com
----------------------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:17 EST