From owner-freebsd-arch@FreeBSD.ORG Sun Nov 25 02:52:35 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F7C8DE2; Sun, 25 Nov 2012 02:52:35 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id DEC4B8FC12; Sun, 25 Nov 2012 02:52:34 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 5EBF01A3C1A; Sat, 24 Nov 2012 18:52:34 -0800 (PST) Message-ID: <50B187F2.2040506@mu.org> Date: Sat, 24 Nov 2012 18:52:34 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Daniel Eischen Subject: Re: [RFC] sema_wait_sig References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <50B145C5.8070503@mu.org> <50B16E7A.60900@mu.org> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> <50B17BF7.7020609@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "attilio@freebsd.org" , Mark Linimon , Oleksandr Tymoshenko , "arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2012 02:52:35 -0000 On 11/24/12 6:22 PM, Daniel Eischen wrote: > On Nov 24, 2012, at 9:01 PM, Alfred Perlstein wrote: > >> On 11/24/12 5:56 PM, Warner Losh wrote: >>> On Nov 24, 2012, at 6:47 PM, Alfred Perlstein wrote: >>> >>>> 1) compat layer >>>> /usr/src.local/sys/ofed/drivers/infiniband/core # >>>> cddl/contrib/opensolaris >>>> >>>> 2) >>>> if a user expects semaphores and we tell them to "rethink" things, then we're not providing the same facilities as every other non-BSD OS. >>>> >>>> I guess that makes us "cool", but really it just seems out of touch. >>>> >>>> The implementation is 176 lines of code + some headers. >>>> >>>> The sad part to me is that the original user asked "hey I need sema+signal" but we don't know the facility they really need, count of 1? count of 10? instead of just giving them a textbook CS semaphore we tell them to "build your own using our primitives". >>> You don't need stdio, you can build it from the syscall primitives... >> Dude, don't make me replace string.h/strncpy/strlcpy with sbuf_(9), cause I will! > Can we please chill? We're not talking about getting rid of a commonly used API with sema(9). We want to do what is right for FreeBSD, not Linux. That's not to say we can't have a Linux kernel compat shim or something, but they should be hidden accordingly and not used by native drivers and such. We definitely don't want every API for every OS, or we will become an amalgamation of those OSs. Daniel, this is something that I really don't understand, a driver is a driver, it's a means for putting packets on the wire or bytes on disk. Sometimes the stack becomes complicated due to topologies or interesting features (hot plug), but in essence they are very much the same. I do not see the point of "FreeBSD'ing" a driver when we could share code with another OS (infiniband?). It's just duplicate effort and makes it harder to maintain. Sema is already used inside the sysv_ipc code. I don't understand the point of trying to be different for the sake of differentness. It's really not done us any favors. Our strength has been when we've surpassed the other OSes out there with innovation: examples: cam, geom, kqueue, sendfile, accept filters, audit, witness, vfs_debug, zfs. Our strength is not our different names for the same things. I would certainly be accepting of a driver in FreeBSD that used sema(9) and I think we should all, afterall our infiniband stack seems to, and that's kinda cool. -Alfred