In article <20050610225426.GC4785@antioche.eu.org>,
Manuel Bouyer  <bouyer@antioche.eu.org> wrote:
> On Fri, Jun 10, 2005 at 06:59:14AM +0000, Jed Davis wrote:
> > In article <1118281429.532953.2723.nullmailer@yamt.dyndns.org>,
> > YAMAMOTO Takashi  <yamt@mwd.biglobe.ne.jp> wrote:
> > > 
> > > besides that, xen_shm assumes an arbitrary request can be mapped into
> > > a single contiguous virtual address range.  it's wrong.
> > 
> > Also, it assumes that it will be mapping pages for only one xbd request
> > at a time; see XENSHM_MAX_PAGES_PER_REQUEST.  That will need some
> > adjusting if I want to piece together a whole MAXPHYS... and, while I'm
> > in this file, I wonder: is xen_shm's big piece of VM actually big enough
> > to handle use by both disk and net devices?
> 
> Yes, it should. And there is a callback mechanism to defer a request in
> case of resource shortage at this level.

Ah, good.  I saw all the ENOMEMs, but I hadn't looked at where they were going.

> > won't the size of _xen_shm_vaddr2ma[] be a little harder to manipulate
> > post-linking?
> 
> Sure, I didn't intend to have xen_shm_size patchable.

There's a comment nearby to the effect that the size of the VM area is
in a variable rather than just a constant in order to make it patchable,
which is why I was confused.  It looks like it would work for reducing
the size, at least.


-- 
(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)))))