All of lore.kernel.org
 help / color / mirror / Atom feed
From: BALATON Zoltan via <qemu-devel@nongnu.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Huacai Chen <chenhuacai@kernel.org>, John Snow <jsnow@redhat.com>,
	qemu-devel@nongnu.org, Guenter Roeck <linux@roeck-us.net>,
	f4bug@amsat.org
Subject: Re: [PATCH v2 2/2] via-ide: Fix fuloong2e support
Date: Tue, 29 Dec 2020 15:10:02 +0100 (CET)	[thread overview]
Message-ID: <8459846f-6810-12fe-269f-7aa3e4b69df4@eik.bme.hu> (raw)
In-Reply-To: <454e0750-7141-6daf-7917-259b2cb77cfa@ilande.co.uk>

On Tue, 29 Dec 2020, Mark Cave-Ayland wrote:
> On 29/12/2020 12:01, BALATON Zoltan via wrote:
>>> Fortunately with PCI_CLASS_PROG at 0x8a Linux will keep the VIA IDE in 
>>> compatible mode and not attempt to switch to native mode: therefore if you 
>>> keep this as-is and add the legacy IDE ioports back, that just leaves the 
>>> problem with BAR4 (BMDMA). In effect your patch isn't setting compatible 
>>> mode anymore, it is just disabling BMDMA.
>> 
>> It's actually Guenter's patch so you're now bashing him not me...
>
> This is a deliberately misleading comment, and not a good introduction for

It's not deliberately misleading just stating a fact that you deliberately 
misinterpret. Guenter has contributed before (he also fixed up my sam460ex 
emulation) and his contributions are certainly appreciated. I'm sorry that 
he got unintentinally invoved in this disagreement between us two but I 
think he can ignore all this without a problem. I did not mean to drag him 
into it, just pointed out what you're doing and I think he got that.

> someone external becoming involved with the project. Guenter's patch was a 
> PoC demonstrating how to fix the fuloong2e machine, which is really 
> appreciated since it clearly locates the problems to allow a fix to be 
> applied upstream.
>
>> (But I also think your time could be better spent than getting rid of this 
>> hack when there are much more hacks or missing functionalities to get rid 
>> of in the part you maintain.)
>
> And comments like this are not appropriate for a technical mailing list 
> either. I've done my best to review your patch in good faith (including

Don't misunderstand this again, I did not mean to say that you made 
mistakes (although everyone does so that's not a problem) but what I meant 
is that there are a lot of things even in your areas that could be 
improved and that's time much better spent than discussing this patch 
endlessly on phylosophical basis when it's unlikely to get better.

> reading related specifications and testing your pegasos2 model) and explain 
> why it isn't reporting the correct information to the guest.

Yes I agree this should be brought to off list and clear up this between 
us I just don't have time for it now but I'll write to you later. As for 
your comments, we've been through all this in March and I get the 
impression that whatever I submit is criticised by you all the time so I 
really wonder if it's against me personally or you just getting old and 
grumpy :-) Don't take this as personal, no insult is meant just want to 
know if I did something that made you change your mind about my 
contributions or you do this to everything submitted to QEMU, because 
that's slowly becomes a burden discouriging me to contribute anything. I 
already gave up contributing to OpenBIOS but won't give up with QEMU, but 
I'm a bit tired having to fight for every little change to get past you 
(even in areas you're not maintaining like this one).

You can answer in private to this, I think others will be greateful to be 
left out of the discussion.

> Phil - I hope you find that found my review comments useful and that they 
> explain why the patchset is wrong by always claiming legacy IDE ioports exist 
> but not providing them unless the new option is set (and indeed indicating 
> some of the shortcomings of QEMU related to PCI BARs in this area that can be 
> improved in future). As I feel comments in this thread have become directed 
> at me personally, I am going to take a step back from this.

I'm sorry if you feel my replies got personal but I also feel your 
comments getting at me and you seemed to critique something that was 
addmittedly not perfect but working and demanded perfection where it's not 
feasible (without way more work that you can expect from unpayed 
contributors) and calling my patches wrong for that reason. I don't mind 
if you add comments, warnnings or change the commit message to say "this 
patch is all wrong but fixes Linux on fuloong2e and makes guests work with 
pegasos2 within the constraints of QEMU" as long as it gets in until a 
better fix may be available sometimes in the future. But:

- this patch is not mine now
- I did change what you asked in the first review but then you came back with this
- all this has been discussed to death and everyone but you seemed to accept it

I'll try to refrain from answering any more about this and let's continue 
off list if you want. I'd really want to avoid further confrontation but I 
happen to contribute to parts you also have an interest in so it's hard to 
avid each other so it would be better to get to some acceptable terms that 
allow me to contribute without upsetting you too much.

Regards,
BALATON Zoltan


  reply	other threads:[~2020-12-29 14:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-27 22:13 [PATCH v2 0/2] Fix via-ide for fuloong2e BALATON Zoltan via
2020-12-27 22:13 ` [PATCH v2 2/2] via-ide: Fix fuloong2e support BALATON Zoltan via
2020-12-28 12:27   ` Jiaxun Yang
2020-12-28 19:43   ` Mark Cave-Ayland
2020-12-28 20:50     ` BALATON Zoltan via
2020-12-29 10:56       ` Philippe Mathieu-Daudé
2020-12-29 11:35         ` BALATON Zoltan via
2020-12-29 11:24       ` Mark Cave-Ayland
2020-12-29 12:01         ` BALATON Zoltan via
2020-12-29 12:49           ` Mark Cave-Ayland
2020-12-29 14:10             ` BALATON Zoltan via [this message]
2020-12-29 11:43       ` Mark Cave-Ayland
2020-12-29 12:07         ` BALATON Zoltan via
2020-12-27 22:13 ` [PATCH v2 1/2] ide: Make room for flags in PCIIDEState and add one for legacy mode BALATON Zoltan via
2020-12-28 19:30   ` Mark Cave-Ayland
2020-12-28 20:23     ` BALATON Zoltan via
2020-12-29 10:52     ` Philippe Mathieu-Daudé

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=8459846f-6810-12fe-269f-7aa3e4b69df4@eik.bme.hu \
    --to=qemu-devel@nongnu.org \
    --cc=balaton@eik.bme.hu \
    --cc=chenhuacai@kernel.org \
    --cc=f4bug@amsat.org \
    --cc=jsnow@redhat.com \
    --cc=linux@roeck-us.net \
    --cc=mark.cave-ayland@ilande.co.uk \
    /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.