Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Apr 2009 09:13:28 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        FreeBSD Arch <arch@freebsd.org>
Subject:   Re: On errno
Message-ID:  <FE53FDC4-6416-458C-A10C-C2C70A085C83@mac.com>
In-Reply-To: <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com>
References:  <8321954E-5CFF-45F9-9F87-BE83659E4C8D@mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 30, 2009, at 10:31 AM, Marcel Moolenaar wrote:

> This begs the question: what is stopping us from adding new
> error codes?

>> kientzle@ wrote:
>> POSIX does specify the range of allowable error codes
>> for a lot of system calls, but not all.  In my experience,
>> straying outside of that causes more problems than it's
>> worth.

I agree that well-known system calls should not be changed
willy-nilly. But what about error codes returned from GEOM
or other FreeBSD-specific subsystems?

>> phk@ wrote:
>
>> Long time ago, I proposed a scheme where a process can register
>> a userland error-text buffer with the kernel.
>> Whenever a system call returns with error, the kernel has the
>> opportunity to write an explanatory text in the registered
>> buffer (if there is one).

Strings are not to be used to relay error conditions between kernel
and processes. Interpretation of the string is unnecessarily hard
(if not impossible) if the process wants to take corrective action.
They're not even good for printing, because the process is not left
in control over its own output (i18n has been mentioned).

>> kientzle@ responded:
>> This is the right direction:  Basically, add a new variable
>> that augments errno instead of extending the possible values of
>> errno.

Augmentation seems logical. Does anyone know if this has been done
in some OS already?

>> phk@ wrote:
>> Don't overengineer it guys.

I agree that over engineering is not a good thing, but under-
engineering is worse. Handwaving real-world demands/requirements
with nothing more than emotional responses that lack technical
argumentation does not build the "damn best OS".
Oh, and yes: I have been thinking about localization of the kernel.
While I don't see this to be urgent or critical to FreeBSD itself,
I can see a "market" for it.

>> wollman@ wrote:
>> But all this is really irrelevant if no other operating system or
>> standard adopts the interface.  Interfaces which are peculiar to
>> FreeBSD are rarely useful.

That's a very good point indeed.

-- 
Marcel Moolenaar
xcllnt@mac.com






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE53FDC4-6416-458C-A10C-C2C70A085C83>