From owner-svn-src-head@FreeBSD.ORG Fri May 22 15:34:28 2009 Return-Path: <owner-svn-src-head@FreeBSD.ORG> Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AED8B106566B; Fri, 22 May 2009 15:34:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB708FC13; Fri, 22 May 2009 15:34:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n4MFYIOa086969; Fri, 22 May 2009 09:34:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A16C5FA.3080307@samsco.org> Date: Fri, 22 May 2009 09:34:18 -0600 From: Scott Long <scottl@samsco.org> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: "M. Warner Losh" <imp@bsdimp.com> References: <3bbf2fe10905211511g53defb6cmac45fc2469cc64f@mail.gmail.com> <200905220921.34785.jhb@freebsd.org> <4A16AC32.2040507@samsco.org> <20090522.091202.1501528033.imp@bsdimp.com> In-Reply-To: <20090522.091202.1501528033.imp@bsdimp.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: src-committers@freebsd.org, jhb@freebsd.org, svn-src-all@freebsd.org, attilio@freebsd.org, svn-src-head@freebsd.org, rwatson@freebsd.org, kostikbel@gmail.com Subject: Re: svn commit: r192535 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head> List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 22 May 2009 15:34:29 -0000 M. Warner Losh wrote: > In message: <4A16AC32.2040507@samsco.org> > Scott Long <scottl@samsco.org> writes: > : John Baldwin wrote: > : > On Thursday 21 May 2009 6:11:02 pm Attilio Rao wrote: > : >> At this point I wonder what's the purpose of maintaining the sleeping > : >> version for such functions? > : > > : > Actually, I still very much do not like using M_NOWAIT needlessly. I would > : > much rather the solution for make_dev() be that the 1 or 2 places that need > : > to do it with a mutex held instead queue a task to do the actual make_dev() > : > in a taskqueue when no locks are held. This is basically what > : > destroy_dev_sched() is doing. Perhaps a make_dev_sched() with a similar > : > callback to be called on completion would be better. Having a device driver > : > do all the work to setup the hardware only to fail to create a node in /dev > : > so that userland can actually use it is pretty rediculous and useless. > : > > : > : It's a lot easier for me to handle a failure of make_dev in CAM than it > : is to decouple the call to it. Please don't dictate policy. > > On the other hand, we do dictate policy in things like busdma where > one has to do things in callbacks rather than inline. This is for > fairly good reasons, and I'm having trouble seeing why the reasons > presented here for make_dev_sched() are any worse... > > Warner Busdma isn't a good example anymore. I've tried to be very responsive and accommodating to requests for change; see the bus_dmamap_load_mbuf_sg() routine for example. It also lets you break the "normal" semantics without penalty via BUS_DMA_NOWAIT. About the only thing left in busdma that is cumbersome without an alternative is allocating static memory. Even then, I provided an alternative for a number of years, and not a single person used it, so it eventually got removed. Scott