natiiix wrote:iansjack wrote:Memory allocation, interrupt allocation, ABI, registers reserved by OS, library format, etc., etc.
Memory allocation isn't necessary for this particular driver,
Setting aside the matter of whether it is necessary or not (you might end up being surprised later on; a practical driver will almost certainly need to be able to allocate buffers at some point, above and beyond any passed to it by the calling process), whether or not it
can allocate memory, and how it would do so if it can, is in fact a relevant issue, as it places requirements and limitations on how the driver can work.
natiiix wrote: interrupts are nowhere to be seen in the example on Wiki,
That fact alone should make you reconsider the claim that the driver is complete. Unless you intend to drive everything by polling - which would limit your use of AHCI to a subset of the standard - it will need to be set up to work with interrupts eventually, and that will in fact affect the design and maintenance of the driver.
So why doesn't the example show how to use them? Because they are OS-specific, as we have been trying to explain - not well enough, apparently, but hopefully we are getting better.
natiiix wrote:no idea what ABI is
Application Binary Interface, that is to say, the form which things such as system calls need to take as binary executable images and register states (for example, the INT 21h soft interrupt is one part of the ABI of MS-DOS). It also includes things like
Calling Conventions, which are needed for calling procedures which aren't part of the same compilation unit (and are usually used even when they are). This is in contrast to the Application Programming Interface (API), which would be the form that the calls take in source code (things like function prototypes, data structure type declarations, etc.).
Any operating system defines an ABI, whether explicitly or implicitly; but if you don't
explicitly define one, and document it (even if only for your own use), then you won't have a clear idea what the requirements and limitations of it are, and will be working blind.
In the case of a driver, it would be the way that the kernel (or an application, depending on how you design things) calls on the driver, and the way that the driver in turn passes the results back to the caller. Things like how you pass a pointer to a buffer full of data to be written, how you tell the driver which Cylinder/Head/Sector to read from or write to, and how it passes back a pointer to a buffer full of data that has been read in, would be part of the ABI.
natiiix wrote:no such thing as reserved registers,
Actually, yes there are, at least if your OS is running in protected mode there will be. The set of protected registers might only include the
control, segment, debug, test, and page/interrupt table registers, but unless you are giving Ring 3 applications (that is, processes with limited privileges, as opposed to kernel processes in Ring 0 which have few if any restrictions - Ring 1 and Ring 2 are available in the x86 but aren't used by most OSes) direct access to those registers somehow, they are indeed OS protected registers. Most systems also have rules about how the other registers can be used as well, at least in the context of calling conventions and other aspects of the ABI (see above), which really need to be stated explicitly if you don't want to paint yourself into a corner.
natiiix wrote:no idea what library format means.
I presume that iansjack means the formats for
Object Files, code archives (libraries), and executable files. Things like
ELF (the format used by most current Unices, including Linux, as well as the majority of hobby OSes),
a.out (a much older Unix format, now largely abandoned),
COM (the small-memory-model MS-DOS format),
MZ (the older MS-DOS .EXE format),
COFF (an older Unix format which became the basis for PE),
PE (the format used for Windows .EXE and .DLL files), Mach-O (used in MacOS X), and so forth.