Borislav Deianov wrote:
>> - locking: a request can acquire a lock while working on the variables
>
> This seems to be always necessary if you want to provide consistent
> data.
I mean explicit locking. With caching, you can have this implicitly.
And with versioning, you may be able to avoid it entirely (at a price).
>> - caching: ditto, but data is cached instead, changing the type of
>> possible DoS attack
>
> This too, unless you require user space to always provide a big enough
> buffer that can fit all the data in a single read request.
Well, you may just cache for a minute or until the file is closed ...
> Sounds impractical as a generic scheme - modifying the version strings
> for fast changing variables will be costly.
Depends ... atomic_inc isn't too bad. I'm more worried about what you
can do once you've detected a change.
> What do you mean by "chaining" here?
Combining the act of acquiring the lock, the accesses, and the releasing
of the lock into a single interaction with the kernel. That way, user
space can't DoS by simply stopping in the middle. (You may of course use
multiple system calls/ioctls/whatever to set up the transaction, just
the execution must be "atomic".)
- 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:24 EST