On Sat, 24 Jun 2000, Richard Gooch wrote:
> > And you are telling that the former is less brittle? <boggle>...
>
> Think for a moment. The scheme that I proposed (a variant of the
> scheme Rusty, Philip et. al. proposed) will work reliably without
> kernel hacks. The scheme you propose is naturally brittle, because it
> requires a pile of structural changes to the kernel, bloating a
> variety of structures, and *still* isn't entirely safe (someone could
> foul up somewhere).
You mean, like rescheduling at the wrong moment in your scheme?
> Blocking other CPUs is also conceptually simpler. With your scheme
> it's harder to follow what's happening (because they're hidden behind
> some other layer).
???
What is the problem with "thou shalt never run code with reference counter
equal to zero"? IMO it is conceptually simple and it relies on fewer
things. You are trying to kludge around the inherently race-prone
mechanism. Yes, it had been used in almost all modules. Too bad, it means
that it should be fixed, especially since quite a few of them were screwed
up.
What "other layer", BTW? dentry_open() and fput()? Wow... How about the
fact that it's the place where ->open() and ->release() are called from?
-
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 : Mon Jun 26 2000 - 21:00:05 EST