Re: [hatari-devel] Replacing direct file system access with an abstraction layer?

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


> #define File_ftell ftell

I see that as a potential "quick" solution to trying to make an adaptation like mine, but I don't think it's beneficial in the long term.

You mentioned one case, but there are several places in the Hatari code that are trying to redirect low level functions like this with #define, and it was actually a bit complicated to sort out which functions/structures were really secretly something else. There are places in the code that are using file functions/structures that have the same names but are actually incompatible renames of different things, independent workarounds.

At least for my adaptation, I much prefer to see what I am replacing, rather than #define and hope it's doing the right thing globally. It allowed me to review exactly what I had to replace and why. I think trying to use yet another layer of #define renames on top would only make future maintenance even more difficult and error prone.

I feel like the long term goal should be to remove such #define renames where possible, allowing them only as an interim solution, or where it's otherwise impractical.

So, what I am proposing is not a #define rename. I'm proposing to replace all direct filesystem use with an explicit Hatari-provided interface. I would rename fopen in-place and not hide its redirection. We wouldn't have some code using fseek and some code using fseeko. All the posix filesystem implementation can go into a single code file providing the interface implementation, and the majority of code would only need to know about "file.h". We would need far fewer platform-specific library includes and workarounds in many files.

For the most part it would simply a function like fopen with something with a very similar name. Make it all go through one interface so that it's easier to audit and maintain as a whole.

Performance-wise, the wrapper function for the abstraction would become a very small overhead, but I think a trivial one? Even if it wasn't, actual file system calls are sparse and not performance critical.

That's my question, whether anyone else would feel that's worth doing? I've already had to gather most of the information needed, and my adaptation basically accomplishes it by different means, but I want to know if the main project would want to have this change before investing time into it.

-- Brad Smith



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/