Daniel Ouellet wrote: [snip some stuff too flattering to repeat] > But reading it, got me thinking to one small section Nick put int there > and if I learn something over time about Nick's writing is that even > small step that you could very easily overlook are there for a reason > and they were really thought about before been put in.
heh. Many people think I write too much. :) > I refer to this "but it should be done now, as usually, the new kernel > will run old userland apps" from the upgrade 3.6 -> 3.7, or 3.7 -> 3.8, > etc. I was very curious about the word "should". Was that there because > of the switch of a.out to elf from 3.3 to 3.4? That's all I could think > about, or is there actually other possibility that when you do the > process remotely for example like I did that the box doesn't come back > to life? The a.out -> ELF conversion was certainly a major example of this kind of issue (though remote upgrades through the a.out -> ELF conversion had other major, near-fatal issues, too[1]). However, there are lots of potential things that could be done on any platform which produces new binaries which won't run on old kernels. Any API/ABI[2] change (a.out -> ELF is just one example of such a thing) could have that effect. We also have a lot of platforms, any of which could have their own little "quiet" API/ABI change that no one bothered to tell me about. I'd rather have one procedure for all platforms if possible, and I'd rather keep the process as consistant from release to release as possible, that way, when this step becomes important, you don't have to notice the "THIS IS DIFFERENT AND REALLY IMPORTANT" note in the upgradeXX file. > I am not trying to pick on Nick's word, I just learn over the years to > actually respect the choice of them a lots! ...for a second opinion, ask some of the translators, who are really good proofreaders. :) However, in this case, yes, they were chosen carefully. This is not a requirement EVERY TIME, but I don't want to have to verify the upgrade process for every single platform every single release. This also follows the standard OpenBSD process when building from source: replace kernel, reboot replace userland, reboot If this process doesn't work, that's a form of flag day, because we always try to make sure that process works. This is just the binary version of that process. New kernels are supposed to maintain some kind of support for old binaries, but by definition, it isn't possible to always support new binaries in old kernels. > SO, I really was trying to think when that wasn't going to work, or what > is the extend of that meaning in the context of the upgrade process. > > I couldn't come up with anything else then the above note on a.out upgrade. > > Any situations it might actually apply? Or are you referring to > applications more then the OS itself? Imagine some new application security technology, similar to W^X or Propolice, which had to talk to the kernel to "ok" an act. The old kernel would not recognize the function call that the new app made, and thus, the app (reboot, in this case) would not run. You would end up with a machine which won't work, but won't reboot, either (whoa. Windows emulation on OpenBSD!). Another example might be some ACPI call might get stuck in reboot someday if/when ACPI gets more supported...again, same issue, the old, pre-ACPI kernel wouldn't know what to do with them. (note: I'm not a kernel hacker, I really have no idea how plausable the stuff I just babbled above is, so either or both of those examples might be totally bogus.) Developers reserve the right to make changes like that at any time, they could be more subtle than a complete binary format conversion. IF there is some reason you have to complete an upgrade in one reboot, or faster than the local boot media process goes, you might want to try the above referened footnote [1] below. (and if that sentence doesn't cure you of this delusion that I always write efficiently, concisely and clearly, I am sure there are other examples in this note. :) Nick. [1] http://www.holland-consulting.net/obsd/aout-up.html [2] API/ABI: Application Program Interface, Application Binary Interface. How programs talk to each other and the kernel. Guess the binary part would be the only "critical" thing in this case, however.
