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: /cvs/src/sbi
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.
regards
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 sa
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 +0200
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.
Wel
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
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
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&R :-)). I wish with time I'll learn how
> > to do it.
>
> IIRC, you said you saw some undesirable behavio
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&R :-)). I wish with time I'll learn how
> to do it.
IIRC, you said you saw some undesirable behaviour with ks
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 d
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;
> > >
> > >
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 r
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 LIST_EN
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 platf
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
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&R :-)). 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 rec
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 "
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 m_def
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 i
Hi Nicholas,
Nicholas Marriott wrote on Fri, May 19, 2017 at 11:46:52PM +0100:
> On Fri, May 19, 2017 at 10:23:08PM +0200, Ingo Schwarze wrote:
>> What matters most is that sending an incomplete character
>> followed by U+0008 (ASCII BACKSPACE) is a no-op, both in the sense
>> that it doesn't cha
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 sh
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 t
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 belo
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 ker
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
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.
>
> that means if you
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. Pe
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 just muscle memory but the fact that some people includin
> 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 had
>>> hostname.vlanX files without an explicit "vlan
> 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. yes.
>
> that means if you change the vn
> 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-run netstart la
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 any
32 matches
Mail list logo