qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v1 2/4] m25p80: initial verion


From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC PATCH v1 2/4] m25p80: initial verion
Date: Sat, 21 Apr 2012 07:44:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0

Hi Peter,

Am 19.04.2012 04:33, schrieb Peter Crosthwaite:
> So is there any standard policy on setting maintainer-ships for device
> models? When I pushed the cadence IP device models (hw/cadence*) for
> xilinx zynq there was insistence that they be in the MAINTAINERS,

Yes, that was my request.

> however like m25p80, they are not necessarily zynq specific (indeed
> cadence could tmrw sell those IPs to another SoC vendor).
> 
> What qualifies a device model for being in maintainers under a cpu or
> machine model?

MAINTAINERS file is newer than most devices, so many are still missing.

I don't think that grouping devices with the TCG target is a good idea.

My reasoning for adding the Zynq devices to the machine was that it
seemed a natural fit - both were created by you and "belonged" to that
one machine.

When that is not the case, you can just create a new subsystem section
in MAINTAINERS, grouping in a way you see fit (Cadence IP, SPI,
MicroBlaze SoC, ...).

Especially when handling large patch series it is unhandy to manually
track maintainers/authors, so an automated way such as MAINTAINERS +
scripts/get_maintainer.pl is very handy. So if I need to apply some
CPUState change (or someone changes Memory API again) and authors can be
cc'ed for review by our script then I'm happy.

Another discussion this touches on is how the status of a MAINTAINERS
section is interpreted (my recent RFC series). Anthony has been
advocating that S: Maintained means to him you should queue patches for
that subsystem yourself rather than just sending/ack'ing patches on the
list.
How that interacts with TCG target maintenance is still somewhat of a
gray zone, i.e. ARM devices, despite not strictly documented in
MAINTAINERS, are in practice going through Peter as ARM maintainer for
coordination. (cc'ing both: Maybe we should find a mechanism to
distinguish between author and person to queue/pull after all? For
MicroBlaze that might be Peter C. vs. Edgar.)

Sorry for the late reply,

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

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