From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60153 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OkDaC-0006oK-Dn for qemu-devel@nongnu.org; Sat, 14 Aug 2010 06:03:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OkDaA-0002Ej-US for qemu-devel@nongnu.org; Sat, 14 Aug 2010 06:03:20 -0400 Received: from mail-qw0-f45.google.com ([209.85.216.45]:46198) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OkDaA-0002Ef-RD for qemu-devel@nongnu.org; Sat, 14 Aug 2010 06:03:18 -0400 Received: by qwh5 with SMTP id 5so3843356qwh.4 for ; Sat, 14 Aug 2010 03:03:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Sat, 14 Aug 2010 10:02:58 +0000 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH 3/5] CODING_STYLE: add memory management rules Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: qemu-devel On Fri, Aug 13, 2010 at 9:56 PM, malc wrote: > On Fri, 13 Aug 2010, Blue Swirl wrote: > >> On Fri, Aug 13, 2010 at 9:01 PM, malc wrote: >> > On Fri, 13 Aug 2010, Blue Swirl wrote: >> > >> >> On Thu, Aug 12, 2010 at 5:50 PM, Blue Swirl wr= ote: >> >> > Add memory management rules, somewhat like libvirt HACKING. >> >> > >> >> > Signed-off-by: Blue Swirl >> >> > --- >> >> > =C2=A0CODING_STYLE | =C2=A0 =C2=A08 ++++++++ >> >> > =C2=A01 files changed, 8 insertions(+), 0 deletions(-) >> >> > >> >> > diff --git a/CODING_STYLE b/CODING_STYLE >> >> > index 3f10d72..085c86f 100644 >> >> > --- a/CODING_STYLE >> >> > +++ b/CODING_STYLE >> >> > @@ -148,3 +148,11 @@ up-front that this is a read-only pointer. =C2= =A0Perhaps more >> >> > =C2=A0importantly, if we're diligent about this, when you see a non= -const >> >> > =C2=A0pointer, you're guaranteed that it is used to modify the stor= age >> >> > =C2=A0it points to, or it is aliased to another pointer that is. >> >> > + >> >> > + >> >> > +7. Low level memory management >> >> > + >> >> > +Use of the malloc/free/realloc/calloc APIs is not allowed in the Q= EMU >> >> >> >> I forgot to add valloc/memalign/posix_memalign. >> >> >> >> > +codebase. Instead of these routines, use the replacement >> >> > +qemu_malloc/qemu_mallocz/qemu_realloc/qemu_free or >> >> > +qemu_vmalloc/qemu_memalign/qemu_vfree APIs. >> >> >> >> This should also mention that memory allocated by qemu_vmalloc or >> >> qemu_memalign should be freed with qemu_vfree. >> >> >> >> In general, whole of 7 is an existing rule and current codebase seems >> >> to follow it. >> >> >> >> This should be added as a strict rule (as opposed to guideline), sinc= e >> >> breaking this will cause problems on Win32 and user emulators. >> >> >> > >> > This is all perfectly reasonable, but begs one question, where do we s= top >> > codifying self-evident truths (or who is the ultimiate judge of what i= s >> > self-evident and what isn't), since taking the above to extreme we wil= l >> > end up adding stuff like: you must use close to dispose of open-ed >> > descriptors and such like. >> >> Interesting question. We could assume that the target audience knows >> well how to write portable C, conformal to various standards, so we >> only have to point out QEMU specific pitfalls. This approach would >> probably mean that there would be no need to mention, for example, the >> issues with identifiers starting with an underscore. >> >> Another approach is to consider the history. Which types of problems >> there have been frequently with the proposed patches? Then the >> underscore issue (just as an example) should definitely be raised, >> even though that is just one aspect of standards conformance. > > I.e. having a (N)FAQ(BNI) > > [not] [but nevertheless interesting] > >> I don't think either approach would solve your question though. >> > > In any case, what i wanted to convey, but failed, is that this > doesn't, in my opinion, belong to the CODING_STYLE. Well, this is not coding style but architectural guide. We could introduce a new document, rename CODING_STYLE or bury this to qemu-tech.texi. But I still (optimistically) think that some kind of READ_ME_BEFORE_CODING would help.