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

[Mark Gross]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/