Re: Merge pfkeyv2_socket and rawcb into one struct

On 30/05/17(Tue) 14:05, Claudio Jeker wrote: > This is more or less the same thing for PF_KEY that we now do in PF_ROUTE. > Use one PCB LIST on the keycb and embedd the rawcb in that PF_KEY cb. > Diff also has a few variable renames in it to make this code less alien > regarding the rest of our

Re: ksh(1): vi mode UTF-8 bug

Hi Walter, Walter Alejandro Iglesias wrote on Sun, Jun 04, 2017 at 11:45:04AM +0200: > I realized the issue I describe in the message below I don't understand at all what you are trying to talk about. For a proper bug report, please send the exact byte sequence that you are passing in to the

Re: ksh(1): don't output invalid UTF-8 characters

Hi Anton, Anton Lindqvist wrote on Sun, Jun 04, 2017 at 11:09:35AM +0200: > Although this discussion hasn't settled, True. I think nicm@ has convinced me that the shell *can* try to be nicer towards terminals, without risking hangs if done very carefully. Probably that's worth doing, it makes

Re: remove vlan specific ifconfig settings

On 2017/06/05 09:49, Reyk Floeter wrote: > > > Am 05.06.2017 um 09:35 schrieb Reyk Floeter : > > > > > >> Am 05.06.2017 um 09:26 schrieb David Gwynne : > >> > >> > >>> On 5 Jun 2017, at 17:05, Reyk Floeter wrote: > >>> > >>> Well, not

routing sockets vs KERNEL_LOCK()

Routing sockets are not protected by the NET_LOCK(). That's one of the boundaries of the network stack. That's whhy claudio@ sent some diffs to no longer require the KERNEL_LOCK() to protect them. But right now some rtm_* functions can be executed without KERNEL_LOCK(). That's wrong. Diff

Re: let's add PF_LOCK()

On 01/06/17(Thu) 09:32, Alexandr Nedvedicky wrote: > [...] > > > > Where do you want to define this WITH_PF_LOCK? > > > > I currently add > > option WITH_PF_LOCK > > to sys/arch/amd64/compile/GENERIC.MP to build PF with PF_LOCK. > But there should be better place in tree.

Re: remove vlan specific ifconfig settings

On Mon, Jun 05, 2017 at 05:26:58PM +1000, David Gwynne wrote: > > > On 5 Jun 2017, at 17:05, Reyk Floeter wrote: > > > > Well, not just muscle memory but the fact that some people including me had > > hostname.vlanX files without an explicit "vlan X" in it. > > hrm. yes. >

Re: move pbc list from rawcb to routecb (and later pfkey cb)

On 30/05/17(Tue) 13:59, Claudio Jeker wrote: > This is a step I need to do to make progress on the PF_KEY cleanup I'm > doing. Both PF_ROUTE and PF_KEY need to start to take care of their own > PCB list and so move the LIST_ENTRY out of rawcb into routecb. > This allows me to do the same in PF_KEY

Re: ksh(1): don't output invalid UTF-8 characters

Just to applogize to developers here, I'm still not skilled enough to make a proper patch or a clear bug report (I'm on chapter 2 of K :-)). I wish with time I'll learn how to do it. I came to the ksh utf8 discussion because I've been playing with some mail mime encoder just to learn C and

Re: sshd: Remove authorized_keys2 file

Bump: Feeback? OK? On Mon, Apr 17, 2017 at 09:28:29PM +0200, Klemens Nanni wrote: Now that protocol version 1 was finally dropped in sshd(8), get rid of this file completely. Our default sshd_config(5) overwrites AuthorizedKeysFile to ignore it anyway and sshd(8)'s FILES section doesn't mention

Re: tweak txp to avoid ifq_deq_begin/commit/rollback

On Wed, May 31, 2017 at 20:40 +0200, Mike Belopuhov wrote: > According to the FreeBSD driver, txp(4) is not setting up its TX > ring correctly. FreeBSD driver uses up to 16 fragments, while we > use up to 252 which is suspicious. > > This gets us in line with FreeBSD, introduces goodness of

Re: i386 clang: fix binutils build

Todd C. Miller: > I think you want 0xU, not 0xL. Otherwise you will > have the same issue on i386. ??? We need a constant that comes out as the "long" value 0x on 64-bit platforms 0x on 32-bit platforms (degenerate case) -- Christian

Re: routing sockets vs KERNEL_LOCK()

On 05/06/17(Mon) 12:12, Martin Pieuchot wrote: > Routing sockets are not protected by the NET_LOCK(). That's one of the > boundaries of the network stack. That's whhy claudio@ sent some diffs > to no longer require the KERNEL_LOCK() to protect them. > > But right now some rtm_* functions can be

Re: i386 clang: fix binutils build

On Mon, 05 Jun 2017 16:32:01 +0200, Christian Weisgerber wrote: > Todd C. Miller: > > > I think you want 0xU, not 0xL. Otherwise you will > > have the same issue on i386. > > ??? > > We need a constant that comes out as the "long" value > 0x on 64-bit

Re: move pbc list from rawcb to routecb (and later pfkey cb)

On 05/06/17(Mon) 17:32, Claudio Jeker wrote: > On Mon, Jun 05, 2017 at 11:32:06AM +0200, Martin Pieuchot wrote: > > On 30/05/17(Tue) 13:59, Claudio Jeker wrote: > > > - struct rawcb*rp; > > > struct routecb *rop; > > > int af; > > > int error = 0; > > > > > >

Re: move pbc list from rawcb to routecb (and later pfkey cb)

On Mon, Jun 05, 2017 at 11:32:06AM +0200, Martin Pieuchot wrote: > On 30/05/17(Tue) 13:59, Claudio Jeker wrote: > > This is a step I need to do to make progress on the PF_KEY cleanup I'm > > doing. Both PF_ROUTE and PF_KEY need to start to take care of their own > > PCB list and so move the

Re: Merge pfkeyv2_socket and rawcb into one struct

On Mon, Jun 05, 2017 at 11:39:14AM +0200, Martin Pieuchot wrote: > On 30/05/17(Tue) 14:05, Claudio Jeker wrote: > > This is more or less the same thing for PF_KEY that we now do in PF_ROUTE. > > Use one PCB LIST on the keycb and embedd the rawcb in that PF_KEY cb. > > Diff also has a few variable

Re: i386 clang: fix binutils build

On Mon, 05 Jun 2017 09:18:31 -0600, "Todd C. Miller" wrote: > If you assign 0x to a long on i386 the compiler should warn > about it since it is too big to fit unless the value is unsigned. > That is why ULONG_MAX is defined as defined as 0xUL on > 32-bit platforms. I suppose it

Re: ksh(1): don't output invalid UTF-8 characters

Hi Walter, Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 04:50:21PM +0200: > I'm still not skilled enough to make a proper patch or a clear bug > report (I'm on chapter 2 of K :-)). I wish with time I'll learn how > to do it. IIRC, you said you saw some undesirable behaviour with ksh

Re: i386: sync trampoline code with amd64 for clang

On Sun, Jun 04, 2017 at 11:46:00PM +0200, Christian Weisgerber wrote: > This catches up i386 with the changes to acpi_wakecode.S and mptramp.s > that were made on amd64 for clang. Here's kettenis@'s original > commit message: > > ---> > Generating mixed 16-bit/32-bit/64-bit code

Re: remove vlan specific ifconfig settings

Well, not just muscle memory but the fact that some people including me had hostname.vlanX files without an explicit "vlan X" in it. And I did like the implicit tags, despite your vlan6000 problem that nobody ever had ;-) But it is time to move on, we have to cope with it. So no objections

Re: remove vlan specific ifconfig settings

> On 5 Jun 2017, at 17:05, Reyk Floeter wrote: > > Well, not just muscle memory but the fact that some people including me had > hostname.vlanX files without an explicit "vlan X" in it. hrm. yes. that means if you change the vnetid on such an interface at runtime, and then

Re: remove vlan specific ifconfig settings

> Am 05.06.2017 um 09:26 schrieb David Gwynne : > > >> On 5 Jun 2017, at 17:05, Reyk Floeter wrote: >> >> Well, not just muscle memory but the fact that some people including me had >> hostname.vlanX files without an explicit "vlan X" in it. > > hrm.

Re: remove vlan specific ifconfig settings

> Am 05.06.2017 um 09:35 schrieb Reyk Floeter : > > >> Am 05.06.2017 um 09:26 schrieb David Gwynne : >> >> >>> On 5 Jun 2017, at 17:05, Reyk Floeter wrote: >>> >>> Well, not just muscle memory but the fact that some people including me

ifconfig.8 doco for vnetid and parent options

this adds doco for the parent options in ifconfig, and moves vnetid up into generic options list. the vlan(4) specific doco has enough lies and omissions that id rather get rid of it. ok? Index: ifconfig.8 === RCS file:

Re: ksh(1): don't output invalid UTF-8 characters

On Mon, Jun 05, 2017 at 06:06:34PM +0200, Ingo Schwarze wrote: > Hi Walter, > > Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 04:50:21PM +0200: > > > report (I'm on chapter 2 of K :-)). I wish with time I'll learn how > > to do it. > > IIRC, you said you saw some undesirable

Re: ksh(1): don't output invalid UTF-8 characters

On Mon, Jun 05, 2017 at 09:21:31PM +0200, Walter Alejandro Iglesias wrote: > > I wonder how plan9 handle utf8. > In general, by getting rid of TTYs and character-addressed interfaces almost entirely. Probably not the best fit for OpenBSD. khm

Re: ksh(1): don't output invalid UTF-8 characters

In article <20170605192131.ga60...@server.roquesor.com> you wrote: > >Encodings using more bytes than required are invalid. In particular, >1100 and 1101 are not valid start bytes, the byte after >1110 must be at least 1010, and the byte after must >be at

Re: ksh(1): don't output invalid UTF-8 characters

Hi Walter, Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 09:21:31PM +0200: > On Mon, Jun 05, 2017 at 06:06:34PM +0200, Ingo Schwarze wrote: >> Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 04:50:21PM +0200: > But this time I don't think you need a capture of the sequence.

Re: ksh(1): don't output invalid UTF-8 characters

On Mon, Jun 05, 2017 at 10:46:49PM +0200, Ingo Schwarze wrote: > Hi Walter, > > Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 09:21:31PM +0200: > > On Mon, Jun 05, 2017 at 06:06:34PM +0200, Ingo Schwarze wrote: > >> Walter Alejandro Iglesias wrote on Mon, Jun 05, 2017 at 04:50:21PM

Re: let's add PF_LOCK()

Hello, > I don't think it matters. We still need more diffs to be able to test > that. > > Now I'd really like if you could commit this so we continue improving it > in-tree. I've commit the patch _without_ the diff to sys/conf/GENERIC, we can add it later, once more diffs will be in.

Re: release(8): add command example to step 3 for sysmerge(8)/MAKEDEV(8)

On Sun, Jun 04, 2017 at 05:57:01PM -0500, Scott Cheloha wrote: > Hi, > > There is no command-line sample at the end of step 3 in release(8): > > After the build is completed, update /etc, /var, and /dev, > using sysmerge(8) and MAKEDEV(8). > > While needs vary by site, providing a