Subject: [FreeVMS] Re: A kernel to start
From: Bruce Allen (claudevms@home.com)
Date: Wed Nov 14 2001 - 04:54:30 CET
----- Original Message -----
From: <roart@nvg.ntnu.no>
To: <freevms@ml.free.fr>
Sent: Tuesday, November 13, 2001 3:42 AM
Subject: [FreeVMS] Re: A kernel to start
>
> On Mon, Nov 12, 2001 at 06:55:24PM -0700, Bruce Allen wrote:
> >
> > I'll write a paper.
> >
> > There is just volumes of information about the VMS kernel internels.
> > I have the 4.4 book. I will soon (next weekend?) the paper.
> >
> > Please, send me ideas as to priorities. The kernel is a big task and
> > will require a lot of work.
>
> How well do you know both VMS and Linux Internals?
> It could be useful to know both, so you will have at least a sort of
> feeling of how to get from A to B.
How well do you know both VMS and Linux Internals? I hope there are some
really knowledgeable people on the project. I know some and I have worked on
other OSes.
I added floating point context switching for 8087 to the PC XINU OS.
I had a VMS internals class in 1988.
I wrote a VMS security package which allowed the user, SYSTEM administrator,
to
monitor how secure his VMS system(s) were. It had a command line interface
and a
detached process to allow the user to query system security or have the
monitor process
send MAIL and OPCOM messages as to violations. I wrote some kernel code for
this package that flipped the undocumented process bit that makes a VMS
process
unstoppable. I reversed engineered some BLISS and MACRO software from the
VMS source listings, yes I had kernel source listing access, and wrote C
code to query
the I/O database above IPL 2.
Linux internals are easier than VMS internals. 'NIX kernels in general are
not interruptable.
When a process makes a system call the 'NIX kernel can not reschedule the
process in favor
of another, possibly higher priority, process. It can respond to interrupts
as long as the system call
does not protect a critical section of code with x86 instructions cli and
sti, which disable and enable
interrupts. The 'NIX kernel cannot block on anything!
Your spiral approach is exactly how I would approach this project too.
Scheduling is a good starting point.
The priority boost for I/O and adding process states and a fixed quantum are
a first step followed by
a fixed 0-31 priority values. Priorities 16-31 would have no quantum
expiration.
If this project is to "clone" VMS then we need the source listings to get
the data structures verbatum.
The listings are $3,000.00.
Please keep the suggestions coming. With a complex OS no one person, maybe
Ruth Goldberg, can
know how to do all the work themselves.
Thanks,
>
> Suggestion (made on a coarse hunch)(a sort of spiral development process)
>
> 10$:
> (Naming Conventions.)
> Data Structure Definitions.
> Other basic stuff. (PALcode-things)
> Scheduling and Time Support
> Life of a Process
> Control Mechanism
> Synchronization
> Memory Management
> Input/Output (not on the first iterations)
> Life of the System (not on the first iterations)
> BR 10$
>
> I have a feeling things will be a bit iterative, since I doubt everyone
> will sit down and write all include-files, and then there will be
> made complete things of everything else.
>
> As a pilot study before the paper, why not start on scheduling just to get
> the ball going/tip over the first domino?
>
> -Roar Thronæs
>
>
> --
> Liste de diffusion FreeVMS
> Pour se désinscrire :
mailto:freevms-request@ml.free.fr?subject=unsubscribe
>
>
>
-- Liste de diffusion FreeVMS Pour se désinscrire : mailto:freevms-request@ml.free.fr?subject=unsubscribe
This archive was generated by hypermail 2b25 : Wed Nov 14 2001 - 04:55:10 CET