From owner-svn-src-all@FreeBSD.ORG Fri May 22 15:54:25 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4CA106564A; Fri, 22 May 2009 15:54:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1448FC16; Fri, 22 May 2009 15:54:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 497F446B4C; Fri, 22 May 2009 11:54:25 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 49E0C8A025; Fri, 22 May 2009 11:54:19 -0400 (EDT) From: John Baldwin To: Scott Long Date: Fri, 22 May 2009 11:52:59 -0400 User-Agent: KMail/1.9.7 References: <3bbf2fe10905210629p46c7a204v6863aaba77354462@mail.gmail.com> <200905221125.36813.jhb@freebsd.org> <4A16C6C2.4020506@samsco.org> In-Reply-To: <4A16C6C2.4020506@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905221153.00147.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 22 May 2009 11:54:19 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 15:54:26 -0000 On Friday 22 May 2009 11:37:38 am Scott Long wrote: > 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. Are you referring to the sysctl thing? That was quite trivial to fix FWIW. I also do not see why make_dev_sched() with a callback won't work? We already have this exact policy limitation in many similar APIs such as if_attach(). Another thing to consider is that if you hold a lock while calling into other subsystems, that can result in your lock being held for a relatively "long" time which increases the chances for lock contention. -- John Baldwin