Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Feb 2021 00:21:55 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: adding a sysctl man section
Message-ID:  <CANCZdfqvmaLT05dXPEKM8QabKpsVeOURfYZ1YDb0YH4L=Pk5dw@mail.gmail.com>
In-Reply-To: <936bc860-c61d-ecc3-8e3f-496684bad68a@FreeBSD.org>
References:  <20210211001505.GF31099@funkthat.com> <936bc860-c61d-ecc3-8e3f-496684bad68a@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 12, 2021 at 1:14 PM John Baldwin <jhb@freebsd.org> wrote:

> On 2/10/21 4:15 PM, John-Mark Gurney wrote:
> > Inspired by:
> https://twitter.com/michaeldexter/status/1359614809365311490
> >
> > I realized that we could/should create a new sysctl section.  My initial
> > thought was section s, but I'd be open for other recommendations.
> >
> > Then, any page that describes a sysctl, would add an MLINK to it:
> > MLINK+= xhci.4 hw.usb.xhci.debug.s
> >
> > This section would be added to the default search, and then users
> > would simply be able to type: man <sysctl> and get directed to the
> > page that has information about it.
> >
> > Any objections?
>
> I think since they are MLINKs, just have them live in the section of the
> thing they are linking to.  That is, if it is for foo.4, have it live
> in section 4.  If it's a sysctl that's documented as part of a syscall
> (bar.2), have that MLINK live in section 2.  This is how all the other
> MLINKs work rather than needing a new section.
>

I agree. To the extent we do this, they should be in the same section. I
still think that having thousands of symlinks is getting out of hand, but
I'm open for experimentation here...


> Does this meaning adding sysctl nodes as .Nm entries in the NAME section?
>

I'm torn on this. That would make apropos(1) or man -k more useful, but on
the other hand, there's some devices that have dozens of sysctls that could
get messy without a good plan.

The alternative would be to have something new that wasn't in the NAME
section that could appear in man -k.


> I'm also a bit curious how to name per-instance sysctls vs global sysctls
> (hw.cxgbe.* vs dev.cxgbe.N.*) as Warner mentioned.  The global ones are
> easy,
> the per-instance ones would warrant some sort of consistent pattern.
>

Me too.

I'm starting to think that the best place to start for some of these things
would be hw.gxgbe and dev.cxgbe would be symlinks to cxgbe.4. And if we
went this way, having only two .nm wouldn't be horrible. But it would limit
the usefulness of finding some sysctls. kern.*, vm.* become more
troublesome, but even here the pattern at least half works: kern.cam.da,
already documented in da(4) at least in part, could be symlinks. However,
the ioscheduler creates a bunch of additional items for all devices in the
system support it, leading to kern.cam.da.iosched, kern.cam.ada.iosched,
kern.cam.nda.iosched, atll being symlinks, even though it's really
kern.cam.da.0.iosched.<etc>.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqvmaLT05dXPEKM8QabKpsVeOURfYZ1YDb0YH4L=Pk5dw>