Create a loader for each interpreter for x86 BIOS and all EFI

[imp]

Summary

Create a loader for each interpreter for x86 BIOS and all EFI

Create loader_{4th,lua,simp}{,.efi}. All of these are installed by
default. Create LOADER_DEFAULT_INTERP to specify the default
interpreter when no other is specified. LOADER_INTERP is the current
interpreter language building. Turn building of lua on by default to
match 4th. simploader is a simplified loader build w/o any interpreter
language (but with a simple loader). This is the historic behavir you
got with WITHOUT_FORTH. Make a hard link to the default loader. This
has to be a hard link rather than the more desirable soft link because
older zfsboot blocks don't support symlinks.

[rgrimes]

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

[rgrimes]

stand/userboot/Makefile

5

Did this sneak in, or are you planning to kill the test subtree?

[imp]

In D16705#355069, @rgrimes wrote:

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

I would object.

We can't install them as loader.lua, loader.4th loader.simp because then we'd have loader.lua.efi, loader.4th.efi etc. Also the .4th suffix is what we use for actual 4th code. So that leaves us with a prefix, even if it is a bit less orderly.

[imp]

stand/userboot/Makefile

5

I noticed that. tests were broken for some reason, so I removed them. Since this is just a preliminary doodle to share with Kyle to see what he was thinking, I didn't worry too much about it.

[kevans]

Seems reasonable to me. This generally lines up with the way we've been verbally addressing these things anyways.

Ditto Rod's comment on the test SUBDIR, but I assume that was an unintended side-effect of working out how userboot's going to work in the new world order.

[rgrimes]

In D16705#355071, @imp wrote:

In D16705#355069, @rgrimes wrote:

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

I would object.

We can't install them as loader.lua, loader.4th loader.simp because then we'd have loader.lua.efi, loader.4th.efi etc. Also the .4th suffix is what we use for actual 4th code. So that leaves us with a prefix, even if it is a bit less orderly.

Ack, ok simple enough reasoning.

[imp]

Update for efi

[rgrimes]

In D16705#355079, @rgrimes wrote:

In D16705#355071, @imp wrote:

In D16705#355069, @rgrimes wrote:

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

I would object.

We can't install them as loader.lua, loader.4th loader.simp because then we'd have loader.lua.efi, loader.4th.efi etc. Also the .4th suffix is what we use for actual 4th code. So that leaves us with a prefix, even if it is a bit less orderly.

Ack, ok simple enough reasoning.

I thought about this some more and have another proposal, that IMHO address your issues and brings a good gain of order to this, my mistake was I used a . to express the separation, but if you use a _ then things are orderly loader_{,lua,4th,simp}{,.efi}. This matches much closer the variable names (MK_LOADER_FOO),
the source directories could be named similar, and the installed binaries match source directory names. It renames /boot/loader to /boot/loader_forth too, which IMHO is good now that there can be N flavors of it.

[imp]

In D16705#355216, @rgrimes wrote:

In D16705#355079, @rgrimes wrote:

In D16705#355071, @imp wrote:

In D16705#355069, @rgrimes wrote:

Would there be an objection to using SUBDIR names of loader.4th, loader.lua and loader.simp so that they sort next to each other vs the current names that scattter them about the directory? This also means that loader.foo/Makefile simply includes ../loader/Makefile all nice and orderly :-)

I would object.

We can't install them as loader.lua, loader.4th loader.simp because then we'd have loader.lua.efi, loader.4th.efi etc. Also the .4th suffix is what we use for actual 4th code. So that leaves us with a prefix, even if it is a bit less orderly.

Ack, ok simple enough reasoning.

I thought about this some more and have another proposal, that IMHO address your issues and brings a good gain of order to this, my mistake was I used a . to express the separation, but if you use a _ then things are orderly loader_{,lua,4th,simp}{,.efi}. This matches much closer the variable names (MK_LOADER_FOO),
the source directories could be named similar, and the installed binaries match source directory names. It renames /boot/loader to /boot/loader_forth too, which IMHO is good now that there can be N flavors of it.

In the past we've had loader and zfsloader. We then grew loader.efi. In powerpc land we have loader, loader.kboot and ubldr from directories ofw, kboot and uboot respectively. In arm land we have loader.efi, ubldr and ubldr.bin (from efi/loader and arm/uboot respectively). There's no real order here.

We also don't have a MK_LOADER_FORTH, just MK_FORTH. And there's no MK_LOADER_SIMPLE (it's just always made, like we used to always make loader). So they don't really match the names all that much.

When the developers talk about these things we talk about lualoader, 4thloader (or forth loader, which sound the same said out loud), which matches what I've done. I used the zfsloader example, but there's really no precedent to do it in any sort of way. It's honestly a mess that's hard to retroactively fix.

And then there's the zfsboot, gptboot, zfsgptboot, isoboot, etc on the 'boot' side of the stand house, none of which are very "orderly"

And then we'd have loader_4th and loader.4th, which to me seems to be a source of more confusion than making things nice and orderly would relieve.

So I'm hesistant with the available data to say that this proposal is clearly better than my proposal...

[imp]

After reconsideration, go with Rod's suggestion...

[imp]

Fix pxeldr for rename

[imp]

no, really fix pxeldr