From: Mark Gross <mgross@linux.jf.intel.com>
To: ganzinger@mvista.com, George Anzinger <george@mvista.com>,
Mark Gross <mgross@linux.jf.intel.com>
Cc: ganzinger@mvista.com, Arjan van de Ven <arjanv@redhat.com>,
Geoff Levand <geoffrey.levand@am.sony.com>,
high-res-timers-discourse@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] high-res-timers patches for 2.6.6
Date: Thu, 17 Jun 2004 12:35:39 -0700 [thread overview]
Message-ID: <200406171235.39799.mgross@linux.intel.com> (raw)
In-Reply-To: <40D0CAB5.6010000@mvista.com>
On Wednesday 16 June 2004 15:33, George Anzinger wrote:
> > Details... Thats a hard thing to come by when in a high level design
> > discussion.
> >
> > Its too bad the conversion_bits export got shot down. Perhaps it was
> > because you where exporting a data structure that made implicit
> > assumptions rather than a more object based interface, with function
> > pointers to conversion functions, and private data?
>
> The functions, of course, were also exported. But this is exported from
> the arch side of things and not the base. They need to provide the
> conversion functions, the bits just being somthing that is needed if they
> export inline code, where as, if they export the functions, they don't need
> the bits (i.e. they are private). I rather like to export inline code as
> it is about twice as fast (I would guess).
I think if in-lines are exported through more than one level of indirection
through include files then the code is hard to grok.
>
> > Regardless of doing an object based implementation of your design or not,
> > if we could loose the #ifdefs and implicit ifdefs (i.e. IF_HIGH_RES) from
> > the code (especially posix-timers.c) that would be really a good thing.
> >
> > I do still like the object based design concept ;)
>
> I am afraid I am too old :( I rather think I understand object based code
> while not finding it very "warm". I have never written anything large
> that way and find myself objecting in the name of performance, but then, as
> I said, I may be too old.
Object based code good for some things, and not for others. I think it could
be a good match this code, but I bet it can be done well other ways as too.
I think without exporting abstractions (even just prototypes) that are common
across architectures, timebases and interrupt source you will get into #ifdef
hell with this code.
--mgross
next prev parent reply other threads:[~2004-06-17 19:36 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-10 1:49 [ANNOUNCE] high-res-timers patches for 2.6.6 Geoff Levand
2004-06-10 2:40 ` William Lee Irwin III
2004-06-10 8:40 ` eric.piel
2004-06-10 9:08 ` William Lee Irwin III
2004-06-10 10:04 ` Arjan van de Ven
2004-06-11 0:02 ` George Anzinger
2004-06-11 6:22 ` Arjan van de Ven
2004-06-11 22:11 ` George Anzinger
2004-06-11 22:33 ` George Anzinger
2004-06-12 14:01 ` Arjan van de Ven
2004-06-14 15:28 ` Mark Gross
2004-06-14 20:48 ` George Anzinger
2004-06-14 22:20 ` Mark Gross
2004-06-15 0:21 ` George Anzinger
2004-06-15 16:04 ` Mark Gross
2004-06-16 22:33 ` George Anzinger
2004-06-17 19:35 ` Mark Gross [this message]
2004-06-21 22:50 ` Geoff Levand
2004-06-21 23:17 ` George Anzinger
2004-06-22 17:37 ` Geoff Levand
2004-06-22 18:05 ` Stephen Hemminger
2004-06-22 23:07 ` George Anzinger
2004-06-23 0:15 ` Geoff Levand
[not found] ` <40D8CF88.4050608@am.sony.com>
2004-09-03 1:35 ` [ANNOUNCE] high-res-timers patch Geoff Levand
2004-11-04 20:41 ` Geoff Levand
2004-06-23 16:23 ` [ANNOUNCE] high-res-timers patches for 2.6.6 Mark Gross
2004-06-21 23:29 ` Mark Gross
2004-06-12 0:24 ` Karim Yaghmour
2004-06-14 20:57 ` George Anzinger
2004-06-21 3:14 ` Karim Yaghmour
2004-06-21 21:33 ` George Anzinger
2004-06-22 4:50 ` Karim Yaghmour
2004-06-21 23:13 ` Stephen Hemminger
2004-06-21 23:22 ` Randy.Dunlap
-- strict thread matches above, loose matches on Subject: below --
2004-06-10 12:46 Dave Hylands
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=200406171235.39799.mgross@linux.intel.com \
--to=mgross@linux.jf.intel.com \
--cc=arjanv@redhat.com \
--cc=ganzinger@mvista.com \
--cc=geoffrey.levand@am.sony.com \
--cc=george@mvista.com \
--cc=high-res-timers-discourse@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.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.