Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

On 31.10.2011, at 18:35, Peter Maydell wrote:

> On 1 November 2011 00:08, Alexander Graf <address@hidden> wrote:
>> On 31.10.2011, at 06:12, Peter Maydell <address@hidden> wrote:
>>> On 29 October 2011 14:52, Alexander Graf <address@hidden> wrote:
>>>> We should also show people unmaintained areas. The conclusion was a wiki
>>>> page with subsystems and status so people know what to expect. Maybe we
>>>> could generate this from the MAINTAINERS file?
>>> 
>>> Sounds like a good idea, although I think we might need to expand
>>> MAINTAINERS a bit -- I get the impression that there are a lot of
>>> "little bits" that fall into the gaps between the top-level areas
>>> marked out in MAINTAINERS.
>> 
>> True. We do however have file path matches, so we could easily find 
>> unmaintained files.
> 
> We'd need to expand MAINTAINERS to be a lot more comprehensive and
> detailed than it is now (not necessarily a bad plan). It also doesn't
> deal with the "this area is maintained but the maintainer seems to
> have been busy for the last three months" issue.
> 
> I guess we could try it and see how it worked.
> 
>> See above. I think we could script this :)
> 
> I think you also want to have some sort of scripting of whether
> and what you were still leaving behind -- ie try to identify the
> patches which your script thought were maintained but which
> still didn't get any response.
> 
> (A mildly enhanced version of patchwork might do for that.)

Phew, eager goals :). I like the idea though!

> 
>>> If we get the qdev rework done then I think we're probably in
>>> a better position to have a plugin framework for devices. (There
>>> are some issues about API and ABI stability guarantees, of course.)
>> 
>> I'm not sure why we should. We could just follow the Linux kernel
>> model and merely expose what's there. New version means new API.
> 
> The "issue" is whether you try to provide any stability guarantee :-)
> "We don't" is one answer, but of course it does reduce the utility.

Sure, but reduced utility is a good starting point. It's certainly better than 
no utility :).

> 
>> Remember, I don't want this for commercial fire-and-forget device
>> models. I want it for stuff that's either too unclean or too
>> useless for upstream :).
> 
> I'm not sure that it helps very much for this use case -- if you
> have to update and rebuild for any new qemu then you might as well
> have it built in (a private copy of) the qemu source tree, because
> it'll just be some new files and a patch to the Makefile.

The main improvement is that you could enhance distro versions of QEMU. And 
inside a stable version we would also stay ABI compatible usually.


Alex