At 11:22 PM 12/15/2002 +0100, Emmanuel Dreyfus wrote:
> >         1) VMS's shared library mapping technique wouldn't
> >            work under NetBSD.
>
>How is it special?
>Remeber we don't have to do everything like VMS we just have to behave
>so that VMS programs run, that's a big difference.

Shared images that want to activate at a particular virtual address space. 
Given Ragge's explanation of the current PTE story however (everything gets 
mapped anyway) this one is probably doable as long as you don't call 
anything that expects to change your page table (ie sbrk, mmap, etc)

> >         3) The I/O system is based on a multi-threaded asynchronous
> >            I/O model (the QIO) which could not be emulated in the
> >            current I/O layer.
>
>Why not? Could you explain the differencies?

I/O is tied into the threaded event system (ASTs) that VMS uses. NetBSD 
doesn't (didn't?) have a multithreaded kernel beyond i/o contexts the last 
time I checked (which as 1.5, so 1.6 may be different). The event delivery 
scheme would also not work over the existing signal system, although as 
Antonio points out since you have to intercept the trap in the kernel 
anyway you simply end up writing this adaptation layer there.

The acceller8 folks appear to be case by case migration specialists, not 
general binary image running types. (which is what we are talking about 
here, start an image and it just runs).

I certainly don't want to discourage anyone from diving in and having a go 
at it. That's the essence of hacking. But they should be prepared for both 
extensive kernel, library, and scheduler work...

--Chuck

An ex-digit I know once said there had been plans to do something like this 
for Ultrix but the politics killed it. (DEC hated Ultrix because it took 
away VMS sales)