Bug 228924
| Summary: | LUA loader on by default | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Rodney W. Grimes <rgrimes> |
| Component: | bin | Assignee: | Warner Losh <imp> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | KevinTaylor1544, cem, dteske, emaste, kevans, rgrimes, rpokala, sjg, winifredgibson74 |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 228911 | ||
|
Description
Rodney W. Grimes
2018-06-12 09:04:24 UTC
CC'ing dteske@ Objectively, I think we should provide coexistence for 12.x that I will backport to stable/11. The following is verbatim an outline of what I personally want to see that I pitched to dteske@ in private discussion: ``` FreeBSD 11.3 (in reality, stable/11 shortly after 11.2 is released): - lualoader is considered an experimental feature for folks to try that are committed to 11.x for one reason or another - lualoader and forthloader are both built - forthloader is the default loader, as expected FreeBSD 12.0: - lualoader is a first-class citizen - lualoader and forthloader are both built - lualoader is the default loader FreeBSD 13.0: - forthloader is no more - lualoader succeeds it. In all cases where we offer both lualoader and forthloader, two ways to switch: 1.) From a running system, perhaps a boot.config(5) method to select the loader 2.) From the loader prompt, regardless of whether the interpreter and scripts have properly loaded or not ``` I think this is the optimal path to removing Forth for 13 so that we're not maintaining it for basically the next 10 years. This gives all downstreams and users a reasonable upgrade path: they can upgrade to 12 with the expectation that they can keep Forth locally as their default (if absolutely required) while still having an incredibly easy means of doing QA/testing on whatever Lua modifications they need to make. This is a full five years to get it together before Forth is dropped in FreeBSD 13. Of course, we make it abundantly clear that Forth is going away in 13 and that this should be a priority for them. I'm still willing to offer assistance to anyone that actually needs it in porting their stuff to Lua. (In reply to Kyle Evans from comment #1) This schedule is what I thought I understood as well, other than I was unaware of any effort to bring lua back to stable/11. I support this schedule, I would however like to ask that all merges of boot code to stable/11 at this time be held off until we resolve the hybrid iso boot bug. (In reply to Kyle Evans from comment #1) > FreeBSD 13.0: > - forthloader is no more One comment, I think we should separate this item into whether forthloader is built by default or not, and removing it from the src tree. There are some downstream consumers who have extensive local changes to the forthloader, and we should proceed with care on the topic of removal. (In reply to Ed Maste from comment #3) Keeping it in tree for 13 means that we're effectively maintaining it for almost the next 10 years... Backporting to stable branches until 202{6,7,8} is going to be a nightmare as I'll have to audit all loader changes for "might this break the semantics that Forth is expecting" for the next two full branch lifetimes, unless you or someone else is willing to take up the helm on that. I don't think it's useful to not build something as complicated as forthloader by default. That's not part of the plan. At most, it should be a fallback position, not plan of record. We'll know, though, after we publish the FCP and get feedback on it. (In reply to Kyle Evans from comment #4) I'm not suggesting we keep it indefinitely, just that we need to proceed with care and agreeing with you that we need to communicate clearly to downstream consumers. To me your proposed timeline is reasonable. ed, the plan is to write this up as a quick FCP, publish on arch@ and reach out to people that may be using it at the big FreeBSD hardware vendors like Juniper, Isilon, Panasis, etc. We shouldn't be deciding it in this forum, though we should point people to the decision here. My former employer “Vicor” has a massive infrastructure and I wanted to give them time to migrate especially considering I wrote the Forth stack there and if any problems arise, they’ll likely be calling me to do the work. I do work with them from time to time because we remain good friends to this day. We owe a lot of the stability of the Forth enhancements over the years to Vicor’s infrastructure and I feel that they can help Lua by offering a huge test platform in return. If co-existence is allowed, it is far easier to convince them to do the hard work to rebase their infra to 12. Their infra is so large that they don’t adopt every release. It can sometimes take a whole release to deploy (meaning if they chose to start the day 12.0R is released, it might take until 13 is released to get everyone upgraded). They went from 2 to 4 to 8 and are still plumbing 11. If I can stear them at 12 they may have a fighting chance at adopting something newer than, say 16 for their next jump. For the uninitiated, “Vicor” has tens of thousands of physical systems on a range of hardware dating from ancient to bleeding edge and even one-off systems manufactured just for them. They have immense buying power when they shop for solutions and can really only support vendors that in-turn support their FreeBSD needs. What they do with all those FreeBSD systems is process complex payments to the tune of trillions of dollars annually. It is quite the sight to behold and an amazing orchestration. (In reply to Warner Losh from comment #8) Isilon doesn't and hasn't ever used anything special from the forth loader. We do use an ordinary loader.conf in a very boring way, which should work fine in the brave new lua world. This is now the case. MARKED AS SPAM MARKED AS SPAM |