Subject: [FreeVMS] Re: gMach or Linux kernel ?
From: BERTRAND JoŽl (firstname.lastname@example.org)
Date: Thu Oct 18 2001 - 14:55:58 CEST
> On Wed, Oct 17, 2001 at 06:13:54PM +0200, BERTRAND JoŽl wrote:
> 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?
I think that the FreeVMS project will be independent, not a branch of a
> Will it be Redhat, Debian or something else?
> Shall we branch more permanently or should we make patches to existing
> 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)
If the kernel is POSIX, I think that we can use the STR$ library with
string descriptor, and NULL-terminated string with POSIX libraries. I
don't know how work the POSIX layer of OpenVMS...
>>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.
-- Liste de diffusion FreeVMS Pour se dťsinscrire : mailto:email@example.com?subject=unsubscribe
This archive was generated by hypermail 2b25 : Wed Oct 24 2001 - 21:39:20 CEST