[FreeVMS] Status Update

[Roar Thronæs]

On Sun, May 03, 2009 at 07:13:19PM -0700, anthony c wrote:
> > It is only compiled on Linux, but it is not a Linux kernel / distribution.
> 
> Could have fooled me, what with the Linux (2.4?) source tree under the linux/ directory, the makefile.linux makefile, and the references made to Linux, UML, and various other Linux-based kernel modifications under doc/internals. 

But even less is used as time passes.
Linux system calls have to remain for some time.
And the basic system setup is there.

> > Device drivers are rewritten to have a QIO interface.
> 
> Making the device driver interface for FreeVMS fully compatible with OpenVMS makes no sense. OpenVMS is written/compiled for VAX and Alpha, while FreeVMS is (for the moment) i386-only, unless my kernel's portability is sufficient enough for smooth cross-compilation, but it is not going to be a huge goal until it runs smooth on i386 although portable coding practices are being done in the meantime. 
> Consider Linux, a self-proclaimed open source UNIX-like operating system, with a not-very-UNIX-like driver interface, or kernel architecture for that matter. Making a clone of an operating system, especially for an entirely different processor architecture, does NOT mean the driver interface has to be the same, although the usermode environment, C/POSIX library and binary image loading should be the same as I'm attempting to do.

Not only device drivers, but also how RMS accesses ODS-2, and how the
TCP/IP-stack is accessed, is done with QIO.
QIO with ASTS is after all a characteristic of VMS.
And a system call too, so it must be considered as part of the user interface.
It is basically the equivalent of Unix creat, open, close, read, write,
ioctl, fcntl and tens of other system calls.

(Now there is also something new, Fast I/O, but I don't know much about it)

> > They have a QIO interface and are structured according to?:
> > (snip: various OpenVMS Alpha driver coding books)
> 
> A QIO interface, along with the POSIX read/write systemcalls is desired (and perhaps layered) is desired, but I think we need to establish the fact that Alpha and i386 are NOT THE SAME ARCHITECTURE, and that there are no plans to even make the kernel(s?) support them both. 

Only 64-bit that is supported (and will be for a long time) is x86_64.

> Everything at the kernel level shouldn't matter, since we have nothing belonging to OpenVMS kernel-wise to emulate for i386, and save for usermode system calls and libraries it _really_ shouldn't even matter. For an example, look at the recent work by the Debian developers to run the FreeBSD kernel under the usual Debian userspace: the kernel should be invisible and shouldn't even matter as long as it operates the userspace correctly, as basic operating system theory has it.

But FreeBSD and Linux are much alike, belonging to the same family.
Given a set of system calls and a complete system specification,
how many fundamentally different ways can it be implemented in?
It will be fun for you to find out.

> The point is, as long as the userspace is compatible ...

Meaning one should be able to compile source (mostly C) code one
can compile on OpenVMS?

> > I would really like to replace the current console driver.
> 
> Tell me what you'd like to see in it, or just wait until I check in the code and patch away at it.

Some of the drivers with QIO interfaces hurt a bit :)
But no hurry.

> I document everything I write

Good habit.

-- 
Regards,
Roar Thronæs