Open t-w opened 1 year ago
I have a few ideas around the "native" interface. I put a simple example in the ramdisk
branch, where instead of a single native driver option, it is a linked list, and adfOpenDev() looks at each driver in turn, and there are methods to add/remove a "native driver" from the list. It is then used in tests with a "ramdisk" driver, which is just a block of ram, so no on-disk I/O is needed to check the correctness of FS manipulation, and therefore tests run a little faster.
It is possible to go further with this. There is no need for a native driver slot, and special-casing which one is being used. The adf_dump.c functions can simply be another driver, the default one.
There are then two ways to go. Personally I like the first option, but the second is more explicit.
Should there be more error codes than RC_OK and RC_ERROR?
Well, there are, they're just rarely used. Almost all errors are RC_ERROR. A handful are RC_MALLOC. Two are RC_VOLFULL, and one commented-out line attempts to apply RC_BLOCKSUM
Should we review the errors, and start returning the most appropriate one? Do we want a system like most DOSes where the return code of the function is just yes/no, but the actual error that caused a "no" is available, e.g. dev->lastError, or adfGetLastError(dev), or similar?
Should errors be a bitfield? This is how they're defined, but never used in practise. Or should they just be an enumeration?
There is a lot of discussions already about it, I'd expect more, so maybe we can make a place for it (to list, brainstorm and set directions).
Some ideas to (eventually) consider (please update as needed):
file / directory APIs(done)a standard style to implement?changes vs. wrappersissues: #38, #40consistent naming (ie. submodule prefixes) across the library(done)isolating client API from internal one (separated headers in(mostly done, but may be improved)include/
?)eg. for file API, expose only a wrapper over the low level functions(?)devices(done)allow more types of devices (not only one native and "dump"), also custom, user-implementedadd a memory/ramdisk device - useful ie. for testing (see the comment belowunify the device interface for all typesthe type of the device is currently is set inadfOpenDev()
and depend on the name (ie filename) of the deviceinstead: differentiate opening/creating depending on type (need rather different functions as different arguments are needed, eg. filename for dump, size for ramdisk device)make the same device structure with interface also for dump deviceshasRC()
- but it is not used anywhere...)errno
/last error infoEach of these might be a separated issue (or even issues), that could be linked here (so that it is easier to navigate).