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
