On Sat, Feb 17, 2018 at 8:04 AM, Hans Petter Selasky <h...@selasky.org> 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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
