From owner-svn-src-head@freebsd.org Sat Feb 17 15:12:24 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 00F76F1725B for ; Sat, 17 Feb 2018 15:12:24 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 873A8842CF for ; Sat, 17 Feb 2018 15:12:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id t22so7110239iob.3 for ; Sat, 17 Feb 2018 07:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=eL3Kz0HerEfMD5H+It9BSbYYKpI+rbgQl99P8Hr8bqY=; b=pVu4YJas5WrVA4btfTSYgFWt16SZ4x5ECf2YoG3RcJSuzSxXxCr4RFXL73koPFrMcG l5r62y+/5IKb53qJ+gbEaPT5fUGzhXeatW2dtTMhw9QyrU3p39qb0C/tMi0k8T8ZGBHy bGsYqBtZouqDNA0vL7xhczNSFKBfGkTgp3LEM7854Fu3NgUBsvgkHtaeDQcbrK00f1XM xBQNTsbeGrYiHZSf/AIwLydWxmJ//j0Y9kHCLoQ8jD/Xu5jCDcTU7NRoO1qkabEgyHuu FcGvE04sEIbcYaXdVbe4Ro3TDu3AphM9Yi0FzypJkXLHLPF6COzeP4WhefjFAfwCehXP ERJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=eL3Kz0HerEfMD5H+It9BSbYYKpI+rbgQl99P8Hr8bqY=; b=K4nLw7K/+dkzOD5RqBdfuxpgQE8EUgsPjOJv4rO8wak6glr7hn6ODJfGQ26vuOIphZ qzIeJ7EgmAObLlqGFPASRT0GkWNl7Fz39ItD+JVpuER+lCC/w3YUcZ6p5G6CItCgFVCS 1B4hg8fCUG2yn61TW2/UiTSZIPTzMZYRR0IEZHxAoFvYhcp8XJnmC+mT//8mlOI+vwgI mDGepJ5EmbQjm4z4LK8SxQ4gjcIwnZEa4MbC6nKndZn4y3vZKYmaSN3ZcOWppB5aaGSC 5X3jwW6gTIJF72oQjGpy4UoxiHwRMYaObhdi2EMiEJjc5OW9dRR3COM6Xj2z7LW6FHCL Ajig== X-Gm-Message-State: APf1xPBPjF4yuebhEhK/ioWjTNV8HuTELg69WC5dfWTH9ZR3Ezw6oADb wiGl3ylTuxS1mhyBq497wi5UGxSR2Yrej/1z56DwuQ== X-Google-Smtp-Source: AH8x224qZMWytFLCXMV823xwEgYETVfx83SKh3fYqPw7rpDVG0Bl2B5CTWCjntond0rWmR0nSnMFGDNq5VAMc5P2Ma4= X-Received: by 10.107.2.6 with SMTP id 6mr12683267ioc.117.1518880342865; Sat, 17 Feb 2018 07:12:22 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sat, 17 Feb 2018 07:12:22 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <90001804-e025-4981-6b77-350930310ceb@selasky.org> References: <201802171434.w1HEYl8I063603@repo.freebsd.org> <90001804-e025-4981-6b77-350930310ceb@selasky.org> From: Warner Losh Date: Sat, 17 Feb 2018 08:12:22 -0700 X-Google-Sender-Auth: qdT5KU7L_ZNyhFULPFKW_XN4spg Message-ID: Subject: Re: svn commit: r329458 - head/sbin/devmatch To: Hans Petter Selasky Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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:12:24 -0000 On Sat, Feb 17, 2018 at 8:04 AM, Hans Petter Selasky wrote: > 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. > We could batch them in the kernel. But that's still unsatisfying since there could still be other races because multiple drivers wanting the same device is well defined only when all the drivers are there at probe/attach time. > 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. > That makes sense. We likely need to enhance our device model to cope with drivers arriving after a device is attached so this isn't racy. 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". > No, devmatch is necessarily unordered. We can't reliably use the match like you say. It simply will not work. devmatch has no way of knowing (the mask isn't a viable way) who will win. There must be some other method invented. > BTW: The "sort" utility lives in usr/bin and is not suitable for > /etc/rc.d/devmatch, like already pointed out. Yes. I know that. Continuing to belabor the obvious won't help make me less grumpy. Warner