Re: Proposed change to makesyscalls.sh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 6 Aug 2018 07:06:42 +0800 (+08)
    From:        Paul Goyette <paul%whooppee.com@localhost>
    Message-ID:  <Pine.NEB.4.64.1808060645020.6766%speedy.whooppee.com@localhost>

  | I looked into using bitstring(3) operations, but since that stuff "lives
  | in" /usr/include/bitstring.h it wasn't clear if using it in kernel code
  | would be appropriate.

Doesn't matter much either way, when all you need is test (plus set,
if you're doing it dynamically, rather than pre-prepared) and you
don't need all the other crap that is in there, then the ops are trivial
and can just be open coded if using that seems like a poor idea
-- which I think it would be, the kernel should be self-contained and
use only what is in /usr/src/sys (plus the common stuff)).

  | My initial pass at this was to maintain the bit vector at run-time
  | rather than having makesyscalls.sh calculate the value.  The cost to
  | set the bits in syscall_establish() is not very large.

EIther way, but that makes the kernel fractionally bigger for no real
benefit - if it can be done at compile time, let it be.

  | The only drawback here is to add a new entry to struct emul to point
  | at the bit vector,

Sure.

  | and to initialize it in every place that the entrypoint array is initialized.

Whenever e_sysent is set, so shall be the new one.  How many places
can there be?

  | FWIW, what would you suggest as the name of a new struct emul member
  | (in sys/proc.h)?

Naming ... not my strong suit...   e_sc_nomodbits  ?

  | I'm beginning to think that this change really isn't worthwhile.

Not my decision.   Just suggesting a possibility.   As you know (I am sure)
I never use modules (for anything at all, so every time someone suggests
dtrace as useful for anything my skin crawls) so it makes no difference to me.

kre