> Drivers in userland is slow. You'd end up adding two or more context
> switches per driver use.

true -that is why we need to implement safeguards inside the kernel.

> The big problem with the "malloc in an area" stuff you're talking about
is
> that it's a cooperative thing, yet we're talking about an uncooperative
> problem. :-)

if there is a framework for driver writers to malloc() from a seperate
pool,
bad programming will be taken care of by the bounds checks.

> There are other things you can do too. Like use the pool allocators and
> add a generic routine to see if a given pointer is in a given pool. Or

yes- but the programmer will have to replace malloc()'s by pool allocators.
the less the  change the code has to go through -more acceptable it will
be.

> keep two copies of the pointers your driver mallocs, and compare them.

generic c code can do all sorts of things with pointers. Im not sure if
this will suffice.

To summarize the responses I have received,

-microkernels implement safeguards by maintaining seperate contexts. It
takes too much effort to move mainstream unix to a microkernel environment
and there is overhead with this approach too.
-userland drivers provide system stability but given that drivers operate
(but not always) on real-time inputs, this is not a preferred approach.
-optimizing compilers can implement run-time checks for pointers/arrays
-but they are expensive and the effort to port kernel code to use a
non-standard compiler is high.

My points on this:-

-bad pointer accesses do not trigger an exception immediately and by the
time it does occur, it is too late to recover (ie the handler may not be
able to do much).
-there are modules (not necessarily drivers) which restrict (by design)
pointer access to memory malloc()'ed by the module itself. this can be used
to place bounds on pointer access and it does not require significant code
changes or cooperation. it needs that there be a flag indicating the module
for which malloc() needs to be done and a pair of registers indicating the
bounds on all pointer accesses when code from which the module is
executing.
-there is significant code in the kernel which does not lend to the above
safeguards.
but the most frequently changed/added code is in the drivers and this
safeguard will be useful.

thanks
-kamal
p.s:- this is part of an academic activity, so if you think it is b.s-pl.
let me know.

Take care,

Bill