From: "Maciej W. Rozycki" <macro@mips.com>
To: John Baldwin <jhb@freebsd.org>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Workaround a FreeBSD ptrace() bug with clearing thread events.
Date: Sat, 03 Mar 2018 17:45:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.00.1803031733050.10166@tp.orcam.me.uk> (raw)
In-Reply-To: <2023036.DDCG60uWOK@ralph.baldwin.cx>
On Fri, 2 Mar 2018, John Baldwin wrote:
> > Is the one-way compatibility enforced though, by a system library runtime
> > or the kernel somehow, by refusing to run a binary built for a kernel that
> > is newer than one currently in charge of the system? Otherwise the rule
> > would be quite fragile and error prone, asking for extra care to be taken
> > by the user.
>
> It is enforced in some ways but not others. Kernel modules do depend on a
> version number in such a way that attempting to load a newer kernel module
> on an older kernel will fail. However, the general policy of only supporting
> one-way compatibility is well-known among the FreeBSD userbase (for example,
> the instructions for upgrading a system from source require booting into a
> new kernel before installing the matching userland binaries).
That all sounds right, however does not really address my concern where a
user *unknowingly* tries a program binary that has been compiled for a
newer kernel version and then faces all kinds of issues. This is bound to
happen sooner or later for someone, the Murphy's law guarantees it.
Maciej
prev parent reply other threads:[~2018-03-03 17:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-24 0:10 John Baldwin
2018-02-26 4:28 ` Joel Brobecker
2018-02-26 17:25 ` John Baldwin
2018-03-02 0:51 ` Maciej W. Rozycki
2018-03-02 18:32 ` John Baldwin
2018-03-02 20:09 ` Maciej W. Rozycki
2018-03-02 22:48 ` John Baldwin
2018-03-03 17:45 ` Maciej W. Rozycki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.00.1803031733050.10166@tp.orcam.me.uk \
--to=macro@mips.com \
--cc=gdb-patches@sourceware.org \
--cc=jhb@freebsd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox