svn commit: r355828 - head/sys/sys

[Warner Losh]

On Mon, Dec 16, 2019, 9:57 PM Cy Schubert <Cy.Schubert at cschubert.com> wrote:

> In message
> <CANCZdfqRm2HQ=ULPs6w3Kf2aZ6Gi46Q-vBYXaKiTs58X_siz9Q at mail.gmail.c
> om>
> , Warner Losh writes:
> > --0000000000009630860599df06a0
> > Content-Type: text/plain; charset="UTF-8"
> >
> > On Mon, Dec 16, 2019, 9:42 PM Cy Schubert <Cy.Schubert at cschubert.com>
> wrote:
> >
> > > In message <201912162355.xBGNtUq6078840 at repo.freebsd.org>, "Pedro F.
> > > Giffuni" w
> > > rites:
> > > > Author: pfg
> > > > Date: Mon Dec 16 23:55:30 2019
> > > > New Revision: 355828
> > > > URL: https://svnweb.freebsd.org/changeset/base/355828
> > > >
> > > > Log:
> > > >   Double the size of ARG_MAX on LP64 platforms.
> > > >
> > > >   As modern software keeps growing in size, we get requests to
> update the
> > > >   value of ARG_MAX in order to link the resulting object files.
> Other OSs
> > > >   have much higher values but Increasiong ARG_MAX has a multiplied
> > > effect on
> > > >   KVA, so just bumping this value is dangerous in some archs like
> ARM32
> > > that
> > > >   can exhaust KVA rather easily.
> > > >
> > > >   While it would be better to have a unique value for all archs,
> other
> > > OSs
> > > >   (Illumos in partidular) can have different ARG_MAX limits
> depending on
> > > the
> > > >   platform,  For now we want to be really conservative so we are
> avoidng
> > > >   the change on ILP32 and in the alternative case we only double it
> > > since tha
> > > > t
> > > >   seems to work well enough for recent Code Aster.
> > > >
> > > >   I was planning to bump the _FreeBSD_version but it was bumped
> recently
> > > >   (r355798) so we can reuse the 1300068 value for this change.
> > >
> > > This doesn't seem right. Each bump should be for a distinct change and
> > > documented as such.
> > >
> >
> > In the past we've said to piggy back versions when less than a day has
> > passed since the last bump. The hard part on this is that follow through
> on
> > actually documenting both has been lax.
>
> We document this kind of thing on the wiki, but the PITA of opening a
> browser. Would it be better to have a similar type of file like RELNOTES
> and UPDATING to document version bumps? It seems a little silly, though,
> to
> have yet another file, maybe we could incorporate that into RELNOTES in
> the
> form of:
>
> rNNNNNN: <optional: _FreeBSD_version>
>         Some verbiage.
>

We document it in the porters handbook. But I do see the appeal of being
able to find it in a svn log param.h. too bad the version bumps aren't all
usefully documented in the commit message... porters handbook is the best
source

Warner

Warner

-- 
> Cheers,
> Cy Schubert <Cy.Schubert at cschubert.com>
> FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org
>
>         The need of the many outweighs the greed of the few.
>
>
>