At 3:12 AM -0400 8/19/00, gabriel rosenkoetter wrote:
>On 08/16/2000 16:24:57, Henry B. Hotz <hotz@jpl.nasa.gov> wrote:
>
> > There is already support for swapping to a vnode filesystem.  Sounds
> > like what you should be doing is defining the vnode calls to swap
> > page data, not modifying UVM itself.

>As I understand it UVM won't use the vnode pager for standard memory,
>it uses aobj/uvm_obj pairs for that, and making it use something else
>would be more work than what I'm thinking of.
>
>Also, I don't see how a vnode FS (which exists as a file in the local
>file system, no?) helps me get pages of data into the live memory of
>another machine on the network.

Hmmm...  Perhaps I didn't think this all the way through.  My 
starting point was the problem Bill S mentioned about the difficulty 
of replacing existing routines and the fact that the kernel has a 
mechanism for adding routines to support new filesystems.

The problem is that the latter is not *directly* a mechanism for 
reading/writing blocks of memory from an external device.  Thinking 
about it for about 10 seconds more than I did the first time I'd say 
there are two approaches you could try:  1) you could use an LKM to 
add a device driver that UVM could use to access the kind of external 
memory you want, or 2) you could use an LKM to add a new filesystem 
type which has whatever "side effects" you want for how the data is 
actually stored.  Depending on how picky you are about what the data 
looks like on the external machine this could get rather complex, and 
might wind up looking a lot like an NFS mount of another machine's 
memory file system.  Except that you would want to do something 
special with the directory/inode structure to reduce overhead. 
*More* complexity.

>On 08/14/2000 18:16:12, Bill Studenmund <wrstuden@zembu.com> wrote:
>
> > Also, I think that it's hard to change existing kernel routines. The
> > linking process, as I understand it, will modify unresolved symbols in
> > your lkm to point to the in-kernel ones. But it will not modify existing
> > kernel references to other kernel functions (like existing calls to
> > uvm_page()) to point out to your lkm code.
>
>Yes, that is a profound problem. If that's true, then it's time to
>give up on LKMs entirely.
>
>I would ask how LKMs would ever be useful for developing new additions
>to the kernel, then... which I thought was the point of their
>existence. If you can't add calls to symbols from your LKM or modify
>in-kernel symbols to behave differently, how could you ever add
>anything to an existing kernel except by recompiling the kernel?

Well, that's it.  You can only add *new* stuff, not modify existing 
stuff unless it has specific hooks for it.  This problem is not 
unique to NetBSD.  The DS1 spacecraft code (which uses the VxWorks 
real-time kernel) has the same problem.  Solving that problem is what 
ld is for, and ld wasn't built to un-ld. /-(

If anyone knows of a general solution to the problem please let me 
know.  I might even get a bonus.

At 12:57 AM -0400 8/20/00, gabriel rosenkoetter wrote:
>And further, from vnd(4):
>
>BUGS
>     The vnd driver does not work if the file does not reside in a local
>     filesystem.
>
>Definitely not making me think I'm interested in the vnode pager..

So scratch my NFS to MFS idea.  Does this mean that NetBSD doesn't 
support diskless machines at all?

Is the problem a specific interaction or does it mean that you can't 
access the networking code at all inside a page fault?  If so then my 
custom device driver idea wouldn't work either.

Nothing's ever simple is it.

BTW there was a comment on the quality of the -mlong-call patch that 
made it sound fairly good.  Wasn't the guy who made it from Wind 
River (VxWorks)?


Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu