Hi,
zaval wrote:
mariuszp wrote:
I have to support FAT32 in order to access the system partition from my OS (e.g. to install the bootloader in the first place). And also, of course, I want to support USB sticks and such.
Of course, I meant, at the OS loader level, where interaction with UEFI happens, you don't need to implement FAT code. And installing OS loader might have been done with the help of UEFI as well by the way, - your UEFI installer application could do it.
Yes. Apart from the OS installer (and possibly OS updates, if the boot loader is updated), the OS shouldn't touch (and shouldn't mount) the UEFI system partition at all. The OS installer can use UEFI's services (and can/should use 8.3 file names anyway).
For boot loader updates; before loading the kernel from your native file system, the boot loader can check for a "boot loader update" (in your native file system) and copy it to the UEFI system partition (using UEFI's services and UEFI's FAT) and adjust any "UEFI variables" so the new boot loader is used next time, and then start the new boot loader.
Also note that some UEFI systems (from Apple) don't follow the UEFI specs properly and use HFS+ instead of FAT; and if you always use UEFI's "simple file system protocol" for reading and writing files in the UEFI system partition you won't have a reason to care if the UEFI system partition is FAT or not.
zaval wrote:
For the kernel driver, it would be better off to follow the official documentation forgetting about both the "linux way" or "patents". imo.)
For the OS's FAT file system code; the main question is whether or not you're going to release a "finished" OS within the next 3 years. For anyone asking about FAT now; it's very likely that there's no problem - they can add support for LFN now without caring about patents (because the software isn't released), and then release the software later without caring about patents (because the patents would have all expired by then).
If you are going to release an OS soon; I'd just use 8.3 file names initially (and add support for LFN later), and if anyone complains that file names aren't very pretty (which is the only valid reason to care about LFN in the first place - it is a "decoration only" feature) just explain to them that it's Microsoft's fault (I'd even have a "Why are file names ugly when Microsoft's extremely inferior file system is used" page in the OS's documentation to inform people that Microsoft sucks).
Note: I suspect that as long as your code doesn't create files that have long file names you can use existing long file names (created by other software) without violating the remaining patents; but this ruins your ability to inform people that Microsoft sucks, so (partly to avoid the hassle of asking a lawyer about this possibility) I wouldn't bother. Cheers,
Brendan