Date: Thu, 18 May 2000 13:17:22 -0400 (EDT) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Chuck Paterson <cp@bsdi.com> Cc: Mike Smith <msmith@freebsd.org>, Bruce Evans <bde@zeta.org.au>, "Jeroen C. van Gelderen" <jeroen@vangelderen.org>, Doug Rabson <dfr@nlsystems.com>, arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) Message-ID: <Pine.BSF.4.21.0005181302130.74763-100000@green.dyndns.org> In-Reply-To: <200005170406.WAA22297@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 May 2000, Chuck Paterson wrote:
> This really is a very valid statement/complaint. The "M_"
> prefix used with the mutex stuff in BSD/OS is in common with the
> mbuf stuff. We, or maybe just I, though about this quite a bit
> before deciding to go with the M_ for mutexs. I don't know that
> anybody else really cared. Even though there were valid reasons
> for trying to keep the names short, I'm not at all sure that the
> right decision was reached. All of the macros start with mtx_
> (mtx_enter, mtx_exit, mtx_try_enter). It may be that a global pass
> should be made and all the mtx "M_" should be changed to "MTX_".
> Comments?
Quick, identify the structes that the following belong to:
M_WAIT, M_DEF, M_NOWAIT, M_DONTWAIT, M_EXT, M_WAITOK
It's an exercise in frustration keeping these things separate in
your mind when you're using them all. No prefixes are absolute evil,
but single letter prefixes are almost as evil. People aren't made
to keep track of names that similar, especially when the suffixes are
homonyms! Keeping things short makes keeping style(9) "easier", but
it's hell on the programmer.
> On a slightly related note. I see that putting prefixes on
> structure elements appears less common in FreeBSD than BSD/OS. Is
> this a conscience decision, or something that just happened because
> the compiler doesn't require it anymore? Actually anymore is a real
> long time now. Anyway, I can say with a fair amount of certainty
> that when it comes time to go around locking up the kernel this
> isn't going to be popular. When using tools like cscope/glimpse looking
> for foo_timeout is much more productive than just looking for
> timeout. There are some of these in the BSD/OS kernel and making
> sure all references were covered was a real pain.
There are tons of these in the FreeBSD kernel, but it doesn't seem to
be as pervasive as you say it is in the BSD/OS kernel. I seem to have
taken after the old hats insofar as I religiously prefix a structure's
members. I use abbreviations here because there is no namespace clash,
and I often use the full structure name for macros because those can
easily clash. Since functions are just about as likely to clash as
macros, I usually use the full structure name in a support function.
Real world e.g.:
struct ttree {
struct ttree *tt_low, *tt_high; /* low and high branches */
union {
struct ttree *ttu_equal; /* equal branch OR */
void *ttu_data; /* data (pointer) */
} tt_un;
...
#define TT_VALID 0x0001 /* is it here, or removed? */
...
struct ttree *ttree_add(struct ttree *head, char *s, void *userdata);
I'd love for more people to adopt this style, not just because it's the
style I use ;), but because it has a deep precedent and long-standing
(proven) justifications. It seems like there's a fad recently that
many people don't do it, perhaps because they don't like the "tradition"
of it or just that it seems redundant to them. I learned my coding
style entirely from the FreeBSD kernel and some of the userland code,
and have picked up the good habit from there. I'm not saying this to
disrespect anyone in anyway, just to express that it really can be
quite natural to have and think in this style.
> Chuck
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0005181302130.74763-100000>