From owner-svn-src-head@FreeBSD.ORG Wed Jul 14 18:20:52 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62AC9106566B; Wed, 14 Jul 2010 18:20:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 314238FC08; Wed, 14 Jul 2010 18:20:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id BECFE46B09; Wed, 14 Jul 2010 14:20:51 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E65928A03C; Wed, 14 Jul 2010 14:20:50 -0400 (EDT) From: John Baldwin To: Alexander Motin Date: Wed, 14 Jul 2010 14:20:05 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100217; KDE/4.4.5; amd64; ; ) References: <201007141331.o6EDVRp2078644@svn.freebsd.org> <201007141241.36772.jhb@freebsd.org> <4C3DED5A.3080806@FreeBSD.org> In-Reply-To: <4C3DED5A.3080806@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201007141420.05688.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 14 Jul 2010 14:20:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r210054 - in head/sys: conf kern x86/x86 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 14 Jul 2010 18:20:52 -0000 On Wednesday, July 14, 2010 1:01:14 pm Alexander Motin wrote: > John Baldwin wrote: > > On Wednesday, July 14, 2010 11:59:46 am Alexander Motin wrote: > >> John Baldwin wrote: > >>> On Wednesday, July 14, 2010 9:31:27 am Alexander Motin wrote: > >>>> Author: mav > >>>> Date: Wed Jul 14 13:31:27 2010 > >>>> New Revision: 210054 > >>>> URL: http://svn.freebsd.org/changeset/base/210054 > >>>> > >>>> Log: > >>>> Move timeevents.c to MI code, as it is not x86-specific. I already have > >>>> it working on Marvell ARM SoCs, and it would be nice to unify timer > > code > >>>> between more platforms. > >>>> > >>>> Added: > >>>> head/sys/kern/timeevents.c > >>>> - copied unchanged from r210053, head/sys/x86/x86/timeevents.c > >>>> Deleted: > >>>> head/sys/x86/x86/timeevents.c > >>>> Modified: > >>>> head/sys/conf/files.amd64 > >>>> head/sys/conf/files.i386 > >>>> head/sys/conf/files.pc98 > >>> Can this be merged with kern_et.c, > >> They are different. kern_et.c provides event timer drivers API, > >> timeevents.c consumes it to manage kernel clocks. kern_et.c > >> theoretically can be used without timeevents.c if some other code > >> consume timers, for example, exposing them to user-level. > >> > >> May be names indeed cryptic a bit, but I had no better ideas. > >> > >>> or perhaps called subr_eventtimers.c instead? > >> Whatever you like, but why exactly so and why "subr_" important? > > > > The vast majority of files in sys/kern use some sort of prefix, either sys_*, > > kern_*, subr_*, etc. subr_ was just a suggestion to avoid clashing with > > kern_et.c. If timeevents.c is specific to clocks then maybe it should have > > 'clock' in its name somehow? Right now having kern_et == kern_eventtimer.c > > and timeevents.c is a bit ambiguous. Somehow making it clear that > > timeevents.c is for clocks might help. > > We already have kern_clock.c and subr_clock.c. kern_clock.c is quite > close by meaning. What's about kern_clocksource.c? Ok. I assume it would not be easy to just merge this file into kern_clock.c itself? -- John Baldwin