It's Free Software of course, and it only took me about two weeks to do so.
Since I've been doing it in my limited spare time, I might as well brag about it and say that, had I been able to work on this full time (which I sure wouldn't mind), it probably wouldn't have taken more than 7 days... Can't help but wonder how much a proprietary/non-free software development workflow would have had to budget, or outsource, to try to achieve the same thing, within the same amount of time.
At the very least, this demonstrates that, if you start with the the right resource set and, more importantly, if you stop being irrational about how "using the GPLv3 means the death knell of your software revenue stream", a project such as this one can easily and cheaply be completed in a matter of days.
Anyway, the driver itself is read-only (which is all I need for Rufus, as my intent is to use it there) and it could probably use some more polishing/cleanup, but it is stable enough to be used right now.
So, if you are interested in a redistributable and 100% Free Software read-only NTFS EFI driver, you should visit:
https://efi.akeo.ie (the link includes pre-built binaries).
Alternatively, you can also visit the github project page at:
https://github.com/pbatard/efifs
Now, I'd be ungrateful if I didn't mention that the main reason I was able to get something off the ground this quickly is thanks to the awesome developers behind the GRUB 2.0 project, who abstracted their file system framework enough, to make reusing their code in an EFI implementation fairly straightforward.
And I also have to thank the iPXE developers, who did most of the back-breaking work in figuring out a GPL friendly version of an EFI FS driver, that I could build on.
Finally, I was also able to reuse some of the good work from the rEFInd people (the GPLv3 compatible parts), which was big help!
But the lesson is: Don't waste your time with proprietary/non-free software. If you are both interested in being productive and budget-conscious, Free Software is where it's at!
2014-06-30
Subscribe to:
Post Comments (Atom)
Hi, there some APi to be able to read NTFS files/directories?
ReplyDeleteI'm in this situation, I have a code that, using your driver, is able to load an efi image on a ntfs driver from the bootloader image.
Now I need to be able to read the partition to load file in memory. There is any solution, API to do so or I need as you have done use grub?
Please do not post the same comment 3 times. This GREATLY diminishes the willingness for anybody to help you out.
DeleteThere Is no API, but what is being done in UEFI:NTFS project (https://github.com/pbatard/uefi-ntfs) might be of interest to you.
Sorry for the postage. Thanks anyway.
ReplyDeleteSo sorry but I reall can't get how tha driver work.
ReplyDeleteSo now I have loaded the driver an launch another efi image. Can I acess the driver from my code? And If how?
I'm really new to uefi and cannot get informations. Thanks
Was wondering how you were able to build the driver? I'm interested in building an Intel raid driver if possible. Thanks
ReplyDelete@davidm671 - Please see the Compilation steps in the README from the project. It gives you all the details on how you should build the driver.
DeleteHi, How do you apply those patches? trying to compile your ntfs driver in VS2017 and copied latest gnu-efi to the gnu-efi folder, copied grub v2.02 to the grub folder and when I compile I get a bunch of type conversion errors. Must be cause I need to apply that patch? Thanks
DeletePlease use the github issue tracker: https://github.com/pbatard/uefi-ntfs/issues
DeleteI do not provide support through the blog. Thank you.
Why is your driver only read-only??!
ReplyDeleteBecause:
Delete1. It is a byproduct of UEFI:NTFS (https://github.com/pbatard/uefi-ntfs), and I only needed a read-only for that purpose.
2. Its source comes from GRUB and the GRUB drivers were designed to be read-only since there's no need for write when all you are using a file system driver for is chain loading.
Ok. That makes sense. Thank you.
Delete