[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-vm
Subject:    Re: Plug and Pray when native? CVT?
From:       Peter Schulte-Stracke <Peter.Schulte-Stracke () T-ONLINE ! DE>
Date:       1999-07-30 23:28:32
[Download RAW message or body]

> On Thu, 29 Jul 1999 23:53:49 -0500,
> Linas Vepstas <linas@LINAS.ORG> wrote:
> >It's been rumoured that David Alcock said:
> >> You know how MVS has a CVT, Communications Vector Table, located at
> >> offset x'10' in the PSA, Prefixed Save Area (storage that starts at
> >> location 0 for the related processor).  What will Linux/390 have in that
> >> field?


A MVS compatibility mode, which seems to be behind this question, is completely
out of reach. Incredibly complicated and what good for?

Let me add, that of course Linux/390 will use the PSA for approximately the
same
stuff as MVS does, that 's simply the architecture, only lots less of it (I
hope). And I confess, that when I first looked at Linas' code, I searched for
location 0x10 and was very disappointed (and I am to this moment) that there
was nothing. For with MVS, life starts at 0x10.

Now I am writing a bit of this and of course I will bow to tradition and add a
CVT. But there is really at this moment not much to go into it. Some option
flags perhaps? It is perhaps interesting to discuss the reason why  a (any) CVT
is not so important in Linux (no other port has anything like it): in the
beginning, only a part of the OS was held in real storage at any moment, the
rest being loaded upon demand or constructed by open/close and similar
mechanisms. Now, when the linux kernel loads a module, it in fact link-edits
with the module, so that a (limited) set of kernel symbols is available in the
module. In the same vein is the whole kernel build and linked under linux.
Under OS/360 the dynamic linking was just beginning, and the building of
the whole system as a single load module impossible. So the CVT *protocoll*
allowed decoupled system compenents to co-operate quite effectively.

> Strangely enough, the CVT pointer (0x10 real) is not a required field
> according to POPS.  0x10 absolute is required but even that is only

In the PSA are hardware fields at certain locations, and software fields, some
of which are indispensable as well, but whose definition is subject to
considerable discretion from the programmer. Then there are nostalgia fields.

>Please, please do not go down the CVT track.  This is Unix, if you want
>data from a system control block you ask the kernel, you do not follow
>chains yourself.  IBM realised back in 1970 that they had made a *BIG*
>mistake by making so many control blocks visible to user space
>programs[*].  Even the simplest useful MVS program will need

Oh no. The big (very big) mistake was to have a system call interface which was
and is completed different from the usual subroutine interface, so requiring
the use of assembler routines for almost every thing not completely trivial and
perhaps a unfortunate choice of abstractions (or the lack of them, as some
would say) that could not easily be corrected because the interfaces were so
difficult to program with. But consider that unix was a very simple system by
comparision. And it was used on systems where kernel space was not visible to
userspace programs. So a different style was very successfully developed. With
hindsight one would have liked a much more unix-like MVS, of course, and it has
been often critisised then, but the question of adequately handling the
conceived diverse needs of a multitude of installations, and the question of
internal organisation , and the CVT is part of this and not in the first line
of the programming interface, have nothing to do with each other.

That good abstractions are useful is well known after all, so what is this
about than the lack of it in say a DCB (not that the things go together in a
data area is the problem, neither that you can read them, but you have or at
least can operate on them without any guidance and structure).

Regards,
                Peter

[prev in list] [next in list] [prev in thread] [next in thread]