Re: git: b75062f23431 - main - riscv: Fix thread0.td_kstack_pages init
- In reply to: Brooks Davis : "Re: git: b75062f23431 - main - riscv: Fix thread0.td_kstack_pages init"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 19 Jan 2023 16:49:12 UTC
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