From owner-freebsd-wireless@FreeBSD.ORG Wed Oct 23 18:15:28 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B6037FA0; Wed, 23 Oct 2013 18:15:28 +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 9F60C22F7; Wed, 23 Oct 2013 18:15:28 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 46F5A1A3C20; Wed, 23 Oct 2013 11:15:26 -0700 (PDT) Message-ID: <5268124E.4040906@mu.org> Date: Wed, 23 Oct 2013 11:15:42 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [rfc] removing the NDISulator References: <5265878B.1050809@yandex.ru> <201310212146.r9LLkqZ1044966@fire.js.berklix.net> <201310231023.32351.jhb@freebsd.org> <526810DB.20705@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Julian H. Stacey" , freebsd-current , "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:15:28 -0000 On 10/23/13 11:11 AM, Adrian Chadd wrote: > On 23 October 2013 11:09, Alfred Perlstein wrote: > > >> Eh, having taken a stab at porting the bwl blob already, I would strongly >>> oppose removing NDIS. If you do that I will just stop using my netbook >>> with a Broadcom part altogether as I wouldn't be able to use it to try to >>> test bwl changes. The NDIS thing is a bit hackish, but it is quite useful >>> for a lot of folks. >>> >>> I have to agree. Deprecation != motivation. > > I can pull out examples of this not holding true: > > * all the giant locking in drivers > * all the giant locking in VFS > > People did pop up and claim ownership of things they cared about. Some > stuff died, some stuff didn't. There was enough of a motivation by us to > kill giant off in these pathways so things could continue to evolve. We > didn't leave the GIANT crutch in forever. > > Sure, however those drivers and vfs systems were not sustainable and holding the kernel back. What part of the NDISulator actually holds the system back? I'm saying that it seems as if it was conjecture rather than a need. Is the NDISulator giant locked? Also why the interest in writing drivers so much? Being able to leverage other platform drivers is pretty neat and saves us a ton of work. -- Alfred Perlstein