Hi, On Sun, Nov 6, 2011 at 11:42 AM, Kostik Belousov <kostikbel_at_gmail.com> wrote: > On Sun, Nov 06, 2011 at 07:22:51AM -0800, mdf_at_freebsd.org wrote: >> On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov <kostikbel_at_gmail.com> wrote: >> > Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has >> > a lot of violations in regard of the namespaces, IMO. The __* namespace >> > is reserved for the language implementation, so our freestanding program >> > (kernel) ignores the requirements of the C standard with the names like >> > __mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes >> > it not unreasonable for other developers to introduce reserved names. >> > So I decided to use the suffixes. vm_map.h locking is free of these >> > violations. >> >> I'm pretty sure that when the C standard says, "the implementation", >> they're referring to the compiler and OS it runs on. Which makes the >> FreeBSD kernel part of "the implementation", which is precisely why so >> many headers have defines that start with __ and then, if certain >> posix defines are set, also uses non-__ versions of the name. > > For libc providing parts, required by standard, you are right. > But our kernel is a freestanding program using a compiler, so in-kernel > uses of the reserved namespace is a violation. > So you prefer to introduce a new notation which will confuses everybody for the sake of following an interpretation of the standard[0] ? Btw, which point of the standard are you quoting ? Section "7.1.3 Reserved identifiers" of ISO/IEC 9899 ? Thanks, - Arnaud ps: my vote is for a deep-sky-blue bikeshed. [0]: I'd be tempted to interpret "the implementation" as the non-visible part of an API, ie vm_page_lock() is public and rely on __vm_page_lock() for its implementation. As such, I would not consider "the kernel" as a single whole unit, but as a sum of public API and implementation.Received on Mon Nov 07 2011 - 03:50:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:20 UTC