Indeed, and instead of simplifying things that might even create new complications, if different one-on-one solutions conflict with each other.ooPo wrote:Fix the problem, don't work around it on a one-by-one basis. That's how code becomes unmanageable and overweight.
(eg: unrelated partition types identified by the same "PP." prefix.)
However, fixing "the problem" as you say (and I agree with) demands that this problem be clearly defined. Hopefully this discussion will do exactly that. (Not through my own post of course, but eventually.)
I'm not well enough informed on the low-level details to contribute any solution. But it seems clear (both from those delays, and from earlier posts about HDD access functions) that current methods to access just a single partition is done in a way that wastes time by reading info *from* several partitions, rather than just reading info from the partition list to identify those partitions. Surely that must be the hub of the problem, regardless of the 'depth' of the routines that contain the code doing it.
Obviously, the existing API must remain unchanged, to avoid breaking compatibility with all existing HDD software, but that should be no hindrance to adding a new lib (or new functions to the old :) ) specifically to allow more efficient HDD access. And naturally this should deal the same way with ALL partition types, with no special treatment for any.
Best regards: dlanor