Re: [ANNOUNCE] high-res-timers patches for 2.6.6

From: Mark Gross (mgross_at_linux.jf.intel.com)
Date: 06/17/04

  • Next message: Roman Zippel: "Re: hfs warning in 2.4.27-pre6" 
    To: ganzinger@mvista.com, George Anzinger <george@mvista.com>, Mark Gross <mgross@linux.jf.intel.com>
Date:	Thu, 17 Jun 2004 12:35:39 -0700

    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Roman Zippel: "Re: hfs warning in 2.4.27-pre6"

    Relevant Pages

    • Re: Accessing monotonic clock from modules
      ... >> We would like to get the posix monotonic clock from a loadable module. ... > (exporting things without the module going into kernel.org shouldn't be ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Any reason why install_page and zap_page_range are not exported?
      ... "Petr Vandrovec" wrote: ... > there is no way how to put some page into pagetables. ... zap_page_rangesounds like an odd thing to be exporting. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.6-rc1-mm1
      ... On Wed, 21 Apr 2004, Christoph Hellwig wrote: ... >> While I understand the motive for not exporting the lock the question of ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] Menuconfig search changes - pt. 3
      ... > fixes) is separating the search into a function, ... allocated array. ... I agree - exporting the search function to a seperate location in ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.4-rc2-mm1: IPMI_SMB doesnt compile
      ... >And dumb, and incorrect:( ... I certainly agree that exporting ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    Loading