Hi Kristaps,

Kristaps Dzonsons BSD.LV wrote on Sat, Apr 07, 2018 at 01:37:32AM +0700:

> The only reason I suggest a standalone section is that it's easier
> to standardise across manpages.

For that goal, using ".Ss Pledge promises"
at the end of the DESCRIPTION might work.

For now, such consistency would be local to the ksql package (and
maybe some related packages like kcgi?), and i don't anticipate a
large number of other non-base libraries that want to integrate
with pledge(2) in the near future.  But even if some other libraries
pick it up from there, that wouldn't seem undesirable to me.

> How about .Sh RESOURCES?

I don't like that because the term "resources" is so broad that it
is hard for users to guess what they might find there.  Maybe
something related to X11, or to setrlimit(2), or books and mailing
lists on the subject?  Also, trying to standardize a section requires
that the section is widely needed and that the subject matter is
very mature.  Premature attempts to standardize new top-level
sections, mostly in other operating systems, already left us with
various half-dead sections that are not being used consistently and
of doubtful utility (LIBRARY, IMPLEMENTATION NOTES, SECURITY
CONSIDERATIONS, ..., not even talking about what OpenSolaris /
illumos did).

> This would also fit other systems like Capsicum.
> Though in practice, I think we'll find only pledge documented there.

Then i'd suggest to not try to plan ahead for theoretical ideas
that are not likely to get done at all.  Besides, as Theo said,
Capsicum is so different from pledge(2) that what is possible with
pledge(2) likely cannot be done with Capsicum - regarding documentation
just like regarding consistent application to the complete codebase
of a whole operating system.

Yours,
  Ingo

Reply via email to