From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 2/2] i8254: Rework & fix interaction with HPET in legacy mode Date: Sat, 10 Dec 2011 17:29:57 +0100 Message-ID: <4EE38905.5090401@web.de> References: <42a283294478be02e4f1dc5b0a78421030b51bbe.1323520118.git.jan.kiszka@web.de> <4EE38017.5010001@web.de> <4EE382C5.2000200@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF8C0E657420B7997B0880EB3" Cc: Anthony Liguori , Marcelo Tosatti , qemu-devel , kvm , Avi Kivity To: Blue Swirl Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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--