On Thu, Jan 16, 2020 at 10:32:21PM -0600, Scott Cheloha wrote:
> Ticks to milliseconds.
>
> Pretty sure all we need to do to convert the drain timeouts is
> substitute 1000 for hz in each expression.
>
> While we're here, I noticed that at halt time for input/output we
> msleep to allow a drain
Ticks to milliseconds.
Pretty sure all we need to do to convert the drain timeouts is
substitute 1000 for hz in each expression.
While we're here, I noticed that at halt time for input/output we
msleep to allow a drain and then immediately relinquish the mutex
after coming out of the sleep. We
We need to load firmware onto the device. It seems we need to poll
for completion in two phases.
So, poll at 10ms intervals in each case. We can make it faster later
if need be.
ok?
Index: pci/if_tht.c
===
RCS file:
Hi Marc,
Marc Espie wrote on Wed, Jan 15, 2020 at 01:52:37PM +0100:
> So there is some luggage in make that I think we should drop.
>
> Currently, our make "supports" the keywords
> .EXEC, .INVISIBLE, .JOIN, .MADE,
> to the extent that I never touched the code that handles those, but
> frankly
On 16/01/20(Thu) 12:01, Theo de Raadt wrote:
> +# Keep in sync with /sys/kern/syscalls.c
> +SRCS+= syscalls.c
>
> But that trick never works!
>
> Why not compile from ../../sys/kern/syscalls.c?
Nice! That would work indeed :)
+# Keep in sync with /sys/kern/syscalls.c
+SRCS+= syscalls.c
But that trick never works!
Why not compile from ../../sys/kern/syscalls.c?
The userland companion of dt(4) is named btrace(8). It understands an
awk(1) inspired syntax, a current subset of the bpftrace(8) language, to
enable probes and format informations recorded during the tracing.
The choice of the bpftrace(8) dialect and outputs has been made to be
able to ease the
As kn@ found out the hard way and otto@ analysed: We can not share a
cache between validating and resolving strategies.
The resolving only strategies mess up the negative cache by claiming
DNSKEY and DS records do not exist which confuses the validating
strategies.
This diff rearranges things
I'd like to import this new MI pseudo-driver and the framework it
provides to instrument and inspect kernel internals.
It is still under development and all the code is guarded under NDT, so
it shouldn't impact GENERIC. However at this stage of development I'm
interested to get code reviews and
On Thu, Jan 16, 2020 at 06:24:47PM +0100, Tobias Heider wrote:
> Hi,
>
> this diff adds a '-p' command line option which allows to configure
> the used UDP encapsulation port, similar to isakmpd's '-N' flag.
>
> UDP encapsulation is primarily used with IPsec NAT traversal
> but with this diff it
On Thu, Jan 16, 2020 at 06:56:06PM +0100, Alexandr Nedvedicky wrote:
> I like your suggestion, diff below fixes extra white space and
> uses Stuart's wording.
sure
Hello,
> > +.Pp
> > +Note that users 1000 and 1500 are excluded from the pass rule.
>
> The last line above is a little hard to parse - I think a "positive
> example" would be clearer, i.e. something like this:
>
> .Pp
> The example below permits users with uid between 1000 and 1500
> to open
Hi,
I want to schedule timeouts more lazily from softclock() in order to
spend less time processing timeouts that will be cancelled and avoid
double-processing timeouts that will fire at the next softclock()
anyway.
This means introducing an additional timeout queue, probably named
On 2020/01/16 17:37, Alexandr Nedvedicky wrote:
> Hello,
>
>
> > > +of uids, which match the pass rule. The
> > New sentences on its own line. I'd say
> >
> > Note that users 1000 and 1500 are excluded from the pass rule.
> >
>
> yes, new sentence on the new line. and your wording
Hi,
this diff adds a '-p' command line option which allows to configure
the used UDP encapsulation port, similar to isakmpd's '-N' flag.
UDP encapsulation is primarily used with IPsec NAT traversal
but with this diff it might as well be interesting in cases where
ESP and UDP ports 500 and 4500
On Thu, Jan 16, 2020 at 05:37:17PM +0100, Alexandr Nedvedicky wrote:
> updated manpage is below.
OK kn
> +The
^
$ mandoc -T lint pf.conf.5
mandoc: pf.conf.5:832:4: STYLE: whitespace at end of input line
mandoc: pf.conf.5:2946:2: WARNING: sections out of
In practice, how many ticks will we poll for this device to be ready?
Does it vary by parent device, e.g. pci vs isapnp vs pcmcia?
If it's usually 1 we could try to poll at a faster rate, say 1ms or
5ms. If it's usually 2 or more we can leave it at 10ms, the effective
rate on 100hz platforms.
Hello,
> > +of uids, which match the pass rule. The
> New sentences on its own line. I'd say
>
> Note that users 1000 and 1500 are excluded from the pass rule.
>
yes, new sentence on the new line. and your wording sounds better.
> > +.Cm :
> The port paragraph marks up those
here is a related argument:
https://lists.freebsd.org/pipermail/svn-src-stable-9/2016-September/008613.html
https://reviews.freebsd.org/D
There is a minute C++ argument against changing it, but I suspect a library
using ipopts is a rare animal.
Alexander Bluhm wrote:
> On Thu, Jan 16, 2020 at 02:35:25PM +0100, Mark Kettenis wrote:
> > As for your suggestion. I think it is a bit of a mess. I wasn't
> > entirely sure about the consequences of such a change for ports.
> > However, "Stevens" has this as "char ipopt_list[]" which means
On Thu, Jan 16, 2020 at 03:29:16PM +0100, Alexandr Nedvedicky wrote:
> I think that's where we are heading after reading email from sthen@
>
> Let's focus on to update pf.conf.5 manpage. Would diff below make
> pf.conf.5
> manpage more useful?
I think this is the right way; adding
On Thu, Jan 16, 2020 at 02:35:25PM +0100, Mark Kettenis wrote:
> As for your suggestion. I think it is a bit of a mess. I wasn't
> entirely sure about the consequences of such a change for ports.
> However, "Stevens" has this as "char ipopt_list[]" which means that it
> was signed on some
Hello,
>
> (2Theo: yes, I'm lazy, sorry :) )
>
> I agree, that "X:Y" syntax for "user" could be confusing, and "X> simply ugly. I do not have a silver bullet here, though.
>
> If you oppose the proposed change, I'll add "... except 'uid1:uid2' syntax,
> which could be mistakenly interpreted as
> Date: Thu, 16 Jan 2020 15:26:13 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jan 16, 2020 at 02:27:42PM +0100, Klemens Nanni wrote:
> > Just like vmctl(8), this implements the little convenience for ldomctl:
> >
> > $
On Thu, Jan 16, 2020 at 02:27:42PM +0100, Klemens Nanni wrote:
> Just like vmctl(8), this implements the little convenience for ldomctl:
>
> $ doas ./obj/ldomctl start -c guest4
> Connected to /dev/ttyV3 (speed 9600)
> ...
>
> To avoid duplicate code, I moved the now common
16 января 2020 г. 15:58:09 GMT+03:00, Klemens Nanni пишет:
>On Thu, Jan 16, 2020 at 01:16:27PM +0100, Alexandr Nedvedicky wrote:
>> sentence 'The syntax is similar to the one for ports' sets my
>expectations
>> I can define a range of users in the same way I define a range of
>ports.
>>
Hi Mark and Klemens,
Mark Kettenis wrote on Thu, Jan 16, 2020 at 02:46:02PM +0100:
> I suppose this is fine since vmctl(8) has the same option.
>
> However the way you change the usage output isn't quite right.
> Maybe "start" should go on a line of its own then.
That sounds reasonable.
> But
On Thu, Jan 16, 2020 at 02:46:02PM +0100, Mark Kettenis wrote:
> However the way you change the usage output isn't quite right. Maybe
> "start" should go on a line of its own then. But then we're back to
> the discussion that too many lines make the usage output useless.
You mean because the
> Date: Thu, 16 Jan 2020 14:27:42 +0100
> From: Klemens Nanni
>
> Just like vmctl(8), this implements the little convenience for ldomctl:
>
> $ doas ./obj/ldomctl start -c guest4
> Connected to /dev/ttyV3 (speed 9600)
> ...
>
> To avoid duplicate code, I moved the now
> Date: Thu, 16 Jan 2020 10:52:06 +0100
> From: Martin Pieuchot
>
> Found while compiling sgi kernel:
>
> /sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
> (aka 'signed char') changes value from 148 to -108
> [-Werror,-Wconstant-conversion]
>
Just like vmctl(8), this implements the little convenience for ldomctl:
$ doas ./obj/ldomctl start -c guest4
Connected to /dev/ttyV3 (speed 9600)
...
To avoid duplicate code, I moved the now common exec routine into
console_exec() which is used by guest_console() and
On 2020/01/16 13:58, Klemens Nanni wrote:
> On Thu, Jan 16, 2020 at 01:16:27PM +0100, Alexandr Nedvedicky wrote:
> > sentence 'The syntax is similar to the one for ports' sets my
> > expectations
> > I can define a range of users in the same way I define a range of ports.
> > Looks
On Thu, Jan 16, 2020 at 01:16:27PM +0100, Alexandr Nedvedicky wrote:
> sentence 'The syntax is similar to the one for ports' sets my expectations
> I can define a range of users in the same way I define a range of ports.
> Looks useful to me, though a bug in parse.y might be just a tip
On Thu, Jan 16, 2020 at 10:52:06AM +0100, Martin Pieuchot wrote:
> Found while compiling sgi kernel:
>
> /sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
> (aka 'signed char') changes value from 148 to -108
> [-Werror,-Wconstant-conversion]
>
Hello,
>
> > Looks like Vadim found a bug and I'll take a look at the patch
> > he has sent.
> Where do you see a bug?
>
at description of 'user' match the pf.conf(5) reads as follows:
User and group IDs can be specified as either numbers or names.
The syntax is
On Thu, Jan 16, 2020 at 10:52:06AM +0100, Martin Pieuchot wrote:
> Found while compiling sgi kernel:
>
> /sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
> (aka 'signed char') changes value from 148 to -108
> [-Werror,-Wconstant-conversion]
>
On Thu, Jan 16, 2020 at 12:30:07PM +0100, Alexandr Nedvedicky wrote:
> On Wed, Jan 15, 2020 at 11:14:43PM -0700, Theo de Raadt wrote:
> > What does 1234:12345 mean. It must be uid 1234 _and_ gid 12345?
This is how I would interpret it, as that's existing semantic for
ownership handling in
On Thu, Jan 16, 2020 at 03:54:25AM +0300, Vadim Zhukov wrote:
> I've just found that pfctl doesn't like 'X:Y' syntax for user and group
> clauses, despite of the words in manpage.
Which wording are you referring to exactly? To me the entire user and
group documentation in pf.conf(5) is clear
Hello,
just to clarify the user and group match in pf.conf
On Wed, Jan 15, 2020 at 11:14:43PM -0700, Theo de Raadt wrote:
> I'll bite, using text from your regress.
>
> > +pass out proto tcp all user 1234:12345 flags S/SA
> > +pass out proto tcp all user 0:12345 flags S/SA
> > +pass out proto
On Mon, Jan 13, 2020 at 02:02:58PM +0100, Martin Pieuchot wrote:
> > Please, make this 10ms; that is what we have now and 100ms would
> > defenitely be too long.
>
> Sure, updated diff below.
OK kn
While discussing recent config_detach(9) vs close(2) race I figured
out that the 'indirect' flag (`cd_indirect') is never set.
Time to kill this feature?
This survived build on x86, armv7, sgi, hppa, luna88k, alpha, landisk,
sparc64.
Ok?
Index: sys/sys/device.h
Found while compiling sgi kernel:
/sys/netinet/igmp.c:140:22: error: implicit conversion from 'int' to 'int8_t'
(aka 'signed char') changes value from 148 to -108
[-Werror,-Wconstant-conversion]
ra->ipopt_list[0] = IPOPT_RA;
~ ^~~~
42 matches
Mail list logo
