On Sun, Sep 19, 2004 at 06:47:35PM -0500, Chapman Flack wrote:
> Steve Bellovin wrote:
> > 
> > Hmm -- this is the same problem with have with USB umass devices.  It 
> > would be good to find a more general solution.
> 
> I hadn't been following that thread; is it in fact the same issue where
> a USB device is connected after boot, detected, and attach fails to get
> contiguous memory?

Yes it's probablt the same.

> 
> If so, it seems there's a general problem that deserves a general solution.
> The *most* general approach would seem to be to say, look, if the kernel
> needs some contiguous space and there are some user pages in the way, they
> need to be kicked out.  If they're dirty we need to be able to wait while
> they're kicked out, and if all of the hot-pluggable types of buses are
> watched by dedicated kernel threads, then presumably attach is running in
> a thread that can be blocked while that happens.  That does not require any
> pre-reservation of space, at the cost that the attach may be delayed for a
> moment while some pages get flushed.  (Assuming there aren't some more
> complex dependencies I don't know about that could lead to deadlock while
> flushing the pages.)

Yes, this is what should happen. But UVM can't do that yet, code is missing.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--