Re: Corrupt data when reading filesystems under Linux guest

[jdev%panix.com@localhost (Jed Davis)]

I've restructured a lot of xbdback.c; it now should handle xbd requests
that can't be made into one VM range, and merges requests/segments where
possible, including the weird broken Linux case.  For this last, I put
in a simplisticly ratecheck(9)ed printf to inform the administrator.

At Thor's instigation, I dealt with blocking allocation in a
continuation-inspired manner; I did not use kcont(9) for this because
I'd have had to fix and enhance kcont(9) first, and I didn't need any of
the IPL-lowering mechanisms.

It's a little unclean in a few other places, too; the interface with
xen_shm comes to mind (xennet uses it too, so I was reluctant to change
it right away), as does the misuse of splvm() for locking that I cribbed
off of kcont (wait; how can that work if kcont's are being enqueued from
a high IPL?  Doesn't matter for this, as the worst it'll get is splbio,
I think).

Nonetheless, it appears to both work and not kill performance even in
the annoying Linux case.  The diff (against the netbsd-3 branch) can be
obtained at http://www.panix.com/~jld/xbdback-rc1.patch (~33kB).


-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))