From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZPoK-0001XE-6q for qemu-devel@nongnu.org; Sat, 10 Dec 2011 11:30:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZPoI-0008Gr-P7 for qemu-devel@nongnu.org; Sat, 10 Dec 2011 11:30:04 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:51010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZPoI-0008GS-Ak for qemu-devel@nongnu.org; Sat, 10 Dec 2011 11:30:02 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id EEA7A1BB32021 for ; Sat, 10 Dec 2011 17:30:00 +0100 (CET) Message-ID: <4EE38905.5090401@web.de> Date: Sat, 10 Dec 2011 17:29:57 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <42a283294478be02e4f1dc5b0a78421030b51bbe.1323520118.git.jan.kiszka@web.de> <4EE38017.5010001@web.de> <4EE382C5.2000200@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF8C0E657420B7997B0880EB3" Subject: Re: [Qemu-devel] [PATCH 2/2] i8254: Rework & fix interaction with HPET in legacy mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Liguori , Marcelo Tosatti , qemu-devel , kvm , Avi Kivity This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF8C0E657420B7997B0880EB3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-12-10 17:26, Blue Swirl wrote: > On Sat, Dec 10, 2011 at 16:03, Jan Kiszka wrote: >> On 2011-12-10 16:54, Blue Swirl wrote: >>> On Sat, Dec 10, 2011 at 15:51, Jan Kiszka wrote: >>>> On 2011-12-10 16:49, Blue Swirl wrote: >>>>>> >>>>>> +ISADevice *pit_init(int base, qemu_irq irq) >>>>> >>>>> Please retain this function in pc.h, or even better, introduce i825= 4.h. >>>> >>>> No concerns about i8254.h, but this function does not qualify for st= atic >>>> inline. >>> >>> The function is static inline in a header file not for performance >>> reasons, but to keep the instantiation separate from device internals= =2E >> >> Not performance, footprint and header dependencies. You need to pull i= n >> all the stuff the inline function needs for everyone including the >> header that contains this function. That's messy. >=20 > There's only ISA and qdev stuff, that's not messy since both are > needed in any case. >=20 >> Even if the instantiation helper should not poke into the device model= >> internals (and I don't want this to change as well), it belongs to the= >> module that implements the device. We do the same with other fabric >> functions. >=20 > In this case, the callers have the same needs and there are several of > them. In general this need not be true at all, if for example some > part of instantiation would have to be skipped, the functions may need > to be manually inlined to the board level anyway. The instantiation > definitely does not belong to the implementer but to the creator. > Ideally file implementing the device contains only static functions > and instantiation is either in a header file or at the board. This is > true for example for several Sparc32 devices. The helper is wrapping the property base API into a proper function call - nothing that is board-specific. Jan --------------enigF8C0E657420B7997B0880EB3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7jiQUACgkQitSsb3rl5xTX5wCfZK4n4xQHLuc8OZ1Caf+a1VS9 Lx4AoLNNkFWNJEMHAh0ZzSq8E0q6YZqh =sSVD -----END PGP SIGNATURE----- --------------enigF8C0E657420B7997B0880EB3--