Re: New "timeout" api, to replace callout
In message <20071202075334.A11104@xorpc.icir.org>, Luigi Rizzo writes:
>> I disagree, that case, should be "with a period between N and M,
>> at your choice".[/color]
>yes surely this is better. But since your initial interface only
>had one parameter for this i tried to stick with that.[/color]
Right now, I'm looking at the API to replace the current API.
New functionality can be added, as we find out what it should be
and how it should work.
>DEVICE_POLLING is one example. You poll (and do resource allocation)
>to avoid livelock generated by too many interrupts, but don't know
>in advance what's the correct polling rate so rely on the system administrator
>to set HZ appropriately.[/color]
Ahh, but isn't that the wrong way ?
Shouldn't the driver (or central polling) code dynamically adjust
the pollrate instead ?
>> >It wouldn't make sense to do poll-based event handling at the same
>> >rate on a 133MHz soekris or on a 3 GHz multicore cpu.[/color]
>> Hz is the same for those two, so today we poll at the same rate.[/color]
>but you'd bump HZ to 2k or 4k up on a modern CPU, and lower to 500
>on a soekris.[/color]
Nothing prevents dummynet or devicepolling from having a sysctl
to adjust the rate.
>> I'm applying Jim Gettys 3. rule from the X11 project:
>> 3.The only thing worse than generalizing from one example
>> is generalizing from no examples at all.[/color]
>for what matters that would apply to the ns/us/ms/s resolutions that
>you proposed. They may be intuitive units but it doesn't mean that they are
>the most appropriate ones.[/color]
There's trivially room for another 28 'unit' flags, but I don't want
to define them, until rule three above is satisfied.
with respect to ns/us/ms/s, there are plenty of places in device drivers
where datasheets specify timeout durations on those terms, and network
protocols add another dozen such well defined timeouts.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[email]phk@FreeBSD.ORG[/email] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
[email]firstname.lastname@example.org[/email] mailing list
To unsubscribe, send any mail to "email@example.com"