On Mon, Jun 14, 2010 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:>>> Make APICState completely private to apic.c by using DeviceState>> in external APIs.>> Could you explain why this is an improvement?
Outside of apic.c, there is no need to access APICState fields so we
can remove that privilege. We can move the device instantiation to the
board level where it belongs.

Blue Swirl <blauwirbel@gmail.com> writes:
> On Mon, Jun 14, 2010 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:>> Blue Swirl <blauwirbel@gmail.com> writes:>>>>> Make APICState completely private to apic.c by using DeviceState>>> in external APIs.>>>> Could you explain why this is an improvement?>> Outside of apic.c, there is no need to access APICState fields so we> can remove that privilege. We can move the device instantiation to the> board level where it belongs.
Moving the definition of struct APICState into apic.c is a clear win.
But what does widening argument types from APICState to DeviceState
accomplish? The compiler won't be able to catch certain stupid type
errors anymore; what do we gain for that loss?

On Tue, Jun 15, 2010 at 8:17 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:>>> On Mon, Jun 14, 2010 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:>>> Blue Swirl <blauwirbel@gmail.com> writes:>>>>>>> Make APICState completely private to apic.c by using DeviceState>>>> in external APIs.>>>>>> Could you explain why this is an improvement?>>>> Outside of apic.c, there is no need to access APICState fields so we>> can remove that privilege. We can move the device instantiation to the>> board level where it belongs.>> Moving the definition of struct APICState into apic.c is a clear win.> But what does widening argument types from APICState to DeviceState> accomplish? The compiler won't be able to catch certain stupid type> errors anymore; what do we gain for that loss?
More beautiful architecture. This is how for example Sparc devices
work: there are almost no global functions, all but a few are static.

Blue Swirl <blauwirbel@gmail.com> writes:
> On Tue, Jun 15, 2010 at 8:17 AM, Markus Armbruster <armbru@redhat.com> wrote:>> Blue Swirl <blauwirbel@gmail.com> writes:>>>>> On Mon, Jun 14, 2010 at 9:36 AM, Markus Armbruster <armbru@redhat.com> wrote:>>>> Blue Swirl <blauwirbel@gmail.com> writes:>>>>>>>>> Make APICState completely private to apic.c by using DeviceState>>>>> in external APIs.>>>>>>>> Could you explain why this is an improvement?>>>>>> Outside of apic.c, there is no need to access APICState fields so we>>> can remove that privilege. We can move the device instantiation to the>>> board level where it belongs.>>>> Moving the definition of struct APICState into apic.c is a clear win.>> But what does widening argument types from APICState to DeviceState>> accomplish? The compiler won't be able to catch certain stupid type>> errors anymore; what do we gain for that loss?>> More beautiful architecture. This is how for example Sparc devices> work: there are almost no global functions, all but a few are static.
I'd take the static type checking any day. But it's your funeral, I
guess :)