On Sat, 24 Jun 2000, Richard Gooch wrote:
> > 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.
Lovely. You see, I more or less trust that we (tinw) can make sure that a
dozen of places where the kernel plays with refcounting in my scheme will
be done correctly. My trust into drivers is way smaller. No offense, but
a) I've seen what the current code looks like.
b) It's about a thousand places instead of a dozen.
> > 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.
Random module writer does not have to think about it - the rule is dead
simple. You have a character device and it's modular - stick
owner:THIS_MODULE into file_operations and forget about it. Similar rules
go for other subsystems. Notice that they are replacing the current rules
regarding the places where you have to put MOD_{INC,DEC}_MOD_COUNT and
they are way simpler.
> An explicit "stop everything else: we're unloading a module" seems a
> lot more obvious to the un-initiated.
"Uninitiated" as in "my first device driver" or as in "my first large
subsystem a-la drivers/video/fbmem.c"? For the former group - see above,
for the latter - excuse me, but "let's see how some other subsystem deals
with that" is not too hard in that case.
-
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