All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH 5/5] include: Move hardware version declarations to new qemu/hw-version.h
Date: Wed, 9 Feb 2022 13:44:11 +0000	[thread overview]
Message-ID: <CAFEAcA_hXERA3Y0A8JkBxP6xotSHqJtdvTvV8c_gxGh1O_M+PQ@mail.gmail.com> (raw)
In-Reply-To: <8f330b10-7978-860c-35c5-282c8db23f70@amsat.org>

On Wed, 9 Feb 2022 at 10:10, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> On 9/2/22 10:25, Peter Maydell wrote:
> > On Wed, 9 Feb 2022 at 09:20, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > I'm not completely convinced that (a) we have a clear idea of
> > what of our APIs are legacy and what are not or (b) that we could
> > coherently move the 'legacy' ones into separate files.
> > If you want to propose something like that as an RFC, I don't
> > 100% object to it, but I don't want to do a very small subset
> > of that as part of what is really just a "get stuff out of osdep"
> > series.
>
> OK, thanks.

Thinking about the 'legacy API' issue a bit, rather than putting
them in particular include paths, maybe we could have a file
we list them in, and have checkpatch automatically check for new
uses of them. But I think our major problems with legacy APIs are
more "we never go through and complete transitions" rather than
"new code coming in uses old APIs we're trying to move away from"...

-- PMM


  reply	other threads:[~2022-02-09 14:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08 20:08 [PATCH 0/5] include: Trim some fat from osdep.h Peter Maydell
2022-02-08 20:08 ` [PATCH 1/5] include: Move qemu_madvise() and related #defines to new qemu/madvise.h Peter Maydell
2022-02-08 23:01   ` Richard Henderson
2022-02-08 20:08 ` [PATCH 2/5] include: Move qemu_mprotect_*() to new qemu/mprotect.h Peter Maydell
2022-02-08 23:02   ` Richard Henderson
2022-02-08 20:08 ` [PATCH 3/5] include: Move QEMU_MAP_* constants to mmap-alloc.h Peter Maydell
2022-02-08 23:03   ` Richard Henderson
2022-02-08 20:08 ` [PATCH 4/5] include: Move qemu_[id]cache_* declarations to new qemu/cacheinfo.h Peter Maydell
2022-02-08 23:04   ` Richard Henderson
2022-02-08 20:08 ` [PATCH 5/5] include: Move hardware version declarations to new qemu/hw-version.h Peter Maydell
2022-02-08 23:06   ` Richard Henderson
2022-02-09  9:20   ` Philippe Mathieu-Daudé via
2022-02-09  9:25     ` Peter Maydell
2022-02-09 10:10       ` Philippe Mathieu-Daudé via
2022-02-09 13:44         ` Peter Maydell [this message]
2022-02-09  9:21 ` [PATCH 0/5] include: Trim some fat from osdep.h Philippe Mathieu-Daudé via
2022-02-18 12:18 ` Peter Maydell

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=CAFEAcA_hXERA3Y0A8JkBxP6xotSHqJtdvTvV8c_gxGh1O_M+PQ@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.