From owner-freebsd-arch Tue May 16 21: 6:26 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id CEF1737BDEC; Tue, 16 May 2000 21:06:16 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@LOCALHOST [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id WAA22297; Tue, 16 May 2000 22:06:15 -0600 (MDT) Message-Id: <200005170406.WAA22297@berserker.bsdi.com> To: Mike Smith Cc: Bruce Evans , "Jeroen C. van Gelderen" , Doug Rabson , arch@freebsd.org Subject: Re: A new api for asynchronous task execution (2) From: Chuck Paterson Date: Tue, 16 May 2000 22:06:15 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG }(This applies to crap going into libc as well; especially new stuff. We } should be using a symbol prefix that at least *tries* to keep us out of } other peoples' namespaces.) 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? 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. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message