From owner-freebsd-hackers@freebsd.org Thu Nov 26 00:21:07 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E565CA37640; Thu, 26 Nov 2015 00:21:07 +0000 (UTC) (envelope-from stas@freebsd.org) Received: from mx0.deglitch.com (cl-414.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:19d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 945201C63; Thu, 26 Nov 2015 00:21:07 +0000 (UTC) (envelope-from stas@freebsd.org) Received: from [172.27.138.58] (unknown [199.201.64.131]) by mx0.deglitch.com (Postfix) with ESMTPSA id 8F8898FC2D; Wed, 25 Nov 2015 16:20:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: Low-level trace-buffers in CAM From: Stanislav Sedov In-Reply-To: <1676097.ULW1yzL7e7@ralph.baldwin.cx> Date: Wed, 25 Nov 2015 16:20:50 -0800 Cc: freebsd-hackers@freebsd.org, Adrian Chadd , "freebsd-geom@freebsd.org" , "ken@freebsd.org" , "Pokala, Ravi" , "scottl@freebsd.org" , "freebsd-scsi@freebsd.org" , "imp@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1676097.ULW1yzL7e7@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 00:21:08 -0000 > On Nov 24, 2015, at 6:07 PM, John Baldwin wrote: >=20 > I actually think bpf might not be a bad interface (as I suggested at > the vendor summit), though I think we need a way to enumerate BPF taps > that aren't network interfaces (if we fix this then we can remove the > fake USB ifnets and make glebius@ happy as well). Then you can look > at these things in wireshark (which would be a bit bizarre perhaps) This is an interesting idea! Wireshark access does not sound too = bizzare actually -- wireshark supports FC protocol parsing as well as generic = SCSI dissecting. This is immensely useful when debugging FC communication problems, and I can imaging it would be helpful in other situations as = well. On the other hand, if we are talking about generic ring buffer logger with userland access -- isn't DTrace essentialy that? DTrace provides a very efficient data collection framework with the filtering = capabilities not unlike BPF. We can already access most of the information the new = proposed framework hopes to provide without any kernel code modifications = (including raw CDBs), and by adding the missing static DTrace probes we can provide an easy access to the same data both BPF and an ad-hoc framework would = while also giving a flexibility of accessing auxiliary data without code = modifications. This will allow for a pure-userland pcap generation as well (or any kind = of custom reporting). Something to think about as well. -- Stanislav Sedov ST4096-RIPE