From owner-svn-src-head@freebsd.org Sat Feb 17 15:07:04 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F754F1692F; Sat, 17 Feb 2018 15:07:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A112283ADF; Sat, 17 Feb 2018 15:07:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B3DDE26027E; Sat, 17 Feb 2018 16:07:01 +0100 (CET) Subject: Re: svn commit: r329458 - head/sbin/devmatch To: Warner Losh Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201802171434.w1HEYl8I063603@repo.freebsd.org> From: Hans Petter Selasky Message-ID: <90001804-e025-4981-6b77-350930310ceb@selasky.org> Date: Sat, 17 Feb 2018 16:04:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 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: Sat, 17 Feb 2018 15:07:04 -0000 On 02/17/18 15:56, Warner Losh wrote: > The right fix there, I think, is to load them all at once, in one kldload > operation and not loop in /etc/rc.d/devmatch. Each driver will invoke the driver loaded device method, so this will race aswell! You have a point. But, that means devmatch should read ahead the nomatch events until the end, to make sure the correct driver is loaded. For example if first a driver is loaded for a generic device, uhid, then comes a long a ums device, we have a problem this way. Matching should then understand how to reduce the hints, maybe by stripping down the "mask" from least significant bit. It is then important that the order from devmatch is not messed up by "sort -u". BTW: The "sort" utility lives in usr/bin and is not suitable for /etc/rc.d/devmatch, like already pointed out. --HPS