From owner-svn-src-head@FreeBSD.ORG Fri May 22 15:37:44 2009 Return-Path: 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 46F49106566B; Fri, 22 May 2009 15:37:44 +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 CAEB38FC13; Fri, 22 May 2009 15:37:43 +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 n4MFbcZn086981; Fri, 22 May 2009 09:37:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A16C6C2.4020506@samsco.org> Date: Fri, 22 May 2009 09:37:38 -0600 From: Scott Long 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: John Baldwin References: <3bbf2fe10905210629p46c7a204v6863aaba77354462@mail.gmail.com> <200905220921.34785.jhb@freebsd.org> <4A16AC32.2040507@samsco.org> <200905221125.36813.jhb@freebsd.org> In-Reply-To: <200905221125.36813.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; 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, svn-src-all@freebsd.org, Attilio Rao , svn-src-head@freebsd.org, rwatson@freebsd.org, Kostik Belousov , "M. Warner Losh" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 15:37:44 -0000 John Baldwin wrote: > On Friday 22 May 2009 9:44:18 am Scott Long wrote: >> 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. > > But what is there for CAM to handle? I would expect CAM to handle hardware > events such as the devices arriving or leaving. A temporary memory shortage > it not a hardware event. As a user, if I insert a USB stick when the system > happens to be temporarily low on memory, is it more useful for the cdev to > appear a few microseconds later from a deferred context once memory is > available or for no device to ever appear at all? > John, You yourself have been recently burned by not fully understanding the complexity involved in CAM. By changing all of the periph drivers to conform to an artificial policy limitation of the make_dev call, I face a significant amount of time and effort to rewrite and test code paths that are, unfortunately, highly complex and very fragile. Please just make a simple concession. Scott