Cool. So we start with spk_serial_out() by replacing it with a wrapper wherever it is used in speakup_dummy? For first pass, here's what I am thinking (from your suggestion but using uglier function names which parallel existing ones): - add spk_serial_out2() wrapper which delegates to spk_serial_out() - add spk_synth_flush2() which is same as spk_synth_flush() but calls spk_serial_out2() instead - add spk_do_catch_up2() which is same as spk_do_catch_up() but calls spk_serial_out2() instead - in speakup_dummy replace calls to above functions with their *2() alternative Is that fine? Thanks, Okash On Fri, Nov 18, 2016 at 7:44 AM, Samuel Thibault < samuel.thibault@xxxxxxxxxxxx> wrote: > Okash Khawaja, on Fri 18 Nov 2016 07:07:33 +0000, wrote: > > "You will notice calls to spk_serial_out() in spk_do_catch_up() and > > spk_synth_flush(). Actually the very first step of your work could be > > to add a serial_out() method to drivers, which for now would be set > > to spk_serial_out() in all drivers, and make spk_do_catch_up() and > > spk_synth_flush() call the method instead of spk_serial_out(). Direct > > calls to spk_serial_out() within drivers could be converted into calling > > the method too, so that switching methods will be trivial." > > > > So I am wondering if it will be possible to restrict the changes to > > speakup_dummy while we test the new implementation using > tty->ops->write? That > > means a transitional phase where we have both, the existing serial io > for other > > drivers and new implementation for dummy driver. Or is that what you > meant? > > That's what I meant :) > > Samuel > _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
