From owner-freebsd-hackers Thu Aug 6 05:00:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA22303 for freebsd-hackers-outgoing; Thu, 6 Aug 1998 05:00:43 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spoon.beta.com (mcgovern.ne.mediaone.net [24.128.106.170]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA22192 for ; Thu, 6 Aug 1998 05:00:06 -0700 (PDT) (envelope-from mcgovern@spoon.beta.com) Received: from spoon.beta.com (mcgovern@localhost [127.0.0.1]) by spoon.beta.com (8.8.8/8.8.8) with ESMTP id HAA01248; Thu, 6 Aug 1998 07:59:47 -0400 (EDT) (envelope-from mcgovern@spoon.beta.com) Message-Id: <199808061159.HAA01248@spoon.beta.com> To: Jacques Vidrine cc: joelh@gnu.org, mcgovern@spoon.beta.com, hackers@FreeBSD.ORG Subject: Re: O_SHLOCK and O_EXLOCK - change to layering required? In-reply-to: Your message of "Thu, 06 Aug 1998 01:52:17 CDT." Date: Thu, 06 Aug 1998 07:59:46 -0400 From: "Brian J. McGovern" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Huh? >Sure, O_SHLOCK and O_EXLOCK are advisory, but so are lock files. >Applications are free to ignore any of them. >Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org Yeah, but 80% of my problem is the fact they cause the open() call on a device to fail with varying error codes, depending on the type of device. On my own device, it appears that the error condition occurs even before the driver open() call gets called. If I could make it to my driver without something above me setting off bells and whistles, I could make the locking not-so-advisory by handling it in the driver. The problem is that it returns EOPNOTSUPP on serial ports, for example. I think locking would be far more useful if locking would be passed down through the layers until either a layer that COULD handle it became involved, or the DRIVER said "Nope, not supported here", or even silently ignored the lock request. It just seems pitiful to have a reasonable file locking mechanism in place, but not be able to use the same semantics to lock a device. Falling back to UU-style locks is not only easily bypassed (rendering the locking useless, but it reeks of kludge). All it takes to ruin several people's days is to have one person that runs a com program that uses UU-locking, one that uses device locking (which will fail in this case), and one that does no locking, and I've got three people talking to a modem. Not good. -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message