eekee wrote:
@zaval: Did I ever tell you that memory stick you used to justify standards-complience (in another thread) was probably faked? A flash drive which has been reprogrammed to fake its maximum size can't handle any other filesystem than the FAT(s) it's programmed for. Properly-functioning Flash drives generally don't care what filesystem you put on them. This is all well-known by just-about everyone involved with SBCs and/or unusual operating systems.
dood, I was talking about SD cards and the specifications, that they should comply with. USB flash sticks are
mostly formatted as FAT, I meant this - you have support for FAT early, your early users have USB sticks, formatted as FAT, thus they don't need to wipe them out and reformat to try with your OS, everyone is happy. it was a little, but practical objective in favor of having FAT instead of that painfully useless ext2 thing. the farther "discussion" and arguments are pure crap caused by bzt's idiocy. my fault was I got myself in that again.
bzt wrote:
All right, EFI then. My point was (or supposed to be) that the ESP file system is not something that's hardcoded and irreplacable in the firmware; you can change it easily, and you can have a firmware that's 100% EFI/UEFI compliant and 100% EFI API compatible without FAT.
unbelieveable. tell me, are you trolling or maybe it's something worse? no, you can not have it compatible, since ESP is always FAT32. read the f&cking specification already! here is the excerpts for you, for version 2.7. page 662, section 13.3 File System Format, and no, those aren't "addenda", "recommendations" nor "marketing BS embedded by M$, scientologists and reptils", just a legit part of the spec, read it, damn it:
Quote:
EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32 system partition is identified by an OSType value other than that used to identify previous versions of FAT. This unique partition type distinguishes an EFI defined file system from a normal FAT file system. The file system supported by EFI includes support for long file names.
section 13.3.1 System Partition tells you what ESP is.
13.3.1.1, File System Format tells it for you, especially gifted one, with an emphasis:
Quote:
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. What variant of EFI FAT to use is defined by the size of the media. The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system.
come on, I believe you can get it!
bzt wrote:
An EFI application that loads files from the ESP is the same, no matter whether the ESP is actually using FAT or ext2 to store those files (as long as the ESP file system has a driver that implements EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, the EFI app wouldn't know, and doesn't have to know which fs is it). I have tested this successfully with a small EFI application that read a text file and printed its contents on the console. I was able to run it on a "normal" desktop and on a Mac without recompilation or anything.
so this is your "proof", what ensured you FAT isn't part of the spec? vs. what is clearly written out in the spec. hilarious. okey, if you are so dense, here yet once, this:
bzt wrote:
as long as the ESP file system has a driver that implements EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
is your delusional BULLSHIT! ESP is always FAT32. and FAT is the only required FS to implement. anything else could be "as long as" that protocol is implemented for the FS, but 1) then it's not ESP and 2) not required. if apple marks HFS partitions as ESP, their firmware is not UEFI, if they don't, they just implemented value added stuff. but still their FW does support FAT and moreover, as the spec defines, page 668-669, 13.4 Simple File System Protocol, Description:
Quote:
The firmware automatically creates handles for any block device that supports the following file system formats:
•FAT12
•FAT16
•FAT32
See, it is the only one "automatically" handled - those for which the FW should create handles, through which you access those volumes. no BztFS, no ext2, no HFS+, no "any FS".
it's value added whistles, if you, as a FW provider, let the Boot Manager process boot options, created with non-FAT partitions and it's highly unportable. noone else would support your whistles, so for example in the case of apple, it can make troubles for their users wishing to install another OS - it won't work when the OS would want to modify or create its folders in the ESP in the live session during installation for example. say, you try to install you BztOS on iMac and you booted with the FW and now in live session, your user chooses to install BztOS, and your installer wants to create \efi\bzt folder. for putting there bztosloader.efi and bztwolflogo.bmp. and then whoops, the "ESP" is not in fact ESP, apple thought different and pooed in your shows. cheers!
I am stunned by this. for one things people scream about "violating standards" and how bad it is, but for other things the very same people see it as OK and moreover, show standard violation as a "proof" of their truth. "oh, I took that iCrap and it worked just fine without FAT, it's the proof, FAT is not needed" seriously? then who the hell decides what is UEFI, if the spec saying clearly, loudly, spitting in your face "no, f&cking sh1t, you should use FAT32 as ESP" is not?