From: Kamil Rytarowski <n54@gmx.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Implement "info proc mappings" for NetBSD
Date: Fri, 20 Mar 2020 20:13:24 +0100 [thread overview]
Message-ID: <9570eb83-e805-47e9-c334-3938beadfdb9@gmx.com> (raw)
In-Reply-To: <87eetmlv2y.fsf@tromey.com>
[-- Attachment #1.1: Type: text/plain, Size: 1455 bytes --]
On 20.03.2020 19:50, Tom Tromey wrote:
>>>>>> "Kamil" == Kamil Rytarowski <n54@gmx.com> writes:
>
> Kamil> I see. I prefer to keep this called obfd, as it matches the FreeBSD code
> Kamil> more closely. If we want to rename it, we shall do it also in FreeBSD.
>
> Well, that FreeBSD code is wrong too...
>
>>> What if they stop matching?
>
> Kamil> Not a concern.
>
> Kamil> If that will ever change, it will be patched, same as the other
> Kamil> existing NetBSD support.
>
> How will cross debugging to different versions work in this situation?
>
Do you mean non-NetBSD cross debugging connected to NetBSD gdbserver?
In any other case there is no concern and APIs are stable. If there will
be ABI changes, we will version sysctl() for new vs old calls, keeping
compat and old prebuilt things will continue to work.
> Kamil> I prefer to keep similarity with FreeBSD. If we want to change it,
> Kamil> FreeBSD shall be changed too.
>
> ...
> Kamil> I don't have chance to work or test on FreeBSD myself so I defer
> Kamil> refactoring it into future.
>
> It sounds like maybe FreeBSD isn't as maintained? Unless the two need
> to share a lot of code, it seems like it would be better to do things as
> well as possible in the maintained code; and let the other code alone.
>
If that can make the code merged, I will apply some changes on the cost
of diverging from the FreeBSD model.
> Tom
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-03-20 19:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 17:34 Kamil Rytarowski
2020-03-19 13:07 ` Kamil Rytarowski
2020-03-20 15:36 ` Tom Tromey
2020-03-20 16:58 ` Kamil Rytarowski
2020-03-20 18:50 ` Tom Tromey
2020-03-20 19:13 ` Kamil Rytarowski [this message]
2020-03-25 16:36 ` John Baldwin
2020-03-26 23:24 ` Kamil Rytarowski
2020-03-20 16:58 ` [PATCH v2] " Kamil Rytarowski
2020-04-02 20:09 ` Kamil Rytarowski
2020-04-03 1:12 ` Kamil Rytarowski
2020-04-06 9:37 ` [PATCH v3] " Kamil Rytarowski
2020-04-10 10:20 ` Kamil Rytarowski
2020-04-11 21:05 ` Simon Marchi
2020-04-11 21:28 ` Kamil Rytarowski
2020-04-11 21:53 ` Simon Marchi
2020-04-11 23:45 ` [PATCH v4] " Kamil Rytarowski
2020-04-11 23:49 ` Simon Marchi
2020-04-12 0:09 ` Kamil Rytarowski
2020-04-12 0:09 ` [PATCH v5] " Kamil Rytarowski
2020-04-12 0:56 ` Simon Marchi
2020-04-12 10:17 ` Kamil Rytarowski
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=9570eb83-e805-47e9-c334-3938beadfdb9@gmx.com \
--to=n54@gmx.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/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