>> How will you allow for such large table-walking to be compatible with
>> real-time kernel response?
> *What* large table-walking? All this means you have to do is have
> every write check the relevant mount point to see if it's mounted
> read-only, for downgrading remounts, and mark the filesystem as gone,
> for forced unmounts. (I suspect this is what deadfs is for.)
That's typical incremental behavior. Again, it's a matter of tradeoff:
do you want a big atomic operation once in a while and
simple operations every time, or complex incremental operations every time?
It's real-time response vs overall-time duration.
See GC for a field of CS where this trade-off has been beaten to death.
Also, the worry was most important in the case
of atomically stopping processes as recommended by Robert.
Hum. It looks like the need to avoid losing file descriptor information
and pending I/O requests would make it a good idea that there be a
mount mode without either read or write permissions,
similarly to opening files without read or write permissions.
Looks to me like an interesting alternative to deadfs, anyway...
>> Competition is _not_ about taunting each other for pride;
> I know this. I even think most of the people involved know it.
Cool.
> But there seem to be a few - not many, but very poisonous - who seem to
> take any competition - indeed, almost any *difference* - as an
> opportunity for "we're better than you" egoboo.
"Hey, stupid, my underwear is nicer than yours!"
Hum. Let's just send those kiddies to /dev/null; uh, I mean, er, whatever.
[ "Faré" | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ]
[ FR: François-René Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
My opinions may have changed, but not the fact that I am right.
-
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/