Subject: [FreeVMS] Re: gMach or Linux kernel ?
roart@nvg.ntnu.no
Date: Thu Oct 18 2001 - 11:44:15 CEST
On Wed, Oct 17, 2001 at 06:13:54PM +0200, BERTRAND Joël wrote:
> Damien WYART wrote:
>
> > So I find a bit strange to rely on Linux to achieve very
> > heavy load support and integrted security... I all these important parts
> > must be rewritten, maybe this is not a good choice ?
>
> I don't know if it is a good choice. But VMS is a very complex system,
> and I don't know if it can be rewritten from scratch with a reasonable
> effort. I saw this project as a modification of an existant operating
> system. If we were about 50, I think that we can rewritten VMS from
> scratch, but we are only 15.
>
> The second reason : if we reuse an operating system, we can reuse the
> compilers (and the X server) without any port. I don't know if it a good
> idea, but why not ?
>
> For me, the Linux kernel is a good starting point. It's modular,
We've got to start somewhere.
Starting from scratch is hard.
With having to eventually rewrite you might risk falling into the wrong habits,
but we'll have to take the chance. (Like /tmp or zero-terminated strings)
We should probably have some security "rules" from the start?:
New code shall not use /tmp. Rewrite eventually existing code.
New code shall not use zero-terminated strings, use descriptors without
zero-terminated strings.
I have a feeling /tmp changes will not be that hard.
There is already an STR$ library with descriptors; but a problem might be
with doing an overall rewrite and transition?
Use stuff from http://www.nsa.gov/selinux/? Or is it too ambitious?
How shall we do it, practically?
Take a Linux distribution and branch?
Will it be Redhat, Debian or something else?
Shall we branch more permanently or should we make patches to existing
distributions/kernels?
Other alternatives to keeping with the current kernels and distributions?
We should probably use a limited distribution or concern ourself with
just a subset one? (Redhat 7.1 has 1000 packages...)
How should we keep it "clean"?
By just providing kernel-patches and new binaries, libraries and such,
and try not to change glibc etc. (Conflicts with /tmp and descriptor rewrites)
(We might eventually have to change gcc)
> supports some hardwares and SMP, and is POSIX. It need in a first time a
> new filesystem (and a new VFS) and a new process manager.
A new fs and vfs seem not to be short-term achievable, I think.
A new scheduler might be easier (but I really don't know).
A lot of kernel structures will have to be changed.
In this case, there will be a transition from task_struct to PCB?
How should such transitions be planned?
Libraries might be implemented early, on any Unix for that matter,
We have some STR$ already. What next? LIB$? OTS$?
Various kernel bits might also be possible to do.
-- -Roar Thronæs-- Liste de diffusion FreeVMS Pour se désinscrire : mailto:freevms-request@ml.free.fr?subject=unsubscribe
This archive was generated by hypermail 2b25 : Wed Oct 24 2001 - 21:39:21 CEST