All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
To: Taylor Simpson <tsimpson@quicinc.com>
Cc: Riku Voipio <riku.voipio@iki.fi>,
	Laurent Vivier <laurent@vivier.eu>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project and therefore do not conform to qemu coding standards
Date: Thu, 21 Nov 2019 21:44:59 +0100	[thread overview]
Message-ID: <CAL1e-=gMvf-gx0WJ+xH0e8J84_JOkaACGA93B2XehuCAgiEyeQ@mail.gmail.com> (raw)
In-Reply-To: <BYAPR02MB48868819DDB0818111D4E972DE4E0@BYAPR02MB4886.namprd02.prod.outlook.com>

On Thu, Nov 21, 2019 at 8:52 PM Taylor Simpson <tsimpson@quicinc.com> wrote:
>
> They are imported from the existing Hexagon simulator.  Please understand that this patch is the first in a series.  Later patches will contain more elaborate contents in that directory.  The reason I don't want to reformat them is to stay in sync with the other simulator in the future.  When the other team makes changes to the code (either to fix bugs or add features), it will be easier to identify the changes and bring them into qemu.
>
> Taylor
>

Taylor,

Please understand that this patch can't remain a single patch. It
can't remain even a set of 2 or 3 patches as others suggested. A patch
is a logically connected unit of code whose typical size is less than
200 lines. There are lots of such logical units in this single path
that you sent, and you should not have sent it in its present form,
even if you wanted just comments to it. You should have submitted a
series rather than a single patch. And you should have said this is v1
of my series that I will expand later on. Guidelines for submissions
are here:

https://wiki.qemu.org/Contribute/SubmitAPatch

As far as "imported" files, frankly, I dislike the fact that you are
willing to sacrifice our coding style guidelines in favor to your
convenience. But, more than this, I also find very problematic that
you practically create a dependency between QEMU and another
simulator. QEMU implementation should rely on specifications, and only
on specifications, and certainly should not depend on another
simulator. Currently, in QEMU, there are some cases of imported
disassemblers or similar relatively unimportant tools, but those
imports change very rarely, and are modified to comply to QEMU coding
style. I am not aware on dependency of QEMU on another simulator in
the form you want to do for Hexagon. My strong impression is that you
will create more problems than benefits with such dependency, both for
you and for QEMU in general.

Once a CPU or any other device is specified though documentation,
these specs don't change. Consequently, their emulation does not
change too, in functional sense. The fact that you anticipate changes
in these files imported from another simulator, leaves me with a
(possibly wrong) perception that neither Hexagon internal simulator
nor QEMU implementation you are trying to integrate are complete. If
that is not true, can you explain what exactly you expect to be
changing in imported files?

Yours,
Aleksandar


> -----Original Message-----
> From: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
> Sent: Thursday, November 21, 2019 1:20 PM
> To: Taylor Simpson <tsimpson@quicinc.com>
> Cc: Laurent Vivier <laurent@vivier.eu>; Riku Voipio <riku.voipio@iki.fi>; QEMU Developers <qemu-devel@nongnu.org>
> Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project and therefore do not conform to qemu coding standards
>
>
> >  create mode 100644 target/hexagon/imported/global_types.h
> >  create mode 100644 target/hexagon/imported/iss_ver_registers.h
> >  create mode 100644 target/hexagon/imported/max.h  create mode 100644
> > target/hexagon/imported/regs.h
>
> Taylor, if I understood you well, these files don't confirm to QEMU coding standard, because they are imported. But, from where? And what is the reason they need to be imported (and not created independently by you or somebody else, but within QEMU code style guidelines) ?
> Their content looks fairly simple to me.
>
> Thanks,
> Aleksandar


  reply	other threads:[~2019-11-21 20:48 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 23:58 [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project and therefore do not conform to qemu coding standards Taylor Simpson
2019-11-19  1:31 ` no-reply
2019-11-19  8:51   ` Exclude paths from checkpatch (was: Re: [PATCH] Add minimal Hexagon target) Philippe Mathieu-Daudé
2019-11-19 13:33     ` Richard Henderson
2019-11-19 15:37     ` Paolo Bonzini
2019-11-19 16:14     ` Stefan Hajnoczi
2019-11-19  8:39 ` [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project and therefore do not conform to qemu coding standards Laurent Vivier
2019-11-19  9:03   ` Laurent Vivier
2019-11-19 14:14 ` Eric Blake
2019-11-19 15:11   ` Philippe Mathieu-Daudé
2019-11-19 15:19 ` Philippe Mathieu-Daudé
2019-11-19 17:22   ` Taylor Simpson
2019-11-19 17:32     ` Peter Maydell
2019-11-19 18:13     ` Laurent Vivier
2019-11-20  4:48       ` Taylor Simpson
2019-11-20  8:33         ` Laurent Vivier
2019-11-20  9:02           ` Richard Henderson
2019-11-20 12:58             ` Taylor Simpson
2019-11-20 14:14               ` Laurent Vivier
2019-11-20 15:19                 ` Taylor Simpson
2019-11-20 16:40               ` Alex Bennée
2019-11-20 17:09       ` Philippe Mathieu-Daudé
2019-11-19 19:36     ` Richard Henderson
2019-11-20  2:26       ` Aleksandar Markovic
2019-11-20  7:49         ` Richard Henderson
2019-11-21  6:01           ` Aleksandar Markovic
2019-11-21  8:55             ` Richard Henderson
2019-11-20  8:41         ` Laurent Vivier
2019-11-20 17:34         ` Alex Bennée
2019-11-19 19:33 ` Richard Henderson
2019-11-20  5:15   ` Taylor Simpson
2019-11-20  8:06     ` Richard Henderson
2019-11-20 12:51       ` Taylor Simpson
2019-11-20 14:43         ` Richard Henderson
2019-11-20 15:17           ` Taylor Simpson
2019-11-21  9:00             ` Richard Henderson
2019-11-21 19:20 ` Aleksandar Markovic
2019-11-21 19:52   ` Taylor Simpson
2019-11-21 20:44     ` Aleksandar Markovic [this message]
2019-11-21 23:51       ` Taylor Simpson
2019-11-22  9:33         ` Aleksandar Markovic

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='CAL1e-=gMvf-gx0WJ+xH0e8J84_JOkaACGA93B2XehuCAgiEyeQ@mail.gmail.com' \
    --to=aleksandar.m.mail@gmail.com \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=riku.voipio@iki.fi \
    --cc=tsimpson@quicinc.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 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.