Date:Sat, 25 Feb 2017 18:13:34 +1100
From:matthew green
Message-ID: <14043.1488006...@splode.eterna.com.au>
| there's a rough ability to "guess" you have a matching kernel/kmem
| groveller based upon the version. eg, crash(8) will notice a
| mismatch and tell y
> | * changes to things that kmem grovelers chase
>
> I don't think kernel version bumps really help there either - for those
> I think it is normal just to expect that a kmem groveller (of which there
> are not many left, fortunately) might need to match the kernel version if
> it is to be expe
> I'm evaluating it from the osabi (pkgsrc term) point of view. I'm
> targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for
> loadable kernel modules, I will follow this in future changes.
it's about whether code is expected to work in that kernel
environment or not. it's not j
Date:Fri, 24 Feb 2017 19:24:34 +0800 (PHT)
From:Paul Goyette
Message-ID:
| In many cases, one might just "ride the previous bump"
Yes, I've seen that happen several times, but it would be much nicer
to predict the bump, than to react to it.
kre
On Fri, 24 Feb 2017, Robert Elz wrote:
Date:Fri, 24 Feb 2017 09:04:36 +0100
From:Martin Husemann
Message-ID: <20170224080436.gb1...@mail.duskware.de>
| (and we already had a bump just a few hours earlier).
It would indeed be useful if, when a change that requires a
Date:Fri, 24 Feb 2017 09:04:36 +0100
From:Martin Husemann
Message-ID: <20170224080436.gb1...@mail.duskware.de>
| (and we already had a bump just a few hours earlier).
It would indeed be useful if, when a change that requires a kernel version
change is expected to
On Thu, Feb 23, 2017 at 11:57:36PM +0100, Kamil Rytarowski wrote:
> My bump was still legitimate as I changed size of amd64 and i386 struct
> lwp - I removed one MD field.
Yeah, that is all fine. I was just confused because the specific commit
did not seem to want a bump, and while numbers are ple
Date:Thu, 23 Feb 2017 23:57:36 +0100
From:Kamil Rytarowski
Message-ID:
| My bump was still legitimate as I changed size of amd64 and i386 struct
| lwp - I removed one MD field.
Yes, I agree, and said that in my first message in this thread, before
it mprphed in
On 23.02.2017 09:48, Robert Elz wrote:
> Date:Thu, 23 Feb 2017 15:32:16 +0800 (PHT)
> From:Paul Goyette
> Message-ID:
>
> | On Thu, 23 Feb 2017, Kamil Rytarowski wrote:
> |
> | > I'm evaluating it from the osabi (pkgsrc term) point of view. I'm
> | > targeti
Date:Thu, 23 Feb 2017 15:32:16 +0800 (PHT)
From:Paul Goyette
Message-ID:
| On Thu, 23 Feb 2017, Kamil Rytarowski wrote:
|
| > I'm evaluating it from the osabi (pkgsrc term) point of view. I'm
| > targeting LLDB for 7.99.62+.
The kernel version number is a h
On 23.02.2017 08:32, Paul Goyette wrote:
> On Thu, 23 Feb 2017, Kamil Rytarowski wrote:
>
>> I'm evaluating it from the osabi (pkgsrc term) point of view. I'm
>> targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for
>> loadable kernel modules, I will follow this in future chan
On Thu, 23 Feb 2017, Kamil Rytarowski wrote:
I'm evaluating it from the osabi (pkgsrc term) point of view. I'm
targeting LLDB for 7.99.62+. If the kernel bump approach is reserved for
loadable kernel modules, I will follow this in future changes.
Modules (and specifically, their interfaces to
On 23.02.2017 07:23, Robert Elz wrote:
> Date:Thu, 23 Feb 2017 05:29:41 +
> From:Martin Husemann
> Message-ID: <20170223052941.ga29...@homeworld.netbsd.org>
>
> | Does this kind of change really require a version bump?
>
> That one didn't, but there was anoth
Date:Thu, 23 Feb 2017 05:29:41 +
From:Martin Husemann
Message-ID: <20170223052941.ga29...@homeworld.netbsd.org>
| Does this kind of change really require a version bump?
That one didn't, but there was another checkin, 5 or 6 mins earlier,
which changed (added t
On Thu, Feb 23, 2017 at 03:48:20AM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Thu Feb 23 03:48:20 UTC 2017
>
> Modified Files:
> src/sys/sys: param.h
>
> Log Message:
> Welcome to 7.99.62!
>
> New ptrace(2) operations:
> - PT_RESUME
> - PT_SU
15 matches
Mail list logo