From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 4 22:06:47 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E492A16A4CE for ; Sun, 4 Jul 2004 22:06:47 +0000 (GMT) Received: from blitzen.qlo.com (blitzen.qlo.com [142.165.150.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id A85C243D39 for ; Sun, 4 Jul 2004 22:06:47 +0000 (GMT) (envelope-from shurd@sasktel.net) Received: from stephens (hssx-yktn-59-202.sasknet.sk.ca [142.165.59.202]) by mail.qlo.com (SaskTel eMessaging Service) with ESMTPA id <0I0C00806LF9U3@mail.qlo.com> for freebsd-hackers@freebsd.org; Sun, 04 Jul 2004 16:06:45 -0600 (CST) Date: Sun, 04 Jul 2004 16:06:45 -0600 From: Stephen Hurd In-reply-to: <20040704181347.GE997@green.homeunix.org> To: freebsd-hackers@freebsd.org Message-id: <20040704160645.39a0c0d8.shurd@sasktel.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.9) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20040624174919.46160f9e.shurd@sasktel.net> <20040628192935.GF5635@green.homeunix.org> <20040630192041.1d9c5348.shurd@sasktel.net> <20040704181347.GE997@green.homeunix.org> Subject: Re: Locking: kern/50827 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2004 22:06:48 -0000 > Right, if you just make it cross-platform in the first place using > higher- level primitives you don't have to worry what the specific > kernel and operating system and file system you are using provides. > It's my opinion tha there won't be other people adopting this API for > file locking since it is by definition not meant to work like the > standardized APIs. > > I don't think that there's no value in having more useful locking > primitives, but they probably don't benefit much from being implemented > in the kernel unless they conform to a portable API. I certainly always > have my own various kernel modifications that I find useful, but aren't > very standard :) This sounds a lot like "Well, there's no point in doing something better since nobody else is doing it.". strlcpy() and friends are an example of non-standard stuff that just Makes Sense(tm).