On Thu, 9 Mar 2023 at 22:29, Bret Johnson <bretj...@juno.com> wrote: > Or the definition of re-entrancy when applied to a kernel is different than > the definition when it is applied to something else?
*Yes*. Words in isolation mean different things than they do combined with another word. A "tea spoon" is a size of spoon, and the word "tea" in that phrase has no connection whatsoever with what you do with the spoon. > I'm saying that if you apply the definition you supplied to kernels as they > currently exist they are not re-entrant. And I disagree. I think you have some concept of your own in mind, and existing code out there that people are discussing and talking about with existing terminology does not fit your thinking so you are saying it's wrong and people are misusing the term. That is not how language works. It would be a more pleasant world if it were, but it isn't. Dictionaries describe what people use words to mean. They don't set rules. A "beehive" is a hairstyle and is a term of its own which doesn't mean "looks like most modern beehives", and a dictionary tells you what it means, it doesn't say "beehives must look like the hairstyle" or "the hairstyle should be modified to be a box with a wide narrow entrance/exit slot low on the front edge". > It's Bret, not Brent. My apologies for my mistake. > And I will attempt a better explanation below. Is it relevant to FreeDOS? > 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. IBM mainframe PR/SM can do that, and so can one of IBM's systems partitioning tools for POWER servers. > We are discussing re-entrant kernels. Nothing in that paragraph is connected with kernels or re-entrancy as the terms are normally used in this industry. So, no. > 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. Again, firmware level hypervisors on several architectures provide this sort of functionality. You have yet to describe anything I have not already encountered. > 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). Ditto. And this is _not what re-entrant currently means_. > Those scenarios are what I would call examples of re-entrant kernels. Call > the idea stupid or insane or impractical or whatever you want As I said: already been done, and no, not what the terms you are using mean. I suggest reading some more of the history of hypervisors and virtual machines. That is how I wrote my first book, now sadly deleted, but described here: https://www.theregister.com/2011/12/19/short_history_of_virtualisation/ The constituent parts are still up: https://liam-on-linux.livejournal.com/45467.html > Is that explained well enough now for you to understand? Sure. But you are misusing the terms, as others have also told you, and you have yet to describe anything I believe is completely new. > > https://www.theregister.com/2021/12/06/heliosng/ > > Again, not what I'm talking about. See above. Have you got any prior experience or knowledge of Helios? It is _extremely_ obscure and nearly forgotten now. I am not aware of anyone else writing about it this century. For you to just dismiss it like that shocks me. If I were writing the email, I would have had to go and do 2-3 hours reading to just understand the outline of the system and what it did, and I get no sense from your email that you even read the link. I see no useful point in going into the rest of your lengthy email if you're not going to treat mine with the same respect, TBH. If you are able to engage in some serious discussion of pipelining, scalar vs superscalar CPU designs, the significance of microinstruction decomposition and out-of-order execution, perhaps with reference to VLIW and a couple of examples with some discussion of their differences, and maybe demonstrating knowledge of the R&D area by bringing in the Mill processor, then I'd think there was something to this. But you didn't. You didn't even bring in relevant recently-shipping designs such as Knight's Landing or Larrabee. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
