David Gwynne wrote:
> this is a reposting of the diff i sent out a while back. it lets sparc64
> enable iommu bypass, and then uses that bypass support for BUS_DMA_64BIT
> dmamaps.
BTW, this is in snapshots and I'd urge everyone running sparc64 to give it
a try.
Not without further measurement of all applications.
Imagine if this gets commited, and causes kernel memory shortage
and deadlock.
Shall we all then point fingers at you for experimenting live?
I know I will.
Claudio Jeker wrote:
> I noticed that by default the send and recv socket buffers
Claudio Jeker wrote:
> I guess a lot of processes could benefit from increased buffers. For
> example firefox and chrome are heavy users of unix sockets. I remember
> that we already added something in Xorg to bump the buffer size.
> A quick check tells me that most unix sockets have sb_hiwat
Martin Pieuchot wrote:
> On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > I noticed that by default the send and recv socket buffers for
> > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> > write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> >
On Mon, Jun 17, 2019 at 10:20:57PM +0200, Sebastian Benoit wrote:
> Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.17 21:34:30 +0200:
> > Hi,
> >
> > Now that the community rewrite is in here another diff to make bgpd more
> > awesome. There was one loop left that did not run asynchronous
Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.17 22:38:00 +0200:
> On Mon, Jun 17, 2019 at 05:00:32PM -0300, Martin Pieuchot wrote:
> > On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > > I noticed that by default the send and recv socket buffers for
> > > socketpair(2) is rather low (4k
On Mon, Jun 17, 2019 at 05:00:32PM -0300, Martin Pieuchot wrote:
> On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > I noticed that by default the send and recv socket buffers for
> > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> > write/read behaviour on the imsg
Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.17 21:34:30 +0200:
> Hi,
>
> Now that the community rewrite is in here another diff to make bgpd more
> awesome. There was one loop left that did not run asynchronous compared to
> the main event loop. This loop was in nexthop_update() now a
On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> I noticed that by default the send and recv socket buffers for
> socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> SO_RCVBUF seems to help increase the data
I noticed that by default the send and recv socket buffers for
socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
SO_RCVBUF seems to help increase the data sent and received per syscall.
Another option would
Hi,
Now that the community rewrite is in here another diff to make bgpd more
awesome. There was one loop left that did not run asynchronous compared to
the main event loop. This loop was in nexthop_update() now a route server
or a big route reflector would be hit hard by this loop since it will
Florian Obser(flor...@openbsd.org) on 2019.06.17 17:36:28 +0200:
> OK?
after reading the manpage, it seems to be ok.
> diff --git key.c key.c
> index 02c04a03419..b701cf85467 100644
> --- key.c
> +++ key.c
> @@ -81,11 +81,8 @@ ec_key_create(FILE *f, const char *fname)
> EC_KEY
espie found a bug. we reset PATH in the parent too soon, and then it's not
possible to change it back via setenv.
instead of trying to move code around, save a copy of the path before we mess
with it and make it available later. this lets setenv { PATH=$PATH } work.
Index: doas.c
Exception handling code on superH and m88k does not check for a valid
stack pointer, like other platforms do.
The following (mechanical) diff addresses the m88k case, and has been
tested to work on 88100 and 88110 processors.
Index: sys/arch/m88k/m88k/trap.c
Committed, thanks!
On Mon, Jun 17, 2019 at 07:53:50PM +0200, Mark Kettenis wrote:
> > From: James Hastings
> > Date: Mon, 17 Jun 2019 13:24:36 -0400 (EDT)
>
> This diff is ok kettenis@
>
> It might take a few days for me to commit this. If anybody else wants
> to do it based on my ok, go
> From: James Hastings
> Date: Mon, 17 Jun 2019 13:24:36 -0400 (EDT)
This diff is ok kettenis@
It might take a few days for me to commit this. If anybody else wants
to do it based on my ok, go ahead.
> Index: share/man/man4/Makefile
>
Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.713
diff -u -p -u -r1.713 Makefile
--- share/man/man4/Makefile 7 Jun 2019 16:06:59 - 1.713
+++ share/man/man4/Makefile
On Mon, 17 Jun 2019 13:17:15 -0400, "Ted Unangst" wrote:
> Not sure what you mean. This diff does put it before the options.
>
> same place as su, although su has other problems. fortunately, we don't have
> the same combination of possibilities as su.
Sorry, I misread the diff. The placement
Todd C. Miller wrote:
> On Mon, 17 Jun 2019 12:58:00 -0400, "Ted Unangst" wrote:
>
> > Committed this. I'm not entirely happy with the wording. I think hiding them
> > under an option in the config man page is the wrong place. The default
> > behavior should be documented in a more default place.
On Mon, 17 Jun 2019 12:58:00 -0400, "Ted Unangst" wrote:
> Committed this. I'm not entirely happy with the wording. I think hiding them
> under an option in the config man page is the wrong place. The default
> behavior should be documented in a more default place.
I would just place that bit
Ted Unangst wrote:
> Yes, I think it's better to always reset these things. Here's a diff.
>
> 1. Always set HOME, PATH, SHELL etc to the target.
Committed this. I'm not entirely happy with the wording. I think hiding them
under an option in the config man page is the wrong place. The default
On Mon, Jun 17, 2019 at 05:31:16PM +0200, Tim van der Molen wrote:
> Jason McIntyre (2019-06-17 15:02 +0200):
> > On Mon, Jun 17, 2019 at 02:47:09PM +0200, Tim van der Molen wrote:
> > > sftp(1) has this:
> > >
> > > reput [-Ppr] [local-path] remote-path
> > > Resume upload of
OK?
diff --git key.c key.c
index 02c04a03419..b701cf85467 100644
--- key.c
+++ key.c
@@ -81,11 +81,8 @@ ec_key_create(FILE *f, const char *fname)
EC_KEY *eckey = NULL;
EVP_PKEY*pkey = NULL;
- if ((eckey = EC_KEY_new()) == NULL ) {
-
Jason McIntyre (2019-06-17 15:02 +0200):
> On Mon, Jun 17, 2019 at 02:47:09PM +0200, Tim van der Molen wrote:
> > sftp(1) has this:
> >
> > reput [-Ppr] [local-path] remote-path
> > Resume upload of [local-path]. Equivalent to put with the -a
> > flag set.
> >
> >
On Sun, 16 Jun 2019 14:23:24 -0400, "Ted Unangst" wrote:
> Yes, I think it's better to always reset these things. Here's a diff.
>
> 1. Always set HOME, PATH, SHELL etc to the target.
>
> 2. Without keepenv, other environment variables are discarded.
>
> 3. With keepenv, other variables are
On 6/17/19 3:33 PM, Theo Buehler wrote:
On Mon, Jun 17, 2019 at 01:44:47PM +0200, Renaud Allard wrote:
Hello,
EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
EVP_MD_CTX_free(). So replace the occurrences
On Mon, Jun 17, 2019 at 01:44:47PM +0200, Renaud Allard wrote:
> Hello,
>
> EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
> deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
> EVP_MD_CTX_free(). So replace the occurrences to be future proof.
>
> Comments?
Martin, good day.
Sun, Jun 09, 2019 at 11:44:10AM -0300, Martin Pieuchot wrote:
> On 07/06/19(Fri) 20:50, Eygene Ryabinkin wrote:
> > The attached patch fixes incoming interface for pf(4) processing
> > in the case of bridging of multiple VLAN interfaces which have
> > the same parent iface and
> this stores 104 bytes with an NID_secp384r1 key
Yes, this was a pure brainf^Wscrewup on my part, sorry.
> EVP_MAX_MD_SIZE seems to be about digests, not signatures. Did you
> have a different constant in mind or did you get confused by the
> poorly worded variable?
Yes, you're right, I just
On 6/17/19 2:58 PM, Florian Obser wrote:
What would be the correct calculation for a GF2m field? Should I maybe just
ignore it? RFC 7518 only lists P-256, P-384 and P-521 (and I think
Let's Encrypt only supports P-384 anyway), and they are all GFp, no?
Let's Encrypt accepts P-256 and P-384
On Mon, Jun 17, 2019 at 02:47:09PM +0200, Tim van der Molen wrote:
> sftp(1) has this:
>
> reput [-Ppr] [local-path] remote-path
> Resume upload of [local-path]. Equivalent to put with the -a
> flag set.
>
> remote-path should be marked optional, not local-path.
On Sun, Jun 16, 2019 at 08:44:46PM +0200, Theo Buehler wrote:
> On Sun, Jun 16, 2019 at 09:25:45AM +0200, Florian Obser wrote:
> > On Sat, Jun 15, 2019 at 06:20:49PM +0200, Florian Obser wrote:
> > > OK?
> >
> > update to apply cleanly on -current
>
> The acctproc.c change looks ok with some
sftp(1) has this:
reput [-Ppr] [local-path] remote-path
Resume upload of [local-path]. Equivalent to put with the -a
flag set.
remote-path should be marked optional, not local-path. Probably a pasto
from reget.
OK?
Index: sftp.1
Hello,
EVP_MD_CTX_create(), EVP_MD_CTX_cleanup(), and EVP_MD_CTX_destroy() are
deprecated aliases for EVP_MD_CTX_new(), EVP_MD_CTX_reset(), and
EVP_MD_CTX_free(). So replace the occurrences to be future proof.
Comments?
Index: acctproc.c
On Mon, Jun 17, 2019 at 06:15:16PM +1000, Jonathan Gray wrote:
>
> On Mon, Jun 17, 2019 at 02:45:28PM +0800, Kevin Lo wrote:
> > ok?
>
> The header also includes EM_PPC64 which isn't documented
> (and EM_X86_64 which should probably be kept not documented).
Documented EM_PPC64, thanks.
On Mon, Jun 17, 2019 at 03:22:40AM -0400, James Hastings wrote:
> Index: share/man/man4/Makefile
> ===
morning.
the doc parts looks fine to me. can you add an $OpenBSD$ id to the man
page as well. i guess the .c file added should
On Mon, Jun 17, 2019 at 10:17:17AM +0200, Gilles Chehade wrote:
> On Mon, Jun 17, 2019 at 10:12:52AM +0200, alf wrote:
> > Hello,
> >
> > while adding a missing "the" for tls_config_set_cert_file
> > it appeared to me that "file" and "filename" are used
> > inconsistent. I went with "file" since
On Mon, Jun 17, 2019 at 10:12:52AM +0200, alf wrote:
> Hello,
>
> while adding a missing "the" for tls_config_set_cert_file
> it appeared to me that "file" and "filename" are used
> inconsistent. I went with "file" since "filename" to my
> eyes/ears implies the filename without path, however
On Mon, Jun 17, 2019 at 02:45:28PM +0800, Kevin Lo wrote:
> ok?
The header also includes EM_PPC64 which isn't documented
(and EM_X86_64 which should probably be kept not documented).
>
> Index: share/man/man5/elf.5
> ===
> RCS
Hello,
while adding a missing "the" for tls_config_set_cert_file
it appeared to me that "file" and "filename" are used
inconsistent. I went with "file" since "filename" to my
eyes/ears implies the filename without path, however that
maybe wrong.
Alf
Index: lib/libtls/man/tls_load_file.3
Index: sys/dev/pci/sdhc_pci.c
===
RCS file: /cvs/src/sys/dev/pci/sdhc_pci.c,v
retrieving revision 1.20
diff -u -p -u -r1.20 sdhc_pci.c
--- sys/dev/pci/sdhc_pci.c 30 Apr 2016 11:32:23 - 1.20
+++ sys/dev/pci/sdhc_pci.c
Index: share/man/man4/Makefile
===
RCS file: /cvs/src/share/man/man4/Makefile,v
retrieving revision 1.713
diff -u -p -u -r1.713 Makefile
--- share/man/man4/Makefile 7 Jun 2019 16:06:59 - 1.713
+++ share/man/man4/Makefile
ok?
Index: share/man/man5/elf.5
===
RCS file: /cvs/src/share/man/man5/elf.5,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 elf.5
--- share/man/man5/elf.527 Oct 2017 08:36:42 - 1.34
+++ share/man/man5/elf.5
43 matches
Mail list logo
