On 19 September 2016 at 11:06, Martin Pieuchot <m...@openbsd.org> wrote:
> On 19/09/16(Mon) 13:47, David Gwynne wrote:
>> [...]
>> id rather not grow the timeout (or task for that matter) apis just
>> yet. theyre nice and straightforward to read and understand so far.
> So better introduce a new API, right?
>> for this specific problem can we do a specific fix for it? the diff
>> below is equiv to the timeout_set_proc change, but implements it
>> by using explicit tasks that are called by the timeouts from a
>> common trampoline in the network stack.
> Is it really a specific problem?  We already encounter this for the
> linkstate and the watchdog.
> I'm not convinced by this approach.  I don't understand why:
>   - adding a task in every data structure is worth it
>   - introducing a new if_nettmo_* make things simpler
> So there's something which isn't explain in this email.
> And I'll bet that in the upcoming years we're going to stop using soft
> interrupts.  Meaning that timeout handlers will always have a stack
> available.  If/when this happens, it will be easier to do:
>         s/timeout_set_proc/timeout_set/

FWIW, I agree with mpi on this.  As a temporary change his
approach is sound.

I would also like to know what prevents us from executing all
timeouts in a thread context now? serial drivers with softtty
line discipline entanglement?

Reply via email to