Alexander Viro writes:
>
>
> 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?
If you're careful, there won't be a reschedule. And if you don't
believe that it can be done right in user-space, it's still very
simple to do it safely in kernel space.
> > 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?
That's my point. I'm concerned that what you're doing hides things too
much. Just because it's obvious to you, because you're writing it,
doesn't mean it will be obvious to some random module writer.
An explicit "stop everything else: we're unloading a module" seems a
lot more obvious to the un-initiated.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:06 EST