Hi, Chris Wedgwood wrote:
> On Sat, Jun 26, 2004 at 11:54:38PM +0100, Alan Cox wrote:
>
>> For most uses jiffies should die. If drivers could not access jiffies
>> except by a (possibly trivial) helper then it would be a huge step
>> closer to being able to run embedded linux without a continually running
>> timer.
>
> I'm all for that, except last I counted there are about 5000 users of
> jiffies. What do you suggest as a replacement API?
<heretic>
#define jiffies __get_jiffies()
</heretic>
--
Matthias Urlichs
On Sun, Jun 27, 2004 at 02:00:03PM +0200, Matthias Urlichs wrote:
> <heretic>
>
> #define jiffies __get_jiffies()
>
> </heretic>
Well, I have that but it's only part of the story.
The real issue seems to be that a suitable clean API for drivers to
use rather than intenral knowledge of jiffies is lacking.
As Alan pointed out a suitable API could also make it easier to work
towards a clock-less system for embedded targets.
--cw
Hi,
Chris Wedgwood:
> On Sun, Jun 27, 2004 at 02:00:03PM +0200, Matthias Urlichs wrote:
>
> > <heretic>
> > #define jiffies __get_jiffies()
> > </heretic>
>
> Well, I have that but it's only part of the story.
>
True.
> As Alan pointed out a suitable API could also make it easier to work
> towards a clock-less system for embedded targets.
>
Well, drivers do need some way of timing things, else they wouldn't read
jiffies in the first place. So, at minimum, an embedded system would
need a way to trigger a timeout at some specified time in the future.
A simple __get_jiffies() implementation could just set up a 1/HZ-second
timer (and busy-wait for it, and increase its internal jiffies counter)
every tenth call or so. That would probably slow down the whole system
somewhat, but I'd assume it'd mostly work.
--
Matthias Urlichs
On Mon, Jun 28, 2004 at 03:24:07AM +0200, Matthias Urlichs wrote:
> A simple __get_jiffies() implementation could just set up a
> 1/HZ-second timer (and busy-wait for it, and increase its internal
> jiffies counter) every tenth call or so. That would probably slow
> down the whole system somewhat, but I'd assume it'd mostly work.
I think the approach is to look at _why_ people need jiffies and
change this to a cleaner less low-level API using accessor
functions/macros.
--cw
Hi,
Chris Wedgwood:
> I think the approach is to look at _why_ people need jiffies and
> change this to a cleaner less low-level API using accessor
> functions/macros.
>
That would be the correct long-term approach, true.
However, going over 5000 jiffies usages and re-doing all of them doesn't
happen overnight, and I do suspect that some people want their embedded
clockless systems to run Linux 2.4 or 2.6, rather than 2.8...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [email protected]
On Mon, Jun 28, 2004 at 08:55:08AM +0200, Matthias Urlichs wrote:
> However, going over 5000 jiffies usages and re-doing all of them
> doesn't happen overnight, and I do suspect that some people want
> their embedded clockless systems to run Linux 2.4 or 2.6, rather
> than 2.8...
Such (embedded) hardware uses a very small percentage of the drivers
we have in the tree, changing them as required seems quite sane and
manageable in 2.7.x time-frame.
I also do see why clock-less has to be embedded only, I suspect maybe
the s390 could make use of this too? (Think of lots of mostly-idle
Linux instances under VM).
And, it's a 'new feature' so if people need to upgrade, then Life is
tough. How sad.
--cw
Hi,
Chris Wedgwood:
> On Mon, Jun 28, 2004 at 08:55:08AM +0200, Matthias Urlichs wrote:
> > However, going over 5000 jiffies usages and re-doing all of them
> > doesn't happen overnight, and I do suspect that some people want
> > their embedded clockless systems to run Linux 2.4 or 2.6, rather
> > than 2.8...
>
> Such (embedded) hardware uses a very small percentage of the drivers
> we have in the tree, changing them as required seems quite sane and
> manageable in 2.7.x time-frame.
>
... especially since the 2.7 time-frame hasn't even started yet.
> I also do see why clock-less has to be embedded only, I suspect maybe
> the s390 could make use of this too? (Think of lots of mostly-idle
> Linux instances under VM).
>
True. The same argument holds for "real" Linux systems, which could
easily sit in HLT for hours instead of twiddling their thumbs $KERNEL_HZ
times per second.
> And, it's a 'new feature' so if people need to upgrade, then Life is
> tough. How sad.
I'm not contradicting you here. In fact, I seem to have taken the
<heretic> somewhat further than originally intended. :-/
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [email protected]