Re: have m_copydata use a void * instead of caddr_t

On Tue, Feb 23, 2021 at 01:09:06PM +0100, Alexander Bluhm wrote: > On Tue, Feb 23, 2021 at 07:31:30PM +1000, David Gwynne wrote: > > i'm not a fan of having to cast to caddr_t when we have modern > > inventions like void *s we can take advantage of. > > Shoud you remove all the (caddr_t) casts in

mg: fix direction of mark-paragraph

The current direction of marking paragraphs using 'mark-paragraph' in mg is the opposite of emacs. Emacs goes backwards, mg goes forwards. This diff brings mg inline with emacs, and also simplifies the code, and fixes another bug with the current code. ok? Index: paragraph.c

Re: rpki-client don't clobber poll events

Definately! It will round-trip through poll() less often. Claudio Jeker wrote: > It is perfectly fine to wait for read and write at the same time. > The code in rpki-client should do that too, I think it will not matter > but it is what I intended. > > -- > :wq Claudio > > Index: main.c >

rpki-client don't clobber poll events

It is perfectly fine to wait for read and write at the same time. The code in rpki-client should do that too, I think it will not matter but it is what I intended. -- :wq Claudio Index: main.c === RCS file:

Re: sparc64/clock.c: use ANSI-style function definitions

Scott Cheloha wrote: > Any reason not to ANSIfy these? While we're here we can kill some > ARGUSED comments, too. Absolutely, go ahead with that. > I don't have a sparc64 machine so I'd appreciate a test compile. It compiles fine.

sparc64/clock.c: use ANSI-style function definitions

I'm poking around in this file and lo, K function definitions. Any reason not to ANSIfy these? While we're here we can kill some ARGUSED comments, too. I don't have a sparc64 machine so I'd appreciate a test compile. Assuming it compiles, ok? Index: clock.c

Re: rpki-client lock down rsync process further

OK with me. I'll say it again, the unveils in here are misguided. Almost as misguided as the mmap's (which prevents large file transfer, and there are other problems..) Claudio Jeker wrote: > There is no need for cpath or the unveil of . in the rsync process. > That process just does

Re: have m_copydata use a void * instead of caddr_t

On Tue, Feb 23, 2021 at 07:31:30PM +1000, David Gwynne wrote: > i'm not a fan of having to cast to caddr_t when we have modern > inventions like void *s we can take advantage of. Shoud you remove all the (caddr_t) casts in the callers then? Without that step this diff does not provide more

Re: have m_copydata use a void * instead of caddr_t

ok mvs@ > On 23 Feb 2021, at 12:31, David Gwynne wrote: > > i'm not a fan of having to cast to caddr_t when we have modern > inventions like void *s we can take advantage of. > > ok? > > Index: share/man/man9/mbuf.9 > === > RCS

Different fix for vnode deadlock

Page faults on vnode-backed objects commonly end up calling VOP_READ(9) or VOP_WRITE(9) to go through the buffer cache. This implies grabbing an inode lock after any UVM locking. On the other hand changing the size of a vnode results in entering UVM, generally via calling uvm_vnp_setsize() with

rpki-client lock down rsync process further

There is no need for cpath or the unveil of . in the rsync process. That process just does fork+exec for rsync. Removing the unveil pledge is the same as unveil(NULL, NULL) so skip that too. OK? -- :wq Claudio Index: main.c === RCS

allow xlock -dpms* values < 30 and > 0

Hi, I noticed that xlock does not allow values between 30 and 0 for options -dpms{standby,suspend,off}, the man page suggests that all values >= 0 are accepted. I use the blank mode and i would like to set a lower timeout so i made a patch to remove the limit. ok? Index:

have m_copydata use a void * instead of caddr_t

i'm not a fan of having to cast to caddr_t when we have modern inventions like void *s we can take advantage of. ok? Index: share/man/man9/mbuf.9 === RCS file: /cvs/src/share/man/man9/mbuf.9,v retrieving revision 1.120 diff -u -p

Re: uvm_fault_lower refactoring

> Date: Tue, 23 Feb 2021 10:07:43 +0100 > From: Martin Pieuchot > > On 23/02/21(Tue) 00:24, Mark Kettenis wrote: > > > Date: Mon, 22 Feb 2021 10:10:21 +0100 > > > From: Martin Pieuchot > > > > > > On 16/02/21(Tue) 11:20, Martin Pieuchot wrote: > > > > Start by moving `pgo_fault' handler

Re: uvm_fault_lower refactoring

On 23/02/21(Tue) 00:24, Mark Kettenis wrote: > > Date: Mon, 22 Feb 2021 10:10:21 +0100 > > From: Martin Pieuchot > > > > On 16/02/21(Tue) 11:20, Martin Pieuchot wrote: > > > Start by moving `pgo_fault' handler outside of uvm_fault_lower(). > > > > > > If a page has a backing object that prefer