From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 09:56:51 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EACF1065670 for ; Thu, 9 Sep 2010 09:56:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CAFDE8FC1C for ; Thu, 9 Sep 2010 09:56:50 +0000 (UTC) Received: by bwz20 with SMTP id 20so1140140bwz.13 for ; Thu, 09 Sep 2010 02:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Um41vbwON5+ucTyd+phwcr2mi22CZqXNf2YcT5GY3As=; b=d6ry63gIYjOzo28o0iC7tLrKu8+wL8OXPX5X5mlsH9azHAYJPE7iVS05Hv/d7wCLWO WhjjmaI5pIKmE1tdFvcvk24TE60GC7VGz41e0Hy1ywgQNwSjwjXcGdGPKFGmT7JTdegv 6P6IneqtL8ou0++vh2Y40bE5FyorE9nHm3Lu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QYImHmUGc4Ux3VJqkKSKkdNMQvYIazBcKsjWWh0m7swL0wcvdjVcCzYVPdmWi+EgCW K74LRczzi32H/CVx0t2wOBLYtBElQAE592HgIeVUOwE+6YyGyUYvLKeVDagzD9hJOq3h OJ7WTSZCRp2KWJxdeWZljoBJ6gncrwt4b0uAA= Received: by 10.204.60.145 with SMTP id p17mr369610bkh.56.1284026209320; Thu, 09 Sep 2010 02:56:49 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f16sm880621bkd.16.2010.09.09.02.56.47 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Sep 2010 02:56:48 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C88AF4D.4020903@FreeBSD.org> Date: Thu, 09 Sep 2010 12:56:29 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: "Cherry G. Mathew" References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> <4C8738DA.80604@FreeBSD.org> <4C88AC08.7070502@zyx.in> In-Reply-To: <4C88AC08.7070502@zyx.in> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 09:56:51 -0000 Cherry G. Mathew wrote: > To summarise, > > My two concerns were: > I) > a) If there is a non-optional device specific callback (like a timer > isr) tied to specific timer on a vendor board > b) a "generic" non-device specific callback that uses the ET framework > and acquires the timer in "a)" before the isr/callback in "a)" could > obtain it. > > how can the API ensure that this scenario: > > i) doesn't happen > or > ii) can be subsequently rectified Using event timer (unlike time counter) most likely means programming it. Without enough complicated midlayer two consumers won't be able to use single timer, unless it ticks at fixed frequency and doesn't allow any programming. For this reason I wasn't expecting any sharing. We could extend API to allow shared event timer usage, but in that case only one consumer should control it, while all other's just receive these events and trust that timer programmed as they expect. At this moment I don't see practical reason where such functionality would be needed. Do you have some? > AND > II) > Did the api need to be fleshed out separately of timertc.h ? API is in stage of development and was changes few times since originally created. May be some ideas, like yours, could affect it again. -- Alexander Motin