From owner-svn-src-head@FreeBSD.ORG Fri Apr 27 15:18:42 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3640106567A; Fri, 27 Apr 2012 15:18:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id CDCD58FC15; Fri, 27 Apr 2012 15:18:40 +0000 (UTC) Received: by lagv3 with SMTP id v3so781647lag.13 for ; Fri, 27 Apr 2012 08:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0ynOizCXAvU1U+b3OgkIBcwC2DM7j2T8ntbsCTUNrHg=; b=VUwuRqBqkTMnyCvutv/Jcwhp21baYTt0KNT5tm0O6snmzS7orZBdGghgP0w53IxDRA h690qMEo4U6RT8sVrWi0wHF/E/PPJHbDru4UuCoNIiowtAIOnlU3LmdeTlyyTXy1v2MO UIx4nugaPbnalkRz51P1L0cAwMM2sGZTGpvuf3Qlsk9Xm+W0kS6uenb36LYahq6jtuKx MzsqyPy/6CdL42mbNAmF8z/p3950daqDEpXc4lye1Ws9AypTUaMaDYCpi+lrhlZQH5fs be7CfORR/LFLarUtg/esOgCY31yyisCudj2ZXeZpmCX6MysUDPruZWqZg+uuONmffl/k froQ== MIME-Version: 1.0 Received: by 10.152.144.101 with SMTP id sl5mr4628137lab.51.1335539919511; Fri, 27 Apr 2012 08:18:39 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.63.146 with HTTP; Fri, 27 Apr 2012 08:18:39 -0700 (PDT) In-Reply-To: <201204271108.25734.jhb@freebsd.org> References: <201204262024.q3QKOPA6067287@svn.freebsd.org> <201204271020.59067.jhb@freebsd.org> <201204271108.25734.jhb@freebsd.org> Date: Fri, 27 Apr 2012 16:18:39 +0100 X-Google-Sender-Auth: r3DxQJezx_vbx2_hZEbrSZdIIDs Message-ID: From: Attilio Rao To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r234723 - in head/sys: amd64/amd64 amd64/include i386/i386 i386/include pc98/pc98 sparc64/include sparc64/sparc64 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: Fri, 27 Apr 2012 15:18:42 -0000 2012/4/27, John Baldwin : > On Friday, April 27, 2012 10:23:14 am Attilio Rao wrote: >> 2012/4/27, John Baldwin : >> > On Friday, April 27, 2012 9:55:41 am Attilio Rao wrote: >> >> 2012/4/27, John Baldwin : >> >> > On Thursday, April 26, 2012 4:24:25 pm Attilio Rao wrote: >> >> >> Author: attilio >> >> >> Date: Thu Apr 26 20:24:25 2012 >> >> >> New Revision: 234723 >> >> >> URL: http://svn.freebsd.org/changeset/base/234723 >> >> >> >> >> >> Log: >> >> >> Clean up the intr* MD KPI from the SMP dependency, removing a >> >> >> cause >> >> >> of >> >> >> discrepancy between modules and kernel, but deal with SMP >> >> >> differences >> >> >> within the functions themselves. >> >> >> >> >> >> As an added bonus this also helps in terms of code readability. >> >> > >> >> > Hmm, this should not have affected anything with modules as no >> >> > modules >> >> > should have ever called this. Also, making intr_bind() available >> >> > for >> >> > UP >> >> > kernels on x86 is largely pointless. It's only caller is already >> >> > conditional >> >> > in sys/x86/x86/nexus.c: >> >> >> >> It doesn't mean that there couldn't be an user in the future of this >> >> KPI in terms of thirdy part modules. >> >> These functions are part of the public KPI and we speak a lot about >> >> making our KPI as less as dependent by compiling options so I don't >> >> really see why you are not happy about this. >> >> >> >> If the function (intr_bind() included) is part of the public KPI it >> >> can be called by thirdy part modules too. >> > >> > No! intr_bind() is _NOT_ part of the public KPI. The public KPI is >> > bus_intr_bind() which accepts a struct resource, which is the approved >> > handle for interrupt resources in drivers and other modules. >> >> It is accessible from machine/intr_machdep.h so *it is* part of the >> public KPI by definition. > > I will argue just this one point. I don't think this is true. There are > many > things in machine/foo headers that I do not consider to be part of the > public > KPI, but are solely for use in MD code, for example for the nexus(4) driver > to > interface with other MD code such as msi.c or intr_machdep.c on x86. Almost > > all of falls into this category. In fact, I don't > > see a single thing in the current that is intended > to > be used by any MI code and is part of the public KPI. I think what we really want is something as _KERNEL discriminant to be _KERNEL_KPI which defines which functions are really part of the public KPI (to be intended for usage in modules) and which not. Right now your idea of 'public KPI' is just something to be shared by voice, but if you really don't want to consider all the exported kernel functions as part of the KPI a way to enforce the subset would be desirable. Attilio -- Peace can only be achieved by understanding - A. Einstein