On Tue, 11 Apr 2000 allbery@kf8nh.apk.net wrote:
>On 11 Apr, Matthew Kirkwood wrote:
>| On Tue, 11 Apr 2000 allbery@kf8nh.apk.net wrote:
>| > is not prohibitively difficult for a shell script to deal with.
>| Yes it is. Why should it all be in one big file?
>+--->8
>
>Because (a) you don't want to deal with the headaches if the network
>configuration changes between files, and (b) multiple files will be
>slower and spend more time in the kernel processing pathnames in
>procfs, adding more to system load.
>
>Point (a) in particular is a nightmare you don't want to have to deal
>with in a shell script; the single file is effectively atomic with
>respect to the shell script.
When I read this, I thought of something.. I'm however not an expert with the
workings of the proc filesystem so my thought might be all wrong. Please
disregard in that case.
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()?
Doesn't this mean that the kernel variables can change in the middle of the
kernel (equivalent of) sprintf()? (or between my read():s of one byte..)
Sure, if I read() one byte at a time, I'm to blame. But kernel variables
could change from time to other, no?
Of course, if the read_proc does some sort of data locking or buffering
etc. my reasoning doesn't apply - I guess this would be a responsibility for
anyone supplying /proc data..
//Peter
-- irc: CareBear\ tel: +46-40-914420 irl: Peter Stuge gsm: +46-705-783805- 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