Re: git: b75062f23431 - main - riscv: Fix thread0.td_kstack_pages init

On 1/18/23 20:57, Brooks Davis wrote:
> On Wed, Jan 18, 2023 at 04:53:51PM -0700, Warner Losh wrote:
>> On Wed, Jan 18, 2023 at 3:07 PM Mitchell Horne <mhorne@freebsd.org> wrote:
>>
>>>
>>>
>>> On 1/17/23 12:38, Brooks Davis wrote:
>>>> The branch main has been updated by brooks:
>>>>
>>>> URL:
>>> https://cgit.FreeBSD.org/src/commit/?id=b75062f23431fbabef1e7d665cae270b144f71b1
>>>>
>>>> commit b75062f23431fbabef1e7d665cae270b144f71b1
>>>> Author:     Brooks Davis <brooks@FreeBSD.org>
>>>> AuthorDate: 2023-01-17 16:36:15 +0000
>>>> Commit:     Brooks Davis <brooks@FreeBSD.org>
>>>> CommitDate: 2023-01-17 16:37:42 +0000
>>>>
>>>>       riscv: Fix thread0.td_kstack_pages init
>>>>
>>>>       Commit 0ef3ca7ae37c70e9dc83475dc2e68e98e1c2a418 initialized
>>>>       thread0.td_kstack_pages to KSTACK_PAGES.  Due to the lack of an
>>>>       include of opt_kstack_pages.h it used the fallback value of 4 from
>>>>       machine/param.h.
>>>
>>> Does this mean that we could/should include opt_kstack_pages.h within
>>> machine/param.h (under #ifdef _KERNEL)? This header is both a consumer
>>> and provider of the KSTACK_PAGES definition, by virtue of the #ifndef. I
>>> think the hidden dependency should be avoided, if possible.
>>>
>>
>> No. Including opt_XXXX.h is never OK in our .h files. They are used in too
>> many places, some of which "cheat" and define _KERNEL becuse, well, they
>> need to get to the kernel bits....  That will break...
> 

Riiiiiight, I was forgetting the _KERNEL liars always ruin the fun. You 
are right, and the "never include opt_ headers in a header" rule is a 
good one.

> We could potentially use the __has_include extension.  I don't think we
> care about building the kernel with a compiler that isn't clang or gcc
> and the usage pattern defined by gcc is safe for compilers that don't
> define it.  We could do something like:
> 
> #ifdef _KERNEL
> #ifndef KSTACK_PAGES
> #ifdef __has_include
> #if __has_include("opt_kstack_pages.h")
> #include "opt_kstack_pages.h"
> #endif
> #endif
> #endif
> #endif
> <old #ifndef KSTACK_PAGES code>
> 

Yeah this would work, but I think we can agree it's one step more 
complicated than necessary for this edge-case which is unlikely to show 
up again often, if at all. I say let's just add a comment to each 
machine/param.h explaining the situation and that will be enough.

Mitchell

>>
>> I do agree, however, that the current interface is less than ideal...
>>
>>
>>> Of course, the problem at hand has been fixed and we want to keep direct
>>> consumers of KSTACK_PAGES to a minimum, but I think the point still stands.
>>>
>>
>> I think it's a good point, but the current way is likely the least-bad way
>> to accomplish things.
>>
>> It would be much better if we could remove it from machine/param.h and
>> opt_XXX.h always defines it, even the default value when it's not otherwise
>> specified. However, we don't (currently) have a way to set default values
>> in config(8). We could add it, since the efforts at config++ have thus far
>> fallen flat....
> 
> I think this is probably the better direction to move.  There aren't any
> in-tree uses of KSTACK_PAGES so removing the definition should be fine.
> 
> -- Brooks