Date: Fri, 27 Apr 2012 16:18:39 +0100 From: Attilio Rao <attilio@freebsd.org> To: John Baldwin <jhb@freebsd.org> 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 Message-ID: <CAJ-FndBcSfD%2Bp38eW4B5JpCx0ww%2B7oGJSeDjgpq-OB2Aqb%2BU7g@mail.gmail.com> In-Reply-To: <201204271108.25734.jhb@freebsd.org> References: <201204262024.q3QKOPA6067287@svn.freebsd.org> <201204271020.59067.jhb@freebsd.org> <CAJ-FndAkm0Ce7MvgvAjFa-JC6gyxfydU3=adZ%2B1n=TzDqT7%2BWw@mail.gmail.com> <201204271108.25734.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2012/4/27, John Baldwin <jhb@freebsd.org>: > On Friday, April 27, 2012 10:23:14 am Attilio Rao wrote: >> 2012/4/27, John Baldwin <jhb@freebsd.org>: >> > On Friday, April 27, 2012 9:55:41 am Attilio Rao wrote: >> >> 2012/4/27, John Baldwin <jhb@freebsd.org>: >> >> > 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 <machine/intr_machdep.h> falls into this category. In fact, I don't > > see a single thing in the current <machine/intr_machdep.h> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBcSfD%2Bp38eW4B5JpCx0ww%2B7oGJSeDjgpq-OB2Aqb%2BU7g>