Here are my comments on the IOSK LM spec.This is where LMerror takes place. The point is that the application cannot know in advance which and how many kind of errors an LM can report. The traditional apps do the following:1. My biggest complaint is error reporting. Look at these functions:
Say the printer is out of paper. Wouldn't it be nice if the spooler
application (actually, coming to think of there's nowhere in our design
where
we've put the printer spooler... I guess that has to do with OpenDoc) would
be able to print a nice dialog box on the screen, "Printer is out of paper" ?
rc=TheFunctionThatBothersWithADeviceDriver();
if(rc<0) {
/* An error is occurred, determine which type
*/
switch(rc) {
case PAPEROUT:
printf("The paper is out: check printer\n");
break;
case ERROR:
printf("Generic printer error\n");
break;
}
}
This implies that if you update a device driver adding a new error check,
you must modify ALL the apps that use it. Also this implies a lot of burden
on apps programmer, because he/she must think of anything.
In the LMerror scenario instead:
rc=LMwrite();
if(rc==FALSE) {
LMerror(&errorType);
printf(errorType.cause);
}
with a total decoupling of device error handling from app. This is *good*
because a) app programmer knows nearly nothing about actual device b) only
the device driver know exactly what's happening.
In this way we report *exactly* what's happened, and in the maximum
detail, and app knows an error it's occurred, which is in firsrt place
what it wants to know. Then, when app needs, calls LMerror to know more.
Just now has popped in my mind a very beautiful feature: error
recovery. LMerror can report also an error recovery strategy, i.e., if
it's meaningful to retry, or it's an abort, etc.
2. The LMinit prototype:Here I was a bit lazy, and don't have updated the docs (also code as you may have noted, does not have this stuff). I'll change it later, I don't know exactly how, but I'll change it.
3. Minor textual correction:This is interesting, because I *not* imply this, or better, depends on the kind of device you have.In order to be generic enough to cover all possible situations,
present and future, when IOSK want to know if a loaded LM can work and
if so, what can do, IOSK interrogate the LM calling a probing
function:The IOSK *HAS* to call the probe function ONCE at least AFTER it calls the
init function, and BEFORE it calls any LM functions (read, write, etc.)
As the init function isn't allowed to contain hardware initialisation, this
has to be in the probe function, so it has to be certain that this function
will be called before any requests to hardware access. I think you did imply
this, but it's best to clarify these things.
There has to be another certainty here, but there are two options: eitherIt's best programmer practice th solution 2. I have taken it for granted, but it's best to say it explicitely.
1. The LMprobe() function in the LM *HAS* to be non-destructive to any
pending requests; i.e., the LMprobe() function can be called at ANY time
without influencing the other functions; or
2. The IOSK promises only to call the probe function
- ONCE right after the init function was called, and afterwards
- ONLY if the LM called the probe callback function.
After probe callback, the IOSK is then not allowed to make *any*
requests until it has probed the LM. The LM is itself responsible for
suspending pending requests until probe.
Another little thing about the directory naming: you put the parallellI have thinked about this over and over, and these are my ideas:
port LM in a directory called ibm-pc. Now in principle, we should divide
hardware drivers per hardware platform, but in practice hardware platforms
are not as unambiguous as processors. For instance, the IBM-PC compatibles
as well as the Digital Alpha, and perhaps also sparcs and macs (not sure)
use the same serial 16650 UART and parallell port hardware. If you divide
on the basis of ibm-pc, that would mean inefficient code reuse.
hardware is sometimes equal, but this overlap occurs only (in my knowledge)
to keyboard, serial and parallel ports and IDE disks. Well, the problem
is: how much they are equal?
If you see the Linux kernel code, you'll see a lot of ifdef of this
and that hardware to differentiate the slightly different behaviour of
the same chip. They are not so equal as you may think. Also this implies
that a modification done on one platform can made the LM of another environment
unstable, and this is bad. Also this made LM writing more difficult, and
I wish to made it the easier process possible.
Another point is that (from the device driver implementor point of
view) the other platform don't exists. He focus on one platform, then (if
needed) to another one. Timing considerations are much different from one
platform to another, and so needed optimizations.
Generally speaking, a device driver implementor knows exactly that
a particular device is used by others, so he can include code, if needed.
Roughly speaking, a few overlaps will occur, say 3 items will be replicated
in each hardware tree (for IOSK at least).
I don't have a solution ready for this, it's simply something we need toThere are multiple-role devices that made categorization hard to mantain.
consider. Perhaps we should simply divide hardware drivers per chip - Ie,LM/
LM/IOSK
LM/IOSK/Storage
LM/IOSK/Comms
Anyway, for the rest, I think it's a great spec !!! Now you just need toTell me (for my curiosity) what do you like more. I have my "loved" points, and I wish to see which are yours.
get it to actually work together with the IOSK.
PS: I have read CK code. I'll ask you something in the near future....
Stefano