Serial: Initial refactor

Okash Khawaja okash.khawaja at gmail.com
Fri Nov 18 04:20:08 EST 2016


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 at ens-lyon.org> 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
>


More information about the Speakup mailing list