From owner-cvs-src@FreeBSD.ORG Tue Jul 25 19:25:41 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67C0B16A4E0; Tue, 25 Jul 2006 19:25:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9DE243D55; Tue, 25 Jul 2006 19:25:40 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id k6PJPVcS000825; Tue, 25 Jul 2006 15:25:31 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: David Malone Date: Tue, 25 Jul 2006 15:25:10 -0400 User-Agent: KMail/1.6.2 References: <200607252001.aa18647@salmon.maths.tcd.ie> In-Reply-To: <200607252001.aa18647@salmon.maths.tcd.ie> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607251525.11623.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88/1618/Mon Jul 24 21:12:40 2006 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Sam Leffler , src-committers@FreeBSD.org, "Christian S.J. Peron" , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/net bpf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 19:25:41 -0000 On Tuesday 25 July 2006 03:01 pm, David Malone wrote: > > > libpcap does not need to be modified; it works already for > > > wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO > > > is a bit of a misnomer; it's not entirely 802.11-specific. > > > > Ah, you mean we just exploit DLT_IEEE802_11_RADIO. Hmm... How > > about processing overhead? Can we synchronize the timestamping > > with system time? > > It sounds to me like a reasonable thing to do would be to pass up > a raw version of the timestamp (as returned by the hardware). We'd > also pass up the regular microtime() timestamp. You can then do any > postprocessing to syncronise timestamps later in userland? Nope. In that case, you actually need to export few more things, i.e., current hardware timecounter value, clock frequency, size of the timecounter, etc. Even then, it's going to be hard to get correct timeval without exposing few kernel internals. > > Okay. But I am worried about timecounter <-> timeval conversion > > because I want to know timeval delta from system time, not just > > some timer value. > > If we do it in the kernel, then we probably need to look into > expanding the timecounter infrastructure quite a lot, particularly > if you want to be able to apply NTP adjustments to multiple > counters at the same time. Yes, I know the complexity because I had experimented on few ideas in the past. Maybe phk can give us something magical again. ;-) Jung-uk Kim