All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices?
Date: Wed, 7 Jun 2006 19:36:09 +0100	[thread overview]
Message-ID: <20060607183609.GA8524@mail.shareable.org> (raw)
In-Reply-To: <200606071825.11037.paul@codesourcery.com>

Paul Brook wrote:
> > > Basing work on the gcc/binutils code doesn't help me either because I
> > > wrote most of that code in the first place :-)
> >
> > Since the idea is for someone else do it, that doesn't matter.
> >
> > I'm wondering why, if it were done, it would be a problem for you to
> > contribute in future in the areas which you contribute to now.
> 
> Because a large proportion of my contributions, and most of my
> interest is in this area.

Sorry, I guess my question wasn't clear.

I'm not asking why it would be a problem for you to stop contributing
to ARM support in Qemu.  That's not the meaning of my question above.
Of course it would be a problem for all of us if you had to stop.

I am asking why you think you'd have to stop contributing to the
pre-ARMv6 feature set, given that it's unrelated to the restrictions
that you're bound by.

If it's post-ARMv6 contributions that you're interested in, you can't
contribute them now or in future; so someone else contributing changes in
that area makes no difference to you.

Or does it?  That's my question; I don't see why post-ARMv6
functionality in Qemu would prevent you from contributing to the
pre-ARMv6 functionality (devices, CPU model etc.), which is the only
area you're publically able to contribute now anyway.

I realise they would overlap substantially in the code, but that
doesn't mean you have to contribute any changes or reveal any
information which depends on the ARMv6 or later documentation.

I don't see why it would make a difference to what you're able to do,
and that's why I'm asking why you think it would.

Thanks,
-- Jamie

  parent reply	other threads:[~2006-06-07 18:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-07  7:11 [Qemu-devel] I want to add the ARMv6 instructions, who can give some advices? wang lianwei
2006-06-07 13:35 ` Paul Brook
2006-06-07 14:38   ` John R.
2006-06-07 14:46     ` Paul Brook
2006-06-07 14:53       ` Jamie Lokier
2006-06-07 15:07         ` Paul Brook
2006-06-07 15:48           ` Jamie Lokier
2006-06-07 15:58             ` Paul Brook
2006-06-07 16:18               ` Jamie Lokier
2006-06-07 16:34                 ` Paul Brook
2006-06-07 17:21                   ` Jamie Lokier
2006-06-07 17:25                     ` Paul Brook
2006-06-07 17:42                       ` John R.
2006-06-07 18:36                       ` Jamie Lokier [this message]
2006-06-07 14:46   ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2006-06-07 14:58 Laurent DESNOGUES
2006-06-07 16:34 Laurent DESNOGUES

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=20060607183609.GA8524@mail.shareable.org \
    --to=jamie@shareable.org \
    --cc=paul@codesourcery.com \
    --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.