On Thu, Apr 29, 2021 at 09:31:57AM -0700, Greg Steuck wrote:
> Alexander Bluhm writes:
> >> I like this too. I somehow got the impression that macros are severely
> >> frowned upon and didn't offer this kind of interface before.
> >>
> >> If you get this submitted, I can do a pass through the cod
> Q: would the introduction of SYSCTL_BOOL be considered an improvement
> over "0, 1"?
Absolutely gross and unneccessary.
0-1 is not neccessarily boolean. It remains entirely possible that range
of values is a count.
Alexander Bluhm writes:
>> I like this too. I somehow got the impression that macros are severely
>> frowned upon and didn't offer this kind of interface before.
>>
>> If you get this submitted, I can do a pass through the codebase to be
>> sure we catch them all.
Vitaliy, I volunteer to do a se
On Wed, Apr 28, 2021 at 12:06:26PM +0200, Alexander Bluhm wrote:
> On Tue, Apr 27, 2021 at 08:22:20PM -0700, Greg Steuck wrote:
> > Vitaliy Makkoveev writes:
> >
> > > On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
> > >> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt w
On Tue, Apr 27, 2021 at 08:22:20PM -0700, Greg Steuck wrote:
> Vitaliy Makkoveev writes:
>
> > On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
> >> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt wrote:
> >> > Actually, your variation seems pretty good. Is there any reas
Vitaliy Makkoveev writes:
> On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
>> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt wrote:
>> > Actually, your variation seems pretty good. Is there any reason to not
>> > use this type of define?
>>
>> This would look like thi
On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt wrote:
> > Actually, your variation seems pretty good. Is there any reason to not
> > use this type of define?
>
> This would look like this.
>
> I think sysctl_int() and sy
On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt wrote:
> Actually, your variation seems pretty good. Is there any reason to not
> use this type of define?
This would look like this.
I think sysctl_int() and sysctl_rdint() should be the primitive
functions. This brings us back the 4.4BSD
Alexander Bluhm wrote:
> On Tue, Apr 27, 2021 at 10:37:25AM -0600, Theo de Raadt wrote:
> > > Would 0, 0 min, max be a simple and obvious way to say "read only" ?
> >
> > That is not as terrible.
>
> Yes. But it has another undocumented side effect. I think
> sysctl_bounded_arr() inherits the
On Tue, Apr 27, 2021 at 10:37:25AM -0600, Theo de Raadt wrote:
> > Would 0, 0 min, max be a simple and obvious way to say "read only" ?
>
> That is not as terrible.
Yes. But it has another undocumented side effect. I think
sysctl_bounded_arr() inherits the minimum == maximum check from
sysctl_i
Chris Cappuccio wrote:
> Vitaliy Makkoveev [m...@openbsd.org] wrote:
> >
> >
> > > On 26 Apr 2021, at 01:43, Theo de Raadt wrote:
> > >
> > > I am not a fan of this strange behaviour, where the min+max values
> > > have additional behaviours. It is too surprising, and surprising
> > > often
Vitaliy Makkoveev [m...@openbsd.org] wrote:
>
>
> > On 26 Apr 2021, at 01:43, Theo de Raadt wrote:
> >
> > I am not a fan of this strange behaviour, where the min+max values
> > have additional behaviours. It is too surprising, and surprising
> > often turns into error-prone.
>
> Agreed. Also
> On 26 Apr 2021, at 01:43, Theo de Raadt wrote:
>
> I am not a fan of this strange behaviour, where the min+max values
> have additional behaviours. It is too surprising, and surprising
> often turns into error-prone.
Agreed. Also according sysctl_int_bounded() code this behaviour looks
lik
I am not a fan of this strange behaviour, where the min+max values
have additional behaviours. It is too surprising, and surprising
often turns into error-prone.
Alexander Bluhm wrote:
> On Sun, Apr 25, 2021 at 10:08:08AM -0700, Greg Steuck wrote:
> > - { IPCTL_ARPQUEUED, &la_hold_total, 0, 1
On Sun, Apr 25, 2021 at 10:08:08AM -0700, Greg Steuck wrote:
> - { IPCTL_ARPQUEUED, &la_hold_total, 0, 1000 },
> + { IPCTL_ARPQUEUED, &la_hold_total, 1, 0 },
>
> Will make la_hold_total read-only via sysctl.
This feature surprises me. When reading the caller, is is not clear
what it does
Hi Alexander,
Quick bike-shed followup below.
Alexander Bluhm writes:
> Index: netinet/ip_input.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_input.c,v
> retrieving revision 1.356
> diff -u -p -r1.356 ip_input.c
>
> On 23 Apr 2021, at 20:39, Alexander Bluhm wrote:
>
> Hi,
>
> The variable la_hold_total contains the number of packets currently
> in the arp queue. So the sysctl net.inet.ip.arpqueued must be read
> only. In if_ether.c include the header with the decalration of
> la_hold_total to ensure
Hi,
The variable la_hold_total contains the number of packets currently
in the arp queue. So the sysctl net.inet.ip.arpqueued must be read
only. In if_ether.c include the header with the decalration of
la_hold_total to ensure that the definition matches.
ok?
bluhm
Index: netinet/if_ether.c
==
18 matches
Mail list logo
