In D9520#196825, @allanjude wrote:

Once you get someone to verify this works on an ARM device, approved.

In D5992#195948, @allanjude wrote:

Can you add some instructions or a man page explaining how to use it? (and how one would test it)

off_t -> uint64_t

svn update to 313337.

svn update to 313329

In D9430#194891, @imp wrote:

In the past we've only used this where it makes sense.
That's because in the past -Os has often resulted in either mis-compiled code or has resulted in larger binaries than w/o it.
I suppose it is OK, but I'm leery since this touches every single architecture.

In D9430#194891, @imp wrote:

In the past we've only used this where it makes sense.
That's because in the past -Os has often resulted in either mis-compiled code or has resulted in larger binaries than w/o it.
I suppose it is OK, but I'm leery since this touches every single architecture.

Check also D7600 - I did try to take on -Os there, but it is a bit mixed up with crypto stuff. Maybe some ideas are useful in your work.

make buildworld TARGET_ARCH=armv6 is clean.

Inserted the comment about idea behind the RE size setup.

svn update to 313091.

svn update to current state.

svn update to revision 313042.

realloc() need to use temporary variable for result check, or
we will get memory leak.

use realloc(), add missing \n.

usb disk ioctl should provide DIOCGSECTORSIZE and DIOCGMEDIASIZE instead of
IOCTL_GET_BLOCK_SIZE and IOCTL_GET_BLOCKS (which are not used by anything).

rebase on r312374, updated the NULL checks on efi_devpath_last_node()
and efi_devpath_trim().

fixed the copyright line

In D9179#189633, @allanjude wrote:

Approved for commit

Maybe wait 72 hours for other reviewers though

In D7589#189590, @eric_metricspace.net wrote:

With partition - filesystem mapping we can get the device handle without much issue - the handle stack has handles from FS down to partition and disk handle and the api to access the next handle from stack is there.

With zfs the situation is much more complicated as it is dual disk and file system and we need interface to access BE list and to switch the "current" filesystem on top of the "disk", and UEFI api itself does not help us there. It is possible to create specific protocol on top of zfs pool to implement an mechanism to get information about BE's and to switch, but it means that instead of reducing complexity, we are adding more.... note that the dataset list specifying BE's can be quite long, on my dev host I currently do have 73 entries.

Also, as I already wrote, for human operating the machine, it is really important to know exactly what I'm going to boot from.

So what I did was use the COMPONENT_NAME2_PROTOCOL interface to report back the names of the devices. The raw device to EFI layer now installs a COMPONENT_NAME2_PROTOCOL interface when it installs the SIMPLE_FILE_SYSTEM_PROTOCOL interface.

The COMPONENT_NAME2_PROTOCOL interface currently uses code borrowed from the dev_print methods from the efipart and zfs underlying drivers. We could possibly refactor the dev_print method or add a new one in the future to make this a cleaner integration, but I want to avoid adding more refactorings than necessary here.

In some cases (such as when the firmware has installed a SIMPLE_FILE_SYSTEM_PROTOCOL), you'll get a handle with no COMPONENT_NAME2_PROTOCOL. In this case, it does the default behavior from before.

Also, on verbose mode, it prints out EFI device paths as well.

In D7589#180702, @eric_metricspace.net wrote:

In D7589#180667, @tsoome wrote:

ok, got it built, and initial test. And there is this problem...

OK lsdev

EFI0:    EFI(SIMPLE_FILE_SYSTEM)
EFI1:    EFI(SIMPLE_FILE_SYSTEM)
EFI2:    EFI(SIMPLE_FILE_SYSTEM)
EFI3:    EFI(SIMPLE_FILE_SYSTEM)
EFI4:    EFI(SIMPLE_FILE_SYSTEM)
EFI5:    EFI(SIMPLE_FILE_SYSTEM)
EFI6:    EFI(SIMPLE_FILE_SYSTEM)
EFI7:    EFI(SIMPLE_FILE_SYSTEM)

net devices:

net0:

OK

Yeah, that's problematic. I guess we're back to the question of what should go here: EFI device paths, or something else?

There is an EFI interface that allows a descriptive name to be attached to an arbitrary EFI_HANDLE. Perhaps this could be added as part of the probing process.

Second problem is that the devices are sorted by file system type, So first I get my 4 EFI System partitions (I have 4 disks on this VM), then the rest.

I gather they should be sorted by disk or partition, then? This should be relatively easy to achieve.

Third one is that for some reason it does list root directory, but not subdirectories - probably because:

? 270 dev
? 5 opt
? 20 kernel
? 3 code
? 2 raid
? 2 rpool
? 187 lib

the ls -l does see the size, but not an type, note this is zfs.

Probably an oversight. Actually, I seem to recall something about the EFI_SIMPLE_FILE_SYSTEM interface making you have to open a file to find out its type. I probably intended to add in file types later, but never did.

And finally, for some reasons sometimes the ls was running really slow - not always.

But the disk and file system identification is huge issue, because from current snapshot I can not get even the size hints;)

So, it is very impressive work, but it will take a lot still:) Well, it should be possible to use the disk+part interface I did and relate the file systems with actual partitions... but still there is huge question about identification, and for zfs case - as an admin, I really can not lose the boot environments....

OK, seems I've got some more work to do.

libefi/Makefile needs to build efi.c even without BOOT_FORTH

ficlEfiSetenv() already does initialize the string variables

In D8710#189382, @ae wrote:

I don't remember why I chose off_t, but AFAIR, daddr_t is signed and used in many places.
Also there was a small tool in the tools/tools/bootparttest, that may need in some changes, but it seems it is already broken by some early change.

updated struct dentry

Updated to revision 311995.

LGTM

Factored out the set_nfs_read_size(), as the r305588 did miss the fact
we have not one but two versions of nfs_getrootfh() and we need to set
the nfs_read_size in both.

Seems good, I think.

Filter out nested partitions. At least AMI does create device tree like:
../Sata(..)/HD(1,GPT,...)/HD(1,MBR,...) for PMBR entry.

IMO it seems to make sense, but there is the question, how much testing have you done, any class[less] tests?

There is an problem - not enough context. You can use arcanist, or just tell svn diff to include more {all} lines.

In D8710#180823, @jhb wrote:

size_t doesn't work since it is not always 64-bits. OTOH, uoff_t gives an unsigned off_t so it might be a natural fit for having an unsigned off_t-sized value.

ok, got it built, and initial test. And there is this problem...

In D7589#180599, @eric_metricspace.net wrote:

OK, based on others' reproduction of tsoome's issue on -hackers, I have a credible diagnostic theory.

The new EFI code will try to attach filesystem drivers to every partition, and will end up trying every driver on any partition that doesn't actually contain a filesystem it can recognize. The most obvious example of this would be freebsd-boot partitions containing BIOS boot code. Another would be something containing a non-filesystem. If there's a bug in the dosfs code, this would likely trigger it.

The reason I couldn't reproduce it is that my UFS partition got detected as UFS first, and my dosfs partition was bound by the firmware, so it already had an EFI_SIMPLE_FILESYSTEM interface before the boot code ran (so it didn't probe the partition).

The coup-de-gras here would be to either commit the fix for the dosfs bug, or else disable the dosfs driver and see if it still hangs.

Another issue: since the UEFI spec guarantees that a driver exists which attaches an EFI_SIMPLE_FILESYSTEM interface to any FAT32 partition, do we really need our own dosfs driver in the EFI boot loader? I would think not.

In D7589#180576, @eric_metricspace.net wrote:

tsoome, can I get you to build and test with the extra_logging branch on my github repo: https://github.com/emc2/freebsd

The CFT turned up someone who's having the same error, and I have a few possible root causes I suspect. The extra_logging branch has some extra logging that should help track it down.

In D8710#180507, @imp wrote:

So why not size_t in all the right places?

bd_ioctl changed off_t to uint64_t