[FreeVMS] Status Update

[anthony c]

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

> It has VMS scheduling, memory management, QIO, event flags, ASTs, RMS, ODS-2, logicals, DCL, some lock management, etc.

Good...

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

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

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.

Now, as far as loading existing *VMS images into a kernel's userspace running atop i386 hardware, it's already been done by your existing source tree so implimenting it for my kernel shouldn't be that difficult once it is up and running (hopefully as a module for performance reasons).

The point is, as long as the userspace is compatible with the OpenVMS userspace environment, it doesn't really matter what we do with the kernel. Having the same device driver interface as the OpenVMS kernel doesn't really matter (although having a similar QIO interface would be nice) since VAX/Alpha don't even support the same peripherals as i386, and it's not like we're going to be loading OpenVMS drivers into our kernel anyways because of the fact. Any drivers needed in our kernel supported in OpenVMS would need a rewrite anyways (a la Linux to UNIX drivers), so why even go through all the unnecessary trouble?

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

> How much of the above mentioned features do you have?

Still just working on the kernel right now (recall the "invisible" discussion above), but I do intend to impliment an i386 QIO interface for whatever userspace compatibility is needed. 

> Which VMS Internals books do you have?

I'll read up on it once I get my kernel even supporting a userspace environment. Right now, I'm just trying to get basic I/O, core drivers, architecure (module/driver) features, and other kernel interfaces up and running. I will definately utilize any resources I can refer to for OpenVMS userspace compatibility, as I've already discussed with JKB. 

>  I understand, but even if you use VMS internals books, you try to write some VMS-compatible API.

Userspace compatibility is key, kernel is not. I document everything I write, and all of my kernel interfaces are listed and documented alongside the core API functions' prototypes within the headers of my kernel as comments describing what they do, to make driver/module writing a breeze. 

Again, finals are rapidly approaching for me and the amount of studying going into them eats away at my developmental time, but as soon as I'm out for the summer this project takes #1 priority. This is not just something that I'm going to place on the back burner, this is something I'm extremely interested in, and to be honest, I'm writing this code because I want/need this code. When the time comes for a code check-in, I think you'll be impressed and hopefully will be attracted to developing/improving the kernel after seeing its design goals and ease of development. 

Regards,
AC



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.systella.fr/pipermail/freevms/attachments/20090503/6b2b429f/attachment.htm>