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:
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?