I don't think anything expresses why I like NetBSD better than the following example of the concise, clear, ego-free, across-[natural-]language-barriers communication between (volunteer, mind; Wasabi pays neither of these guys) developers, discussing what is now a minor point of code aesthetics but (if the evolution of the Linux kernel is any example) may be a horrible blockage begetting many kludges to work around key code that turned out to break portability all over the room by failing to be exactly as abstract as it could be:
From: Elad Efrat
Subject: Re: CVS commit: src/sys/secmodel/bsd44
Date: Wed, 08 Nov 2006 01:30:31 +0200
To: YAMAMOTO Takashi
Cc: tech-kern@ netbsd dot org
YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>>> also note that some constructs actually set EPERM as the retval for the
>>>> function and break. do you still think we should convert those that use
>>>> the above construct to the one you suggest?
>>> yes. my point is not to assume failure of kauth_foo() is due to EPERM.
>> kauth_authorize_action() can return either 0 or EPERM; the reason may be
>> different, but the final decision is one of those. or do you mean
>> something else?
> well, what's the point to let callers know it?
oh I get your point. will change now.
- -e.
YES! We COULD air our dirty laundry and make eventual (coding) users have to pay attention to the internal structure and take extra steps to interpret the output when people add internals that need to produce more detail… but why would we implement a broken API that left us stuck with that? Why don't we just leave the possibility to pass through whatever's appropriate, so we can add things to the include files later and nobody gets burned?
And, even more YES!, “Oh, yeah. You're right. Great!”
Post a Comment