Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Jun 2015 18:59:00 +0200
From:      Hans Petter Selasky <hps@selasky.org>
To:        hiren panchasara <hiren@strugglingcoder.info>,  Ian Lepore <ian@freebsd.org>
Cc:        Rick Macklem <rmacklem@uoguelph.ca>,  freebsd current <freebsd-current@freebsd.org>
Subject:   Re: setting tunables in stable/10 vs head?
Message-ID:  <5579BE54.6070701@selasky.org>
In-Reply-To: <20150611042303.GC4757@strugglingcoder.info>
References:  <1249942556.55526194.1433967239788.JavaMail.root@uoguelph.ca> <20150611034445.GB4757@strugglingcoder.info> <1433995674.1200.399.camel@freebsd.org> <20150611042303.GC4757@strugglingcoder.info>

next in thread | previous in thread | raw e-mail | index | archive | help
On 06/11/15 06:23, hiren panchasara wrote:
> On 06/10/15 at 10:07P, Ian Lepore wrote:
>> On Wed, 2015-06-10 at 20:44 -0700, hiren panchasara wrote:
>>> On 06/10/15 at 04:13P, Rick Macklem wrote:
>>>> Hi,
>>>>
>>>> I just MFC'd a patch from head to stable/10 that defines some
>>>> tunables using CTLFLAG_RDTUN. Although the MFC didn't break
>>>> anything, the tunables don't get changed by the values in /boot/loader.conf.
>>>>
>>>> By applying a patch like this:
>>>>   SYSCTL_DECL(_vfs_nfsd);
>>>>   int	nfsrv_statehashsize = NFSSTATEHASHSIZE;
>>>> +TUNABLE_INT("vfs.nfsd.statehashsize", &nfsrv_statehashsize);
>>>>   SYSCTL_INT(_vfs_nfsd, OID_AUTO, statehashsize, CTLFLAG_RDTUN,
>>>>       &nfsrv_statehashsize, 0,
>>>>       "Size of state hash table set via loader.conf");
>>>>
>>>> they get set ok.
>>>>
>>>> So, is this correct or have I done something stupid?
>>>
>>> I believe that is correct. hans changed how they are declared with r267961
>>> and now you do not need TUNABLE_INT() on -head.
>>>>
>>>> And, if it correct, do I commit a patch like the above directly
>>>> to stable/10. (It seems that TUNABLE_INT() is discouraged for -head.)
>>>
>>> That's the correct way, afaik.
>>>
>>> Cheers,
>>> Hiren
>>
>> Is there a reason the sysctl tunable flag changes can't be MFC'd?
>> Leaving changes that widespread un-mfc'd just makes for lots of merge
>> conflicts as time goes on (and can also lead to merged code behaving
>> differently than expected).
>
> Added Hans to answer the question.

Hi,

I wasn't sure if MFC'ing would break anything with regard to binary 
compatibility, so the change was kept in -head and only the broken 
SYSCTLs were fixed in 10- and 9- .

--HPS




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5579BE54.6070701>