Subject: re: Questions about and suggestions for kernel.
To: None <ic@ludd.luth.se>
From: Adam Glass <adamg@microsoft.com>
List: tech-kern
Date: 03/16/1994 13:10:00
[replying from work to avoid bad network]

> Since we started the VAX port of NetBSD, a number of questions have appeared,
> along with some suggestions for improving NetBSD. Since we have been looking
> mostly at NetBSD 0.9 and not current, we apologize for anything we 'complain'
> about that might have been improved in the later versions.
>

the answers to these questiosn really don't differ presently between
0.9 and current.  However I *STRONGLY* urge you to port to current as
that is your easiest and most fluid path to future NetBSD releases, and 
really the
only  one in which we will be able to help you.

> Memory Management
> - -----------------
>
> Q: On what version of the MACH kernel is the virtual memory management based?
>
>
> Comment:
>
>    We have been comparing the MACH 3.0 memory management with the NetBSD 0.9
>    version, and the MACH kernel's code for memory management seems
> much simpler.
>    Has there been any discussion about updating the memory management
> in NetBSD?

The vm system we have is based on mach 2.5.  In 4.4-lite it has been
enhanced further.  Upgrading to the mach 3.0 vm system might buy us
some performance gain, but may not be on the path to the vm system we
want in the long run.

>    This would probably also improve the portability of NetBSD, the 
pmap module
>    in the 0.9 version (which as far as we can see is basically unchanged in
>    current) is rather unstructured and seems to contain parts that 
are machine
>    independent, and really should be in the generic part of the code.
>

ah...thought that was what this was about.  If you look at the
*CURRENT* sources you will find that other pmap modules (!i386) are 
considerably more portable and cleaner than the i386 pmap.

I believe the other problem you are having is that you are looking at
a mach 3.0 pmap module and the mach 2.5 pmap interface and saying
"Hmm... this doens't just go together w/o any work".

 It really isn't that difficult to take a 3.0 pmap module and drop it 
into a mach
2.5-based vm system.  The differences are actually pretty simple, and
usually don't result in significant work.  Please contact me
*directly* <glass@sun-lamp.cs.berkley.edu> for more information on this topic.

> Q: Is there any documentation for how it 'should' work or is the
> source the only
>    available documentation?
>

Yes.  In particular, there exists some documentation on how to write
pmap modules.  It is intended for mach3.0 but i have a version that I
started to comment re: 2.5.  Again, the differences are really not 
significant, and myself and others can assist you.  Contact me to get 
this document.

> Comment:
>
>    If there is no real documentation, will this not always remain 
'the hackers
>    operating system'?
>

Obviously.  Much of BSD is documented in the daemon book.  It is at
least my hope that they will do a new version to reflect 4.4...

> Multiple Processors
> - -------------------
>
> Q: Are there plans for multi processor support or is there already 
support in
>    the code?
>
> Comment:
>
>    At least some support is there, in the MACH memory management
> code, but what
>    is the status of the rest of the kernel? We have two VAX8350 here
> with 2 cpu
>    each, and it would be interesting to know how we can make them usable with
>    NetBSD.

There is no support for it in the code.  This is really a BSD-ism in 
the sense that BSD never did MP work.

It is a significant amount of man-months worth of work to do right. While it
is certainly our intention to invest this time at some point, it
will depend on the availability of SMP machines to core developers and
other priority projects.  Short term I would suggest you worry first about
the uniprocessor machines...

>
> Multi Threading
> - ---------------
>
> Q: Support for multi threading. Is it there or are there any plans to add it?
>
>
> 					<asbest suits worn>
>
> 						/ The VAX port crew
>

Same answer as above.

later,
Adam Glass

------------------------------------------------------------------------------