jca@ has already oked this. anyone else want to get on board?
Index: ip_ether.c
===
RCS file: ip_ether.c
diff -N ip_ether.c
--- ip_ether.c 10 Feb 2018 08:12:01 - 1.99
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,28 +0,0
On 04.10.2019 15:54, Mike Belopuhov wrote:
> Thanks a lot for dmesgs. Do I understand correctly that paravirtualized
> disk and network work fine for you regardless of whether OpenBSD-current,
> attached one-liner diff or the linked larger diff are used?
>
> With best regards,
> Mike
I'm not
Andre Stoebe writes:
> On 03.10.2019 02:13, Mike Belopuhov wrote:
>> And what about OpenBSD-current or an attached patch as opposed
>> to the linked one?
>>
>> Please don't go half the way if you're willing to help us out,
>> we'd like to make OpenBSD 6.6-release work in these setups
>>
On Fri, Oct 04, 2019 at 12:35:40PM +0100, Stuart Henderson wrote:
> On 2019/10/04 07:22, sven falempin wrote:
> > On Fri, Oct 4, 2019 at 4:29 AM Stuart Henderson
> > wrote:
> >
> > > On 2019/10/03 11:56, sven falempin wrote:
> > > > BTW, on modern system RAM is plentiful while SSD are not
Hi All,
Does it make sense to add my talk on vmm/vmd at EuroBSDCon to the events.html
page?
If it does, below is the diff. (Thanx Paul! :))
Mischa
Index: events.html
===
RCS file: /home/OpenBSD/cvs/www/events.html,v
retrieving
On 2019/10/04 07:22, sven falempin wrote:
> On Fri, Oct 4, 2019 at 4:29 AM Stuart Henderson wrote:
>
> > On 2019/10/03 11:56, sven falempin wrote:
> > > BTW, on modern system RAM is plentiful while SSD are not always '/tmp'
> > > friendly.
> >
> > Some of the slower media (CF/SD cards etc) might
On Fri, Oct 4, 2019 at 4:29 AM Stuart Henderson wrote:
> On 2019/10/03 11:56, sven falempin wrote:
> > BTW, on modern system RAM is plentiful while SSD are not always '/tmp'
> > friendly.
>
> Some of the slower media (CF/SD cards etc) might have issues eventually but
> I would expect anything
Because of delaying the commits in the RDE it is now possible that table
additions and deletions mix. This triggers a fatal("attempt to mix pf table
additions/deletions") in the parent. Instead of the fatal() it is actually
safe to just commit the pending work and start with a fresh worklist
On 2019/10/03 11:56, sven falempin wrote:
> BTW, on modern system RAM is plentiful while SSD are not always '/tmp'
> friendly.
Some of the slower media (CF/SD cards etc) might have issues eventually but
I would expect anything worthy of the name 'SSD' should be fine.
> Using tmpfs for /tmp, vi
On Fri, Oct 04, 2019 at 10:09:06AM +0200, Martijn van Duren wrote:
> On 10/4/19 10:03 AM, gil...@poolp.org wrote:
> > October 4, 2019 9:55 AM, "Martijn van Duren"
> > wrote:
> >>
> >> This is similar to the diff I send a few months ago, but still doesn't
> >> fix the case when someone sends a
On 10/4/19 10:03 AM, gil...@poolp.org wrote:
> October 4, 2019 9:55 AM, "Martijn van Duren"
> wrote:
>>
>> This is similar to the diff I send a few months ago, but still doesn't
>> fix the case when someone sends a standalone '\n' as line-ending.
>>
>
> Unsure I understand that, can you
October 4, 2019 9:55 AM, "Martijn van Duren"
wrote:
>
> This is similar to the diff I send a few months ago, but still doesn't
> fix the case when someone sends a standalone '\n' as line-ending.
>
Unsure I understand that, can you elaborate ?
> I'd prefer if we go with reverting (=my
On Fri, Oct 04 2019, David Gwynne wrote:
> so we can remove it, starting with taking it out of sys/conf/files.
>
> ok?
I once had a similar diff. ok for this and the ip_ether.c removal.
> Index: files
> ===
> RCS file:
On 10/4/19 9:36 AM, Gilles Chehade wrote:
> On Fri, Oct 04, 2019 at 08:43:28AM +0200, Martijn van Duren wrote:
annoying bumps will just be moved around. If we *really* want to fix
this we need to make it fit within the specifications:
[...]
This means stop
On Fri, Oct 04, 2019 at 08:43:28AM +0200, Martijn van Duren wrote:
> >> annoying bumps will just be moved around. If we *really* want to fix
> >> this we need to make it fit within the specifications:
> >>
> >> [...]
> >>
> >> This means stop opportunistic scanning for '\r' in iobuf!
> >>
> >
> >
On 10/4/19 8:23 AM, Gilles Chehade wrote:
> On Fri, Oct 04, 2019 at 07:35:39AM +0200, Martijn van Duren wrote:
>> On 10/3/19 9:05 PM, Eric Faurot wrote:
>>> On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
>>>
> To me, the only real problem with '\r' is at the end of lines.
On Fri, Oct 04, 2019 at 07:35:39AM +0200, Martijn van Duren wrote:
> On 10/3/19 9:05 PM, Eric Faurot wrote:
> > On Thu, Sep 19, 2019 at 05:48:17PM +, gil...@poolp.org wrote:
> >
> >>> To me, the only real problem with '\r' is at the end of lines. It's
> >>> confusing
> >>> since you never
17 matches
Mail list logo