Date: Mon, 26 Nov 2012 21:11:37 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Alfred Perlstein <bright@mu.org> Cc: "attilio@freebsd.org" <attilio@freebsd.org>, Mark Linimon <linimon@lonesome.com>, "arch@freebsd.org" <arch@freebsd.org>, Oleksandr Tymoshenko <gonzo@bluezbox.com> Subject: Re: [RFC] sema_wait_sig Message-ID: <alpine.BSF.2.00.1211262055150.4081@desktop> In-Reply-To: <50B187F2.2040506@mu.org> References: <20121124193010.GB1627@lonesome.com> <50B12520.7040508@mu.org> <CAJ-FndBeLvsgXQ4fskRwdZh2qaWbn7-LrCOmJTjPcfnbmD7aYg@mail.gmail.com> <50B145C5.8070503@mu.org> <CAJ-FndC%2BjHO2uKg%2Bd8GmzWGkQ8nZ6_iefgyGAeno0VqprR84Wg@mail.gmail.com> <50B16E7A.60900@mu.org> <CAJ-FndAetPqiZ0nCQTY1xAcqBJuuaq9dZfUhP9YXXw669o0WNQ@mail.gmail.com> <50B178A3.4070305@mu.org> <46D582BB-1EB9-4080-9733-7558D6D87FA8@bsdimp.com> <50B17BF7.7020609@mu.org> <CD4350B2-40E3-4964-B403-78825A00C75A@vigrid.com> <50B187F2.2040506@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Nov 2012, Alfred Perlstein wrote: > On 11/24/12 6:22 PM, Daniel Eischen wrote: >> On Nov 24, 2012, at 9:01 PM, Alfred Perlstein <bright@mu.org> 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. There is a pretty large variation in how packets are put on the wire and how bytes are delivered to the disk. You can shim and wrap and emulate but in the end you don't end up with what's most efficient for the underlying operating system. I think that's the underlying issue here. We don't use semaphores, they aren't implemented well on FreeBSD. They are there as a token effort at providing an API that we felt was better served in other ways. If we want to support this API then we should support it well and it should be written to the standards of the other primitives. Attilio wants to solve the problem by eliminating the API entirely because he knows how long it takes to write a good primitive. Those who are calling to support it should consider the effort it takes. It's not free. Calling it supported rather than deprecated means driver authors will expect it to be up to the quality standards of the rest of the kernel. This could have unintended consequences. Idioms will be developed. Code will be copied and propagated. All while using something terribly inefficient. Users will wonder why their driver performs so much better on Linux. I am responsible for one use of this code and I only did so knowing that it wasn't for anything performance critical and I was being lazy with a considerable porting effort ahead of me. I think my approach at this point would be either to entirely eliminate sema or rewrite it appropriately. Adding new consumers and hacking in a new feature is just another half measure. Which of the other solutions is best is up to individual bias. > > 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. Well I for one think we innovate in infrastructure as much as features and that innovation is important and necessarily means we can't always be compatible with everything else. We chose a locking and concurrency model that is not always compatible with everyone else and hopefully provides sufficient advantages to be preferable. Jeff > > 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 > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1211262055150.4081>