From owner-freebsd-arch Thu May 18 10:17:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 02FDC37B50F; Thu, 18 May 2000 10:17:25 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Thu, 18 May 2000 13:17:22 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Chuck Paterson Cc: Mike Smith , Bruce Evans , "Jeroen C. van Gelderen" , Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) In-Reply-To: <200005170406.WAA22297@berserker.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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