Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with

Hi,

On Sun, Nov 6, 2011 at 11:42 AM, Kostik Belousov <kostikbel@gmail.com> wrot=
e:
> On Sun, Nov 06, 2011 at 07:22:51AM -0800, mdf@freebsd.org wrote:
>> On Sun, Nov 6, 2011 at 4:43 AM, Kostik Belousov <kostikbel@gmail.com> wr=
ote:
>> > 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 __* namespac=
e
>> > is reserved for the language implementation, so our freestanding progr=
am
>> > (kernel) ignores the requirements of the C standard with the names lik=
e
>> > __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. =A0Which 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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"