I am modeling after the slip driver

I am modeling after the slip driver

[David]

The slip driver looks to me like a good place to start.
It does most of what I want as far as tty manipulation etc.
Obviously I will do considerable tweeking and replace the speakup/serial.c
with a slip style driver. Then on startup, the poll thread
will look for the tty to become ready and attach the tweeked driver to it.
Then it should run as normal. So serial/usb/whatever will make no difference.

Re: I am modeling after the slip driver

[Samuel Thibault]

David, on Tue 15 Nov 2016 14:54:28 -0500, wrote:
> The slip driver looks to me like a good place to start.

That's an instance of line discipline, yes.

> It does most of what I want as far as tty manipulation etc.

But it lacks what I mentioned in my other thread: actually opening the
serial port from the kernel itself. In slirp it's a userland process
which does this. That's the tricky part which will probably need some
changes to the rest of the kernel.

Samuel

Re: I am modeling after the slip driver

[John G Heim]

On 11/15/2016 01:59 PM, Samuel Thibault wrote:
> > But it lacks what I mentioned in my other thread: actually opening the
 >serial port from the kernel itself. In slirp it's a userland process
 > which does this. That's the tricky part which will probably need some
 > changes to the rest of the kernel.

Is anybody working on those changes? I haven't done this kind of work 
for 20 years but maybe I can still contribute.

Re: I am modeling after the slip driver

[Samuel Thibault]

John G Heim, on Tue 15 Nov 2016 14:38:34 -0600, wrote:
> On 11/15/2016 01:59 PM, Samuel Thibault wrote:
> >> But it lacks what I mentioned in my other thread: actually opening the
> >serial port from the kernel itself. In slirp it's a userland process
> > which does this. That's the tricky part which will probably need some
> > changes to the rest of the kernel.
> 
> Is anybody working on those changes?

The thread I had started was meant to provide info for a student to do
the work, but I haven't actually seen him make progress.

Samuel

Contributing to speakup

[Okash Khawaja]

Hi Samuel and David,

As I've mention in 'Status of kernel' thread, I would like to contribute to this project. I have done some kernel work in personal capacity, like Eudyptula challenge and Free Electrons embedded linux drivers course. I have also been studying speakup code and - after Samuel's replies to the other thread - line discipline and wider TTY subsystem.

Looks like there are some ideas on what to do. Is there any piece of work that I can take up? This is an interesting project and I hope to learn from it, therefore happy to commit time and effort. Please advise. 

Thanks,
Okash

Re: Contributing to speakup

[Samuel Thibault]

Hello,

Okash Khawaja, on Wed 16 Nov 2016 05:36:19 +0000, wrote:
> Looks like there are some ideas on what to do. Is there any piece of work that I can take up?

AFAIK, there has been no real code written.

I've however digged up my mails with Shraddha a bit, to find this:

“
Testing
with all actual synthesis hardware will be needed at some point, yes,
but most of the work can be done with the dummy driver.  Then we can ask
the speakup community to make tests with actual hardware.  I don't think
you need actual hardware (I have myself actually worked on speakup for a
long time without any particular hardware).

The I/O operations are already very well factorized (some drivers do
some I/O by hand, but we can forget about them in a first step), into
the following functions used by the drivers:

- spk_serial_synth_probe
- spk_serial_out
- spk_synth_immediate

To make things go smoothly, I'd say we should add equivalents of those
functions that would use proper kernel APIs, testing them with the
dummy driver. Then, for each driver, we can have it tested with the
new equivalents (that would be a matter of switching the probe and
synth_immediate methods of the driver), and once verified by users with
the actual hardware, commit the switch to the equivalents.

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.

About spk_stop_serial_interrupt, it could be made to return immediately
if spk_serial_init was never called.

> And also I'll have to convert spk_serial_in() too right?

Ah, I missed that one while checking functions. Yes, just like
spk_serial_out.
”

Samuel

Re: Contributing to speakup

[Okash Khawaja]

Okay the initial refactoring seems straightforward. If no one has picked it
up, I can start working on it. However, I am not sure about what the new
implmentation of serial_out() et el will look like.

Also, I understand speakup being a line discipline and the challenges
involved in creating device file and assigning speakup ldisc to it. But
don't know how it ties with it this work. And how it facilitates comms with
USB, PCI etc. Perhaps we can come back to that later and start with the
refactor first.

Thanks

On Wed, Nov 16, 2016 at 8:42 AM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Hello,
>
> Okash Khawaja, on Wed 16 Nov 2016 05:36:19 +0000, wrote:
> > Looks like there are some ideas on what to do. Is there any piece of
> work that I can take up?
>
> AFAIK, there has been no real code written.
>
> I've however digged up my mails with Shraddha a bit, to find this:
>
> “
> Testing
> with all actual synthesis hardware will be needed at some point, yes,
> but most of the work can be done with the dummy driver.  Then we can ask
> the speakup community to make tests with actual hardware.  I don't think
> you need actual hardware (I have myself actually worked on speakup for a
> long time without any particular hardware).
>
> The I/O operations are already very well factorized (some drivers do
> some I/O by hand, but we can forget about them in a first step), into
> the following functions used by the drivers:
>
> - spk_serial_synth_probe
> - spk_serial_out
> - spk_synth_immediate
>
> To make things go smoothly, I'd say we should add equivalents of those
> functions that would use proper kernel APIs, testing them with the
> dummy driver. Then, for each driver, we can have it tested with the
> new equivalents (that would be a matter of switching the probe and
> synth_immediate methods of the driver), and once verified by users with
> the actual hardware, commit the switch to the equivalents.
>
> 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.
>
> About spk_stop_serial_interrupt, it could be made to return immediately
> if spk_serial_init was never called.
>
> > And also I'll have to convert spk_serial_in() too right?
>
> Ah, I missed that one while checking functions. Yes, just like
> spk_serial_out.
> ”
>
> Samuel
>

Re: Contributing to speakup

[Samuel Thibault]

Okash Khawaja, on Wed 16 Nov 2016 10:03:32 +0000, wrote:
> However, I am not sure about what the new
> implmentation of serial_out() et el will look like.

It will call tty->ops->write(), typically.

> Also, I understand speakup being a line discipline and the challenges involved
> in creating device file and assigning speakup ldisc to it. But don't know how
> it ties with it this work.

That's what will produce the 'tty' pointer.

> And how it facilitates comms with USB, PCI etc.

It will bring them for free: opening ttyS0 will open whatever serial
port appears as ttyS0 in Linux, be it ISA or PCI. Opening ttyUSB0 will
open whatever USB serial port which appears as ttyUSB0.

> Perhaps we can come back to that later and start with the refactor first.

Yes, the refactor can be done first. The tty initialization will however
come immediately after, to replace the outb() of serial_out() with
tty->ops->write().

Samuel

Re: Contributing to speakup

[Okash Khawaja]

I see, now it's falling into place. Still more questions to come but I can
see the way forward. Thanks

On Wed, Nov 16, 2016 at 6:28 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:

> Okash Khawaja, on Wed 16 Nov 2016 10:03:32 +0000, wrote:
> > However, I am not sure about what the new
> > implmentation of serial_out() et el will look like.
>
> It will call tty->ops->write(), typically.
>
> > Also, I understand speakup being a line discipline and the challenges
> involved
> > in creating device file and assigning speakup ldisc to it. But don't
> know how
> > it ties with it this work.
>
> That's what will produce the 'tty' pointer.
>
> > And how it facilitates comms with USB, PCI etc.
>
> It will bring them for free: opening ttyS0 will open whatever serial
> port appears as ttyS0 in Linux, be it ISA or PCI. Opening ttyUSB0 will
> open whatever USB serial port which appears as ttyUSB0.
>
> > Perhaps we can come back to that later and start with the refactor first.
>
> Yes, the refactor can be done first. The tty initialization will however
> come immediately after, to replace the outb() of serial_out() with
> tty->ops->write().
>
> Samuel
>