[FreeVMS] Status Update

[BERTRAND Joel]

Roar Thronæs wrote:
> 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.

	Ant I think we have to keep QIO too.

> QIO with ASTS is after all a characteristic of VMS.

	Right.

> 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.

	And I would add that i386 is a dead arch and shouldn't be a priority. 
If I have to do some choices, I shall prefer amd64, sparc64 and maybe 
some other 64bits archs.

>> 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.

	Yes, I think ;-)

	Regards,

	JKB