i seek a way to load a binary file using path.

but path means... file system, and i still don't have my own file system.

fat32?
fat12?
ntfs?
ext?
etc???

when i see that file systems are all different, and maybe more or less independant from the bootcode... maybe it is a good idea to make a dual load in the bootloader.

first load the file system lib that starts in the second sector, or elsewhere...
second, load the file using the file system lib freshly loaded.

then, when you will modify the boot sector, you will not need to modify the file system routine.

you will be able to install the same bootloader, on any drive, with any file system, assuming they all have the corresponding driver installed on them.

All OSs I know of support booting off of only one or at most two FS(s). Bootloaders are usually FS-dependent. If you want to support more than one FS, simply write two (or more) different bootloaders and give the user the option of installing either one of them when they install the OS.
A 1 sector bootloader is more than enough to load files. It's done in virtually every existing OS. It doesn't really take that much code to read and traverse the entire FS hierarchy. You only need a very basic read-only support at that stage, i.e. sector reading routines and a lot of loops and checks depending on the FS structures you're reading and parsing (BPB, superblock, FAT, MFT, inode table, root directory).

On the other hand, the entire first track (minus the bootloader) is often kept free of data and boot managers (for example) usually fill that space with their own code so you could very well use it too.

It's your OS, write it as you wish...

In my opinion the best option is to create one read-only plain partition for kernel, drivers and all the stuff that works in priviligies level 0, and modules that work as regular applications(GUI, etc) should go to any other partition.
This should provide security for kernel, driver, etc and free you from writing FS driver in bootloader

My boot images construct their own FS but calculate absolute LBAs for the boot sector/loader to use to load the core, system and basic drivers. Higher up, the proper FS handling will be used and can access the full FS not just those particular files I've selected. I find this a nice lazy shortcut (it also means I only have to implement my FS once which is designed towards 64bit rather 16/32bit)

A stage 1 boot loader is boot device and file system specific. You could use call back technique for access to stage 1 boot loader's API. But this technique has two essential lacks such as RM (maybe only for me) and small size of boot loader in some cases that is reason to have no support for paths (only reading from root dir is supported).

Other way is to load two files instead one from root dir by stage 1 boot loader. The first one could be a stage 2 boot loader and the second one could be a driver for specific boot device and file system. I use this technique in two variants:
1) to load basic system modules from root dir I just load kernel and PM boot device and file system driver by stage 1 boot loader;
2) to load basic system modules from other than root dir I load stage 2 boot loader and RM boot device and file system driver by stage 1 boot loader and then I load kernel and PM boot device and file system driver by stage 2 boot loader (which use a specific RM driver).
Or the first file could be a stage 2 boot loader for specific boot device and file system and the second one could be a configuration file for this boot loader.

All long journies start from words "I know a shortcut"

The keyword here is nice In this case, the additional code for proper implementation would violate the lowest common multiple of 512 byte sector devices.

(Nasty shortcuts are my page mapping code )

Also, How do file systems map 'free space'???

Different FSs use different methods. One easy and efficient one is to use bitmaps. Check the See also section at the end of the article for other methods.

Thanks!!!
I'll to mix B-tree and bitmap cuz b-tree is complex and bitmap is large

One more question:
How do I edit files that located in my FS ???

Using an editor of some kind (text, hex, etc.) that calls FS-independent file operation functions (e.g. open, seek, write, etc.) that call FS-dependent APIs that call low-level disk routines (e.g. write block).
In case you were wondering how big that is, the code used in everything except the editor is probably 1/3 (or more) of the entire OS.

if you're wanting to learn how to design a FS in entirety I'd suggest reading Practical File System Design with the Be File System