From owner-p4-releng@FreeBSD.ORG Wed Oct 1 12:28:49 2003 Return-Path: Delivered-To: p4-releng@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 4F07716A4C1; Wed, 1 Oct 2003 12:28:49 -0700 (PDT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25A0D16A4B3; Wed, 1 Oct 2003 12:28:49 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A69B43F3F; Wed, 1 Oct 2003 12:28:47 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h91JSTbw004061; Wed, 1 Oct 2003 21:28:29 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Juli Mallett From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 01 Oct 2003 14:23:49 CDT." <20031001142349.A87379@FreeBSD.org> Date: Wed, 01 Oct 2003 21:28:29 +0200 Message-ID: <4060.1065036509@critter.freebsd.dk> cc: perforce@freebsd.org cc: julian@elischer.org cc: "M. Warner Losh" Subject: Re: PERFORCE change 38917 for review X-BeenThere: p4-releng@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 releng tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2003 19:28:49 -0000 In message <20031001142349.A87379@FreeBSD.org>, Juli Mallett writes: >* "M. Warner Losh" [ Date: 2003-09-30 ] > [ w.r.t. Re: PERFORCE change 38917 for review ] >> In message: >> Julian Elischer writes: >> : Someone who understands all this stuff should update >> : >> : /usr/share/examples/drivers/make_device_driver.sh >> >> That's premature at this time. We're trying to hash out the >> guarnatees that various subsystems need to make in order to ensure >> that we can successfully detach drivers. > >In other words, the strawman is being used to find the fundamental >flaws/races/... that we need to grow the APIs/etc. to accomodate? Yes, that's the concept. It is rather trivial to solve the actual problems, throw enough mutexes at it and you're done. It is far more tricky to do it in a way where you get both readable source code (so people understand what it does and how it does it), simple conceptual models (so people can understand it) etc. And then of course, once we have that we need a transistion plan, and that in itself is a problem because we want to minimize code sweeps, and we have a lot of practically untestable drivers. >Groovy. Better APIs and primitives :D Yeah, well, eventually. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.