… you know, when you hear hoofbeats, think horses.
Well, there are some situations when the “Occam’s razor” approach does not really seem to be the optimal one. This particular case seems to fall into this class. More on it below
And to extend such an idea to the entire concept of why IRQs exist (when the simplest explanation – that some devices
need “more urgent” service than others – is more likely to be the correct one).
The above suggestions seems to be, indeed, perfectly reasonable at the first glance. However, if you scratch it a bit, you will see that
things as not necessarily as simple as they first seem to be.
To begin with, if the concept of “certain device interrupts being more equal than the other ones” was, indeed, defined by the needs of the system software, I would expect it to be platform-agnostic. In case if your target architecture does not provide a hardware-level support for this concept, you can implement it in a software really easily. Therefore, if the above suggestion was correct, I would not
expect spl’s (which happens to be sort of IRQL’s twin) lifespan to correlate with the one of PDP11 THAT closely.
However, this is not how the things had actually worked. The very concept of spl() appeared only when interrupt prioritisation feature got introduced in some newer version of PDP11(AFAIK, the earliest PDP11 versions did not have the one - it had been introduced a bit later), and lost any practical meaning when they started porting UNIX to other hardware architectures, subsequently having had disappeared from practically all major UNICes.
In other words, I would rather suspect PDP11’s specifics and not the OS’s needs to be “the key driving force” here…
Sigh. Your command of history seems to be a bit off.
The very first PDP-11 was the PDP-11/20. It was the first PDP-11 to run Unix. It had the same multi-level interrupt prioritization as “later” PDP-11s, such as the (much later) PDP-11/70.
The PDP-11/15 was a cost-reduced OEM-only follow-on to the 11/20… one way to reduce cost was to make multi-level interrupts an option. I don’t know if anybody ever bought a system configured this way, and I don’t know which OSes supported it. There were some funky-ass operating systems back at the Dawn of PDP-11 Time that didn’t last long or morphed into something else (RSX-11A, B and C for instance, and RSTS-11).
“OEM” in this context and era meant a system that was not sold by Digital to end users, and was thus bundled by a system integrator into a larger purpose-built hardware and software solution.
Having been around when interrupt prioritization was an “important thing”, I can assure you that your notions are… misguided. In an era where facts count for little, I’m sure you will wish to continue to champion your incorrect assumptions and assert them as fundamental historic truths.
Having been around when interrupt prioritization was an “important thing”, I can assure you that your notions are… misguided.
In an era where facts count for little, I’m sure you will wish to continue to champion your incorrect assumptions
and assert them as fundamental historic truths.
Oh, come on…
Taking into consideration the fact that,unlike me, you had a first-hand experience with PDP11, arguing with you in this respect would
be a bit to the extreme even by my standards
In any case, it looks like we are agree at least on the following points:
1.IRQL and SPL are sort of “twins”
2. SPL lost any practical meaning when UNIX got ported to other machines, and subsequently want away from all major UNIX flavours
Imagine the amount of Christmas spirit and good cheer that I must possess… I haven’t locked either this thread
The most interesting thing here is that, despite some superficial and insignificant “deviations”, this thread does not really seem to go
anywhere off-topic. Instead, it remains clearly focused on the original topic. I know it may sound bizarre, but that’s the way it is…
unlike me, you had a first-hand experience with PDP11
One of the very few advantages to having been programming long enough to know stuff that is in no longer even remotely relevant to computing and operating systems in the 21st Century (if the discussion of multi-level interrupts isn’t a good enough example of this… how about “overlays”?) is that you can (sometimes, still, even if through a glass darkly) remember how certain things go to be the way they are today.
Consider it a party trick that can be used to amuse (or, you know, bore and annoy) younger colleagues. The primary risk of this trick (aside from rolled-eyes and being told “OK boomer”) is that the younger colleagues often decide that they know the facts as well as you do, and repeat some nonsense or build some intensely incorrect theory based on invalid assumptions. Witness the current discussion.
[As an important aside… I hasten to add that there is an entire generation of OS devs who are (MUCH MUCH) older than me who are still writing code, for better or for worse. Cutler, for example, is only a couple of years shy of 80. I also recently met one of the original RSTS devs (speaking of PDP-11s), who is still writing kernel-mode code and is working as a key guy in a pretty interesting multi-national startup.]
arguing with you in this respect would be a bit to the extreme
As an aside, learning about the decisions and their consequences of the past can be an invaluable source of knowledge. Generally judgement comes from experience, and generally speaking reading competent history is a much faster way of gaining experience than actually living all that time and doing all of those things
