[FreeVMS] FreeVMS disk image update

[BERTRAND Joël]

Tim Sneddon a écrit :
> On 16/06/2013 11:42 PM, BERTRAND Joël wrote:
>> Hello,
>>
>> I have uploaded this afternoon a qemu image with a recent L4/X2 kernel
>> (on http://www.freevms.net), the last vmskernel.sys and some
>> modifications to boot this system with grub2 instead of grub-lecacy.
>> This kernel supports until 4 processors. System boots, starts
>> PAGER.SYS that doesn't do anything and stops.
>>
> Hi Guys,
>
> There have been a number of posts going backwards and forwards and
> keeping track of all the different points is a bit difficult, so I
> thought I might just summarize my thoughts regarding some of the points.
>
> Before coming up with my OpenBSD based plan I had looked at L4. There
> are lots of good reasons for going with L4.
>
> 1. VMS on Mach was already done. Some of the high level decisions made
> were quite good are a discussed in a paper submitted to USENIX. This
> would give an implementer a clear direction.
>
> 2. L4 does have a hypervisor. It is part of a related project and I
> believe it could certainly be used. It is called NOVA.
>
> 3. Dresden University of Technology has been putting heaps of effort
> into L4 in the form of Fiasco.OC,
> http://www.inf.tu-dresden.de/index.php?node_id=2697.
> <http://www.inf.tu-dresden.de/index.php?node_id=2697>They provide quite
> decent supporting libraries to get projects off the ground.

	When we have choosen L4 four years ago, we have choosen L4Ka, not 
Fiasco, as L4Ka API was better than L4/Fiasco one. Fiasco comes with 
L4RE, but this toolkit needs corba and some other technologies.
If I remember L4Ka was also designed to provide very short IPCs.

> 4. Linux drivers could likely be used in a shell process that presents
> the correct environment to the driver.

	With L4, each driver can run in its own address space (and of course in 
a separated thread).

> However, while that all sounds great. This was not something that I
> could easily handle on my own and so I made the decisions, related to my
> project that I would only support user mode public interfaces. Don't
> bother with presenting four modes. This is a great design feature of
> VMS, but not critical to get people with user mode applications off the
> ground. VMS engineering have made the same decisions when supporting
> code between VAX, Alpha and I64. So, I did the same. There is also a lot
> less work in writing a bunch of libraries that provide a supported call
> interfaces, rather than an entire operating system.
>
> My feeling is that most people who are looking for somewhere to go are
> likely unconcerned with whether or not the shell runs in supervisor mode
> or if RMS runs in exec mode. I think that modifying something like BSD
> UNIX to support some underlying features, like logicals and ASTs and
> then handling everything else with a compat package will be
> comparatively easier to implement. The other things is that all that
> UNIX compatibility that the masses are begging for is right there!

	Sure, but Linux or xBSD kernels are monolithic. Thus, you have to patch 
mainstream kernel (we have try until 0.3 FreeVMS kernel). It's a huge 
work too.

	With a L4 kernel, you only have to know root task's API to write a new 
kernel that cannot crash your running system (it runs as a separate task 
in a separate address space). Critical tasks are only root task, its 
pager and pagefault handler.

> These are the first two goals I would like to put forward:
>
> * User-mode public API compatibility.
>
> * Open source (preferably BSD or GPLv3) licensed source code.

	Regards,

	JKB

PS: if you send mail to freevms at systella.fr, you must subsribe to the list.