[ Cc list trimmed ]
Jamie Lokier wrote:
> [...] dump the contents of x, y and z complete with a standard delimited
> format, and atomic snapshot if such a thing is applicable.
Atomicity will become a big issue with fine granularity of live data.
For sysctl, it's not a problem, because sysctl currently contains
almost static data. /proc currently does a good job at pretending the
problem doesn't exist, because it can provide at least intra-record
consistency.
I see five possible approaches:
- simple time-bomb: continue to pretend the problem doesn't exist, even
if things get worse
- sophisticated time-bomb: any read of a set of variables that should be
read atomically caches all of them for a while and further reads are
from the cache
- locking: a request can acquire a lock while working on the variables
- caching: ditto, but data is cached instead, changing the type of
possible DoS attack
- versioning: /proc/bla/bla/version yields a string that changes whenever
one of the variables in (atomic access domain) /proc/bla/bla changes
I don't particularly like any of the two time-bomb approaches. In order
to avoid the most obvious DoS problems, locking would probably need a way
to "chain" reads, such that the kernel never has to wait for user space
to release a lock. Caching could do the same, or just limit the
per-process amount of such cached data.
Versioning is simpler, but has unbounded access times if user space
retries until the data is consistent. This is particularly bad if
rapidly-changing variables have a useful relation, e.g.
bytes_enqueued - bytes_dequeued = bytes_in_queue
Just some input to keep the thread going ;-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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:23 EST