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

On 12 Apr, Peter Stuge wrote:
+-----
|  On Tue, 11 Apr 2000 [e-mail] wrote:
|  >On 11 Apr, Matthew Kirkwood wrote:
|  >|  On Tue, 11 Apr 2000 [e-mail] wrote:
|  >|  > is not prohibitively difficult for a shell script to deal with.
|  >|  Yes it is.  Why should it all be in one big file?
|  >
|  >Because (a) you don't want to deal with the headaches if the network
|  >configuration changes between files, and (b) multiple files will be
|  
|  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()?
+--->8

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.

-- 
brandon s. allbery	   os/2,linux,solaris,perl	[e-mail]
system administrator	   kthkrb,heimdal,gnome,rt	  [e-mail]
carnegie mellon / electrical and computer engineering			kf8nh
    We are Linux. Resistance is an indication that you missed the point.