Date: Fri, 22 May 2009 09:34:18 -0600 From: Scott Long <scottl@samsco.org> To: "M. Warner Losh" <imp@bsdimp.com> 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 Message-ID: <4A16C5FA.3080307@samsco.org> In-Reply-To: <20090522.091202.1501528033.imp@bsdimp.com> References: <3bbf2fe10905211511g53defb6cmac45fc2469cc64f@mail.gmail.com> <200905220921.34785.jhb@freebsd.org> <4A16AC32.2040507@samsco.org> <20090522.091202.1501528033.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A16C5FA.3080307>