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.

[Samuel Thibault]

Post by David
The slip driver looks to me like a good place to start.

That's an instance of line discipline, yes.

Post by David
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

[John G Heim]

Post by Samuel Thibault

Post by Samuel Thibault
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.

[Samuel Thibault]

Post by John G Heim

Post by Samuel Thibault

Post by Samuel Thibault
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

[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

[Samuel Thibault]

Hello,

Post by Okash Khawaja
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.

Post by Okash Khawaja
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

[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 <

Post by Samuel Thibault
Hello,

Post by Okash Khawaja
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.
“
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
- 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.

Post by Okash Khawaja
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

[Samuel Thibault]

Post by Okash Khawaja
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.

Post by Okash Khawaja
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.

Post by Okash Khawaja
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.

Post by Okash Khawaja
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

[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 <

Post by Samuel Thibault

Post by Okash Khawaja
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.

Post by Okash Khawaja
Also, I understand speakup being a line discipline and the challenges

involved

Post by Okash Khawaja
in creating device file and assigning speakup ldisc to it. But don't

know how

Post by Okash Khawaja
it ties with it this work.

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

Post by Okash Khawaja
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.

Post by Okash Khawaja
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