[FreeVMS] Status Update

[BERTRAND Joel]

anthony c wrote:
>  > 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.
> 
> In that case I'll implement it but with more of an emphasis as a 
> usermode I/O system call rather than for actual device drivers, 
> following the peripheral discussion earlier. From what I've read of QIO 
> and the complex arguments it supports, it should be fun to write support 
> for it, and in fact I'll make it the primary interface for TCP/IP, 
> filesystem, and other non-i386-specific drivers.
> 
>  > (Now there is also something new, Fast I/O, but I don't know much 
> about it)
> 
> Ah, the nuances of emulating version-dependent features... The OpenVMS 
> documentation declares it as a seperate system call to reduce processing 
> time of filesystem, networking, and other misc. I/O operations, and is 
> available OpenVMS only. It requires the the data to be stored in an 
> in-memory buffer object, and prior to 7.2 this was limited to a 
> process's given virtual address space but in current versions the buffer 
> object can be in a global page.
> 
> It's not a huge priority to implement as the standard QIO and RMS, but 
> it would be a nice system call to add later just for increased 
> compatibility and to make the loading of precompiled VMS images smoother.
> 
>  > But FreeBSD and Linux are much alike
> 
> Userland-wise (i.e. system calls, kernel transparency, library support) 
> yes, kernel no. FreeBSD is a typical Unix Microkernel, whereas Linux 
> broke away and used a monolithic kernel, although their interface is 
> similar in the way of system call usage but the way extensions are 
> loaded, where in memory they reside and what priviliedge (ring) the 
> drivers run as vastly differ.
> 
> And while we're on the subject, how does *VMS handle kernel 
> modules/drivers? If it isn't application-specific, then we don't have to 
> worry but if it's anything like Netware and the applications run the 
> same address space as and depend on the kernel and it's modules then we 
> have a problem.
> 
>  > Meaning one should be able to compile source (mostly C) code one can 
> compile on OpenVMS?
> 
> Yes. A port of GCC to our kernel is a goal I've had since day 1, and 
> it's an integral part of any OS. In addition to standard C, POSIX is 
> needed for compatibility with OpenVMS and any other POSIX code one 
> should be able to compile on OpenVMS and other POSIX-compliant OS. As 
> for BLISS, PASCAL and FORTRAN, I'm not touching it ;).

	I can not be agree with your last sentence. OpenVMS is not POSIX 
compliant out of the box (I have a 8.3 on an AS800 and a 7.3 on a VAX, 
and it is impossible to directly build any POSIX code). It only contains 
all concepts to be POSIX compliant. If you want to build some POSIX 
sources on OpenVMS you have to install some utilities that are not 
distributed with OpenVMS (OpenVMS jacket libraries and some others). All 
stuffs to build POSIX sources are not required to write system. Indeed, 
in a first time, we only need a stable kernel (with only internel POSIX 
support, not userland POSIX support) even if we have to cross compile 
it. When kernel API shall be stable enough, we can modify a gcc backend 
to build kernel from itself.

	That being said, we need some documentations to write these API because 
it isn't easy to obtain any VMS books.

>  > Ant I think we have to keep QIO too.
> 
> I'll write support for it, considering it's used for filesystem and 
> TCP/IP and some applications might need that. I also have some reading 
> to do, considering QIO is pretty extensive...
> 
>  > 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.
> 
> I don't know Sparc assembly, but writing a portable kernel is key for 
> migrating to other "vanity" architectures. IA-32 is supported for now, 
> x86_64 assembly written at the bottommost of the current kernel code 
> isn't that hard of an addition, and other than that portable C code 
> covers us on other portability issues. But yes, 64 bits is desired, and 
> even a Pentium processor as the oldest supported x86/IA-32 processor is 
> desired.

	Today and for me, i386 isn't a priority. All new workstations are 64 
bits ready and I think that it shall be easier to write a 64 bits kernel 
(more internal registers...).

> With all of these new requirements, keep in mind that what I check in 
> (when it's finished) will be described as a "diamond in the rough", and 
> I will ultimately need some help in extending my basic kernel into 
> supporting all of these requests. But first, as I've said, let me get 
> the basic kernel architecture laid and a base for us to extend and we'll 
> hack the hell out of it to support everything we need to call the OS a 
> VMS clone, GPL'd of course.

	If I have understood, today, there are _two_ concurrent kernels. The 
first one is a fork of a Linux 2.4.15 kernel. The second one is written 
from scratch. FreeVMS only requires _one_ kernel and I think we have to 
merge both kernel. How ?

	JKB