OSDev.org

Cognition wrote:Wouldn't it be easier to simply use a bitmask to return multiple error conditions? It seems like it'd work under most scenarios pretty well, perhaps there are some scenarios were you would have to worry about handling more than 32 or 64 error conditions but I can't imagine there would be many. At any rate in such scenarios calling several syscalls to resolve the error would definitely be a huge performance hit as well.

rdos wrote:I like your idea. Especially since that would define the possible error returns per API, not in a huge list that is specific for each OS and version.

And for showing error reasons to users, I think returning a text string is quite adequate, and only requires a printf or similar to decode.

gravaera wrote:Yo:

In practice, no: if a syscall passes through several "hurdles" at which an error can occur, it normally stops and returns error at the first one, because proceeding with a shaky state into the second hurdle is just likely to cause another error, or produce suboptimal results.

If the syscall is of such a nature that it can be completed sanely with one or more unusual flags occuring then the API would normally just provide a "FORCE_OPERATION" flag that the app explicitly passes to bypass a certain hurdle if it has knowledge of the ramifications. In practice, since continuing with unstable state into a syscall past an error point would produce more errors, and possibly corrupt system state, the kernel usually just returns an error code for the first encountered error and then leaves the onus on the application to rectify it and call in again, etc.

An error bitfield would end up unintentionally just becoming a single-error value since it will rarely ever have more than one bit set on return.

--Peace out
gravaera

Solar wrote:PS: For those wondering why I throw up my hands in exasperation... given the C standard library's "errno" mechanism, the list of possible error returns is well-defined per API call, and the the perror() and strerror() functions turn an errno value into a (localized!) error description.

Solar wrote: Not that the "errno" mechanism is perfect; it has a couple of problems itself (especially in the realm of multithreading).

rdos wrote:FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

• access denied
  no such file
  invalid argument
  bad path
  interrupted by signal
  IO error

berkus wrote:Best kernel syscall ever is in BeOS anyway.

// Returns:
//   0 = computer has been sent "wake on LAN" packet
//   1 = computer is booting
//   2 = computer is on
//   3 = computer is preparing for shut down
//   4 = computer is in the "soft off" state (waiting for "wake on LAN")
//   5 = computer is off (unable to respond to "wake on LAN")

int _kern_is_computer_on(machine_ID)
{
   return state_of_each_computer_in_the_cluster[machine_ID];
}

piranha wrote:

FYI, the standard C errno mechanism can be implemented with a syscall API that doesn't return error code information. I know because I've done it.

Uh huh. It doesn't return any error information? So, how do you know what the error is? Do you guess?

I believe that you're talking about using your superfluous kernel-polling error info API (which I just don't understand why you would do such a thing. Even if you're the only one who is writing programs for your OS, it just seems silly. Please, provide us with a real example, discuss exactly why it is better in an objective way. So far, I haven't seen that. If you want to post your design decisions here, expect people to respond critically to them, and if this many people disagree that it is a good idea, maybe you're wrong? Or is that even possible?)

Anyway, given a function (say, open) that can return the following errors (of course there are more, this is simplified):

• access denied
  no such file
  invalid argument
  bad path
  interrupted by signal
  IO error

Go ahead, write the user space error handling API for this exactly how you envision to be "perfect".

-JL

    int handle;

   handle = RdosOpenFile(path);
   if (handle == 0)
       setterrno(FILE_NOT_FOUND);

Traditional APIs (like DOS, Windows and *nix) are cluttered with error-codes, but is this really necesary? Isn't error-codes just a bagage from non-object oriented designs that are not really necesary?

piranha wrote: Your OS may be perfect and you may be a perfect programmer and make it impossible for someone to supply an input that is a bad path (part of the path isn't a directory, etc, any other errors of which there will be a multitude for a lot of syscalls).

piranha wrote:But since you started this thread talking about API's in general, all the arguments you just made that discarded the error codes that I set forth in my challenge are then invalid.

piranha wrote:The point was to write error code handling for that challenge for a general OS, where all those errors are not fatal, can happen, and need to be handled by the application.

berkus wrote:@rdos
How do you go from carry flag to int handle again?

; file handle is returned in ebx for 32-bit memory model

RdosOpenFile    Macro
    DoSyscall ; returns handle in bx
    jc failed

ok:
    movzx ebx,bx
    jmp done

failed:
    xor ebx,ebx

done:
                     Endm

rdos wrote:I don't discard error codes. I never produce them, since I don't think lists of error codes are compatible with an object oriented design.

rdos wrote:My error handling philosophy is that error handling should be localized, and not globalized, which means that errors should be handled where they are produced, and not propagated for ever to higher levels to be handled by a monster error handler.

rdos wrote:Applications shouldn't handle OS issues. The OS should do it's best to perform syscalls, and when this fails, these failures are fatal and there is nothing the application can do about it provided that the application checked relevant preconditions.