Re: Error Msgs returned by kernel

[Tan Pong Heng <tponghen@Trantor.DSO.gov.SG> writes:]

>... I am current working on
>a ext2fs server for VSTa, and is constantly running into this problem of
>error codes handling. It is so inconvience to have a string as error code
>instead of the normal integer codes. So my question is - is there any
>reasons that you have decided on a string instead of integer that I don't see?

Yes. Like the Plan 9 folks, I observed that binary numbers have an enormous
inflexibility. You have to encode them to share them between architectures,
they're hard to manipulate in a structured way, they're hard to view, and
it's very hard to distribute out responsibility of them to reflect kernel,
server, or even application specific values.

So they're strings. 16 bytes might be a little stifling, but just the
ability to have a networking stack say "tcp/retries" instead of 1432, makes
it all worth it.

Note that I also wanted to allow the strings to be common between events and
errors. So "fault" is returned as an error or an event as appropriate.

This interface was meant to reflect my beliefs of the interface between a
server and a client. Within a server, it is entirely possible that you
might encode your state and errors as integers, or enums, or (what the heck)
floating point arrays. At worst, you should be able to map the number to
the appropriate string just as the reply is built for the client.

                                                        Andy
Received on Mon Jun 13 07:38:36 1994