All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH 2/2] i8254: Rework & fix interaction with HPET in legacy mode
Date: Sat, 10 Dec 2011 17:29:57 +0100	[thread overview]
Message-ID: <4EE38905.5090401@web.de> (raw)
In-Reply-To: <CAAu8pHuXMhYQS+AXtBeF=q0SiQd7rjY1qx8Kh+3jXQ2bt8Bosw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

On 2011-12-10 17:26, Blue Swirl wrote:
> On Sat, Dec 10, 2011 at 16:03, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2011-12-10 16:54, Blue Swirl wrote:
>>> On Sat, Dec 10, 2011 at 15:51, Jan Kiszka <jan.kiszka@web.de> 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 i8254.h.
>>>>
>>>> No concerns about i8254.h, but this function does not qualify for static
>>>> inline.
>>>
>>> The function is static inline in a header file not for performance
>>> reasons, but to keep the instantiation separate from device internals.
>>
>> Not performance, footprint and header dependencies. You need to pull in
>> all the stuff the inline function needs for everyone including the
>> header that contains this function. That's messy.
> 
> There's only ISA and qdev stuff, that's not messy since both are
> needed in any case.
> 
>> 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.
> 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] i8254: Rework & fix interaction with HPET in legacy mode
Date: Sat, 10 Dec 2011 17:29:57 +0100	[thread overview]
Message-ID: <4EE38905.5090401@web.de> (raw)
In-Reply-To: <CAAu8pHuXMhYQS+AXtBeF=q0SiQd7rjY1qx8Kh+3jXQ2bt8Bosw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

On 2011-12-10 17:26, Blue Swirl wrote:
> On Sat, Dec 10, 2011 at 16:03, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2011-12-10 16:54, Blue Swirl wrote:
>>> On Sat, Dec 10, 2011 at 15:51, Jan Kiszka <jan.kiszka@web.de> 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 i8254.h.
>>>>
>>>> No concerns about i8254.h, but this function does not qualify for static
>>>> inline.
>>>
>>> The function is static inline in a header file not for performance
>>> reasons, but to keep the instantiation separate from device internals.
>>
>> Not performance, footprint and header dependencies. You need to pull in
>> all the stuff the inline function needs for everyone including the
>> header that contains this function. That's messy.
> 
> There's only ISA and qdev stuff, that's not messy since both are
> needed in any case.
> 
>> 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.
> 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2011-12-10 16:29 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-10 12:28 [PATCH 0/2] pit/hpet: Fix legacy mode switching Jan Kiszka
2011-12-10 12:28 ` [Qemu-devel] " Jan Kiszka
2011-12-10 12:28 ` [PATCH 1/2] hpet: Save/restore cached RTC IRQ level Jan Kiszka
2011-12-10 12:28   ` [Qemu-devel] " Jan Kiszka
2011-12-10 12:28 ` [PATCH 2/2] i8254: Rework & fix interaction with HPET in legacy mode Jan Kiszka
2011-12-10 12:28   ` [Qemu-devel] " Jan Kiszka
2011-12-10 15:49   ` Blue Swirl
2011-12-10 15:49     ` [Qemu-devel] " Blue Swirl
2011-12-10 15:51     ` Jan Kiszka
2011-12-10 15:51       ` [Qemu-devel] " Jan Kiszka
2011-12-10 15:54       ` Blue Swirl
2011-12-10 15:54         ` [Qemu-devel] " Blue Swirl
2011-12-10 16:03         ` Jan Kiszka
2011-12-10 16:03           ` [Qemu-devel] " Jan Kiszka
2011-12-10 16:26           ` Blue Swirl
2011-12-10 16:26             ` [Qemu-devel] " Blue Swirl
2011-12-10 16:29             ` Jan Kiszka [this message]
2011-12-10 16:29               ` Jan Kiszka
2011-12-10 16:49               ` Blue Swirl
2011-12-10 16:49                 ` [Qemu-devel] " Blue Swirl
2011-12-10 15:52 ` [PATCH 0/2] pit/hpet: Fix legacy mode switching Blue Swirl
2011-12-10 15:52   ` [Qemu-devel] " Blue Swirl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EE38905.5090401@web.de \
    --to=jan.kiszka@web.de \
    --cc=aliguori@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.