>> My terminology is compliant with that definition. > > *Sigh* > > I am aware of that. The general term "re-entrancy" is not synonymous > with the specific term "reentrant kernel".
So re-entrancy is not synonymous with re-entrancy? Or the definition of re-entrancy when applied to a kernel is different than the definition when it is applied to something else? Or the definition you supplied doesn't apply to kernels? > I do not wish to seem mean, but when I say to you that you are not > explaining this well, it is not a useful or constructive answer to > acknowledge it and then go on to say "well this backs me up" > followed by "but that is not what I mean". I'm saying that if you apply the definition you supplied to kernels as they currently exist they are not re-entrant. > Brent, I am a professional explainer of hard concepts. It's my job. > I get paid for it. I am not here to try to decode what you are > talking about and then explain it better. That is what I get paid > to do and you are not paying me. I am telling you, gratis, that your > explanations are lacking, and rather than an essay-length response, > a better one would be to _come up with better explanations_. It's Bret, not Brent. And I will attempt a better explanation below. >> I haven't redefined anything. Individual subroutines may be re- >> entrant but the entire kernel itself is not. > > When the industry considers that all mainstream OSes have reentrant > kernels, _yes it does_ and you need to find some better > explanations. > You are not doing that. So, something is true because "everybody else says so?" Let me try to explain with a thought experiment. Currently, there can be only one bootable device on a computer (usually one of the partitions on the hard drive, whether it be MBR or GPT). Let's say that instead of it working that way, there could be multiple bootable partitions. While booting, each bootable partition is "given" (by what one could at least potentially call a "BIOS") its own CPU/core to use while it is booting, in addition to its own independent chunk of memory. All the different OS's could boot at the same time since they are independent of each other. Of course the BIOS would also need to somehow "divide" or "share" the other hardware resources (in addition to the CPU's and memory) among the different OS's, but that is another matter. We are discussing re-entrant kernels. Let's take this a step further. Let's say that you set it up so that a single partition could boot multiple "copies" of an OS. For example, the BIOS would provide three different CPU's to the bootable partition and tell it to install three independent "copies" of Linux. The _same_ kernel would boot three independent Linuxes at the same time. The kernel would need to be re-entrant since three different CPU's would be accessing it at the same time. This is sort of the opposite of what happens today -- instead of the OS controlling the CPU(s) the CPU/BIOS "controls" the OS. Or, as an alternative, the BIOS could only provide one CPU but still tell the kernel it wants three "copies" of Linux to boot. The kernel could boot each "copy" of the OS sequentially (in which case it wouldn't necessarily need to be re-entrant) or could boot them concurrently (in which case it would need to be be re-entrant). Those scenarios are what I would call examples of re-entrant kernels. Call the idea stupid or insane or impractical or whatever you want, but that would comply with the definition you provided of re-entrancy. For whatever reason (mostly, I think, just "because that's not the way it's done"), in today's world the "boot" part of the kernel is not considered part of the kernel, at least when it comes to the concept of re-entrancy. > Allegedly, Einstein said: "If you can't explain it simply, you don't > understand it well enough." Is that explained well enough now for you to understand? >> E.g., you can't have the _same_ copy of the kernel running on >> multiple CPU's concurrently > > Multiple cluster OSes do that, such as Plan 9, Inferno, and > Parhelion HeliOS. > > https://www.theregister.com/2021/12/06/heliosng/ Again, not what I'm talking about. See above. >> The problem is, the CPU's _themselves_ really haven't gotten a >> whole lot faster than they were in the 386 days. > > Drastic oversimplification to the point of not being true, accurate > or representative. *Sigh* Let me give you some actual data to back up my claim, shall I? The computer I'm currently using is a few years old, old enough that I can boot DOS on the actual hardware. The CPU is an Intel i5-4590 running at 3.30 GHz. I have a DOS program I wrote a long time ago, called SLOWDOWN (and hope to find time to "update" it in the future). The purpose of SLOWDOWN is to slow the computer down so that DOS applications don't "blow up" because the computer is too fast. It's not a perfect solution, but is useful in certain situations. One of the things SLOWDOWN needs to do is figure out how fast the computer is running so that it can slow it down the correct amount when you want to do that. So, SLOWDOWN can sort of be used as a "benchmark" to see how fast your computer actually is. For my test, I compared how fast my current computer runs (with a 3.30 GHz clock speed) against a 33 MHz 386 CPU (which I measured way back when -- I don't have access to that computer any more). At least in theory, because my current clock speed is 100 times as fast as the 386, my current computer should run _at least_ 100 times as fast as the 386 did. Also, at least in theory, it should be even faster than that since the new computer has a cache and the 386 didn't, modern CPU's take fewer clock cycles per CPU instruction, etc. In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the 33 MHz 386 did, not more than 100 times like you would expect. I then ran a second test where I disabled the cache on the CPU (you can do this with my CPUCACHE program which is included with SLOWDOWN). This is a more "apples-to-apples" comparison of the _actual_ CPU speed than the original test with the cache enabled. When I did this test, the computer ran almost exactly the same speed as the 33 MHz 386 (it was about 3% faster, not 10,000% faster as "logic" would dictate). There is something VERY wrong going on here. I suspect you may not believe my results, but they are nonetheless real. So, given this real-life data, how exactly is what I said untrue, oversimplified, inaccurate, unrepresentative, or any other similar adjective you would choose to use? According to the theory, what I said can't be true, and yet it is. I'm sure somebody will claim something like, "modern CPU's are optimized for modern applications so you can't expect them to run old stuff, like DOS, very well." Well, I think it's pretty unreasonable to expect a modern 3.3 GHz i5 CPU to run at almost the exact same speed as a 33 MHz 386 and with a straight face say, "it really is more than 10,000% faster -- you're just not looking at it the right way." As they say, the proof of the pudding is in the eating. Let me ask you a few questions. One of the things I said was that the main reason modern CPU's seem so fast is because of "tricks" like pipelining and caching, and you seem to indicate that you don't think that is true. Would you even _consider_ running a modern OS on a CPU with the cache disabled, when the actual, verifiable data shows it would run about the same speed as in the 386 days? The next set of questions relate again to what I mentioned previously. What if modern CPU's were super high-speed 386-class CPU's? That is, what if we applied modern fabrication techniques to 386 era technology -- how fast would the CPU's actually be? Let's assume we could fabricate a 3.3 GHz 386-class CPU. Do you think it would be 10,000% faster than a 33 MHz 386? I think it probably would be -- I certainly think it would be WAY faster than my 3.3 GHz i5. And you could probably fit dozens, or maybe even hundreds, of them on a single die. > I'd say Koomey's Law replaced Moore's Law circa 2007-2008, when the > x86 industry went through the multicore transition. From ~1975 to > ~2005: CPU bandwidth approximately doubled every ~1½ years. Since > ~2005: bandwidth increases ~10% every 1½ years. Does that matter if it doesn't actually do anything useful in the real world? CPU bandwidth seems to be pretty much irrelevant based on the tests I delineated above. What seems to matter way more are caches and I/O (SSD's have been a big boon to speed that has nothing to do with CPU bandwidth). >> That is not what you are saying. > >> I know it's not -- it's probably not clear to most people since >> it's it's a completely different way of thinking than what they're >> used to. And again, I'm not saying that it's a "good" idea or that >> it should even be implemented -- but it can at least give a >> different perspective on how things _could_ be done. > > I suggest you watch my series of talks at the FOSDEM conference from > 2018-2020. Maybe. > Not because I am saying I am an examplar of cogent explanation -- I > am not Even though that's what you are paid to do? > -- but because they constitute a fairly serious dive into > alternate OS architectures, while you seem to think I am just not > bright enough to understand your searing insights. Not at all. You are more than bright enough. I just think you, like so many others, have been so entrenched in "the way things are" that you can't even conceive of the way things could be. >> Again, while interesting, none of those are what I'm talking about. > > I know they aren't. I specifically chose them to illustrate how your > attempted explanation was amenable to misinterpretation. Of course -- almost everything is amenable to misinterpretation. Did I explain it any better this time? I fully realize that lots (maybe even all) who read this may think "the cheese has slid off my cracker" (I love that line from The Green Mile) or that "I'm not playing with a full deck." That may in fact be the case, but it could also be that I'm playing with a stacked deck. We may never know for sure. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
