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

From: Eric W. Biederman (ebiederm+eric@ccr.net)
Date: Mon Apr 10 2000 - 00:53:34 EST


Andrew McNabb <amcnabb@argus-systems.com> writes:

> On Sun, 9 Apr 2000, Dunlap, Randy wrote:
>
> > So with one value per "file," how do you handle the
> > well-known problem of inconsistent data, i.e.,
> > one or more values being updated, program reads
> > file value(s), some more value(s) updated, program
> > reams some more value(s)?
>
> How easy would it be to have a file in each directory that includes all of
> the data within that tree?
>
> This approach would make it possible to use the simple
> single-value-per-file method, except when a large number of values are
> needed immediately or when two simultaneously read values need to be
> consistent. Would this be practical?

Useless. It's totally possible for an interrupt to come in while
you are reading the big file and the values change.

If you need a snapshot and synchronized values it can be accomplished
with some variety of locking. Say a read lock on the directory
asks the kernel to provide a snap shot if it would be so kind,
of the data. A better way might be to stat the files, read the files,
stat the files, so it can detect an inconsitent snapshot.

Writing to multiple config files at the same time (If it is really
needed) can be accomplished by getting a write lock (on the directory?)
and updating the files. Then when the lock is released the values
are updated.

Using lock etc needs a little more thinking out to be really
clean but it does show multiple config values per file is not necessary.

Eric

-
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:13 EST