From owner-freebsd-current@FreeBSD.ORG Tue Jun 19 10:45:51 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D20CD16A469 for ; Tue, 19 Jun 2007 10:45:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 963EF13C44C for ; Tue, 19 Jun 2007 10:45:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 30BAE17438; Tue, 19 Jun 2007 10:45:50 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l5IGT4qO006084; Mon, 18 Jun 2007 16:29:05 GMT (envelope-from phk@critter.freebsd.dk) To: Takeharu KATO From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 19 Jun 2007 00:07:31 +0900." <46769FB3.8060002@ybb.ne.jp> Date: Mon, 18 Jun 2007 16:29:04 +0000 Message-ID: <6083.1182184144@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Evaluation of High Precision Event Timer Driver for userland timer facility X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2007 10:45:51 -0000 In message <46769FB3.8060002@ybb.ne.jp>, Takeharu KATO writes: >> Basing this facility on the HPET almost guarantees that we cannot >> use it in FreeBSD, because the HPET is not available on more than >> a couple of our architectures. >> >Certainly the facility is not available non-PC platform, it >highly depends on board specs. > >How do you think about introducing this facility as a kernel option. >As far as I think, this facility is a kind of device driver, this is >not timer facility which is used in common. I would prefer if the API seen from the rest of the kernel did not change depending on if you have something like this or not. That requires changes to the current tsleep(9) API, but we have already been talking about that for some time (Search the arch@ list) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.