From owner-svn-src-all@FreeBSD.ORG Tue Feb 10 20:21:01 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0A036DA; Tue, 10 Feb 2015 20:21:01 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 57ACE16E; Tue, 10 Feb 2015 20:21:01 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YLHIm-000NVa-A9; Tue, 10 Feb 2015 23:20:56 +0300 Date: Tue, 10 Feb 2015 23:20:56 +0300 From: Slawa Olhovchenkov To: Rui Paulo Subject: Re: svn commit: r278479 - in head: etc sys/kern Message-ID: <20150210202056.GM3698@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: "svn-src-head@freebsd.org" , Adrian Chadd , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , John Baldwin X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Tue, 10 Feb 2015 20:21:01 -0000 On Tue, Feb 10, 2015 at 06:55:28PM +0000, Rui Paulo wrote: > On Feb 10, 2015, at 10:52 AM, Slawa Olhovchenkov wrote: > For common case (I am not talk about current devd implementation -- I > am don't have any inforamtion/metrics/etc) routing and processing > events may be sensitive to delay and ordering: may be exist > requirement 'delay not more then 700ns', may be exist requirement > 'next event process only after complete process previos event'. And > some event handling may be very CPU/disk/etc consumption. Need to good > think over and design API and architecure. > š > routing events do not come over devd (or any other /dev device): > there's a routing socket specifically tailored for that purpose. I am talk abot this: nomatch 32 { match "bus" "uhub[0-9]+"; match "mode" "host"; match "vendor" "0x03eb"; match "product" "0x2109"; action "kldload -n uftdi"; }; > šFor that type of latency, you probably don't want to be crossing > the kernel/userland barrier too often (or never). We have action for coredump. And have action for automount (when inserting USB disk). Must be coredump wait for complete mounting USB disk? For flapping USB disk need to start multiple mount script?