actually if you sort of "remove" the boot from usr/src/boot path, thats the root you can see in bsd; I used this layout for initial tree setup to simplify tracking of original sources in "first phase". I do agree, it is a bit artificial and not the ideal from point of view of overall source tree we got. I have been thinking about relocating bits to more proper place - including moving the string functions in boot/lib/libc to libtsand etc, but after having little chat with Jeff, I figured I would rather leave this for "second phase", otherwise it is quite hard to see what was brought in and why those rearrangements are done. in bsd the boot loader itself is actually in "kernel" tree - usr/src/sys/boot, where sys is their "uts".

I guess I'm more interested in that "second phase" result then, having the final version of what you propose to put back in to the gate.

I forgot to add, I actually already have moved one build tool used by loader - btxld to our usr/src/tools, its originally located in boot/i386/btx tree - but its really small piece.

There is also the concern and confusion in our current tree; grub itself is in usr/src/grub, while its actually standalone and should not be there - ok, from my point of view the grub is dead and does not matter. 
Then we have usr/src/stand and usr/src/psm, with sparc related code (forth bootblock etc) is mostly in psm. In a sense, the loader and its libstand would really belong where standalone bits are. 
Also for time being I have kept around the acpica and compression libs - eventually we should have single instance for both, with compression it would be easy to do even now, but acpica has to wait till devs working on its update will sort it out, which is also why I hope to see usr/src/common/acpica, but thats another topic.
And finally, I think the more "cleanup" would be in order in sense that the bsd code is mostly trying to use libstand specific headers, but some are bsd public headers, and I think we should get this code changed to more "native". But then again, its more work for future so more people could be involved, but also, it means we need somehow get the baseline source to gate.
Surely, I can go on with polishing those bits forever (or till I get bored, whichever will happen first), but really, this is not work for one person and I have already spent 2 years on this whole topic. For conclusion - I really dont need to get another bike-shedding about which bit should belong where even before this project has chance to get to gate. For reasons given above, I would rather go for one single baseline import now, and then work out the proper final locations on followups. As I wrote in list - this is not final "product", its just about the beginning of the road and if we want to get anywhere on that path, we should start walking.

Actually it is a bit bad plan I think - the current fbsd cstyle is also using 8 char tabs, and the style conversion in general is happening on the go. It does create a bit of mess in between, true.

Essentially its setting the rate of -|/ printout sequence to produce spinner in between operations. While reading larger files we want to have indicator the loader is still alive and working but what I have found is, while reading large files, too frequent spinner printout will add noticeable delay:) So the actual value is balance between having reasonable feedback and not delaying file read too much. For example this change did save ~5 seconds in case of smartos boot archive loading;)

Thanks for the explanation!

yes, and integrated.

oh, yes, its leftover from experiment, sneaky one has managed to slip in...

Ah, you have missed the update sprintf -> snprintf, which also fixed the spaces;)

yep, however, I think, even if this workaround is ugly, I would rather try to keep the build tools as they are and wait till the tools will get more sane. This way at least we have predictible build environment, without surprises... I'm more than happy to revert the change once we have sane nawk.. ;)

I just checked, and /usr/bin/awk refers to oawk on OmniOS, which won't support some of the things used in this awk script. I think changing it to /usr/xpg4/bin/awk is the best solution here.

I think you are right here, did revert merge_help.awk and set AWK=/usr/xpg4/bin/awk in i386/loader/Makefile.

the header is in usr/src/boot/sys/sys/vtoc.h, as it appears, our vtoc (or now dk_label) and vtoc8 in bsd do have same roots (and also relations to AT&T SVr4, as it appears from comments in our /usr/include/sys/dklabel.h), but with some differences... So I did decide to leave vtoc8 as is, and did add dk_label instead. However, the current modern fbsd is rather using either mbr+bsd label or gpt.

yea, well, actually this whole autoselect code is useless for us, but as long as its here, you are right. The fbsd boot code is built on reading the partition table and about deciding what to use based on partition type/flags. Our current grub and also loader are using pre-recorded LBA based approach (loader actually also does have partition browsing as fallback). So in sense it is sort of historical trash, but I would really leave it for future cleanups otherwise;)

The whole efi branch right now as of this update is reference code only, and not targeted for actual build. Most of the issues also pointed here are already addressed in followup development and therefore I would rather leave those files as is for now.
The reason for not including efi branch now is simple - without updates to kernel (frame buffer console support, avoiding accessing bios calls and data), the efi code is still unusable. However, it will provide the base for future commits.

yes, those are from Intel headers, I did add to help the debugging. I haven't pushed them because in current form they don't provide too much value for upstream, and some of listed UUID's are already received updates from upstream, with implementation of additional features.

another sneaky one..

well, this whole nvram command will get replaced later (as part of rework for variable support in freebsd), so, I just will leave it as is for now..

We actually have it, just the approach is a bit different. FreeBSD is reading BE list directly from zfs (dataset list), but since our libbe is using file based approach (<boot pool>/boot/menu.lst), I did implement BE support by reading the menu.lst file instead - the reader code is in beadm.4th. The idea is to make sure loader and OS does have exactly the same view on be list and its order. While reading dataset list directly from zfs would allow to drop menu.lst file, there are two "but's" - first I'm not entirely sure about dataset ordering in zfs zap, it may be the timestamps would be needed to be checked (which would add extra code into loader), also using menu.lst based approach will give us exact match with sparc, as it is in fact the same file and method used in case of sparc.

Ah, that makes sense. Thanks for sorting all of that out!

this one also is having its changes waiting already...

quite so. To support different coonfigurations, the FreeBSD implementation does provide multiple alternate stage files - this is due to various size limits, and historical background. Since our primary rootfs is zfs, I see no reason to keep the multitudes of modules and have consolidated to provide single mbr, stage2 (gptzfsboot) and loader binaries (+ cdboot and pxeboot as those are for specific cases). Also to provide full zfs support, I do build stage2 against libstand, which does increase the size of the binary, but also did remove the need for duplicated code. There is still some cleanup to do, but I leave the cleanup for later phases of the project.

actually yes, and I just figured I need to update it. This version was left in from efi builds, which was sharing the biosacpi.c with bios loader. Later I did create separate (simpler) implementation in libefi, as for efi we dont really scan memory to find tables, the pointers are provided in efi system table. So I have updated this code to drop unneeded efi bits. Of course in illumos case the extracted information is just for humans, fakebop.c does its own magic to extract acpi.

originally it was to keep in mind there are different address mappings for efi and V86 bios loader, removed this argument now as its not needed any more.

for this one: warning: assignment makes pointer from integer without a cast

As I did comment before, we dont read BE list from dataset list:)