qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] SH: Improve the interrupt controller


From: takasi-y
Subject: Re: [Qemu-devel] SH: Improve the interrupt controller
Date: Fri, 20 Mar 2009 02:17:38 +0900 (JST)

Hi, Vladimir,
Sorry for making you be confused,
# I worried when I had been assigned to qemu related job, though....

All development works I have done on qemu are for my hobby.
This mail address, which is used to sign-off for qemu, is for my personal use.

> Hmm, maybe I am confused but I had an impression that you do have access
> to the sh4a qemu -- both binary and source. 
My HDD won't have data that is not publicly available to make license
contamination avoidance easy. Anyway, I can't take any data away from office
to home, because it is prohibited by a company rule.

> Indeed, mailing patches and revisions back and forth is cumbersome. If the
> above set of patches works for you for r2d, then maybe the best approach
> is to get them checked in -- and then I'll have a baseline to revise my
> patch series against?
Perhaps, that will make things easier.

> I assume that core qemu maintainers are not watching this thread closely.
> Do you think you can post the above patches -- either combined, or separately,
> for review?
Developers' test reports are important as well as Maintainer's check.
So, each post should be enough to be build, run, and test the new function.

Being asked if I post it, I think I will rather choose not committing it.
Because
1. No problem has been reported with current code.
This makes "test the new function" above difficult.
2. The based code (current one) itself seems to be problematic.
At least I don't think controlling enable/disable by counter works well,
 especially when there are more than one masking source like INTC2 and INT2.
# So, IPR might be OK.

But, anyway, I don't mind it be checked in, unless it has regressions.
I can fix the problem I mentioned above even after it be checked in.
Or, perhaps will do nothing, because I prefer to spare time, if any,
 to verify and fix CPU core part.

Regards,
/yoshii




reply via email to

[Prev in Thread] Current Thread [Next in Thread]