Well, lets try again. I think I didn't participate last time because I
don't know anything about coding to talk to the serial port. Maybe if we
broaden the scope a little it will garner more interest. As I said, I
agree with the assertion someone made (Janina?) that the first thing we
should do is write up some specs.
I am willing to manage the project if you'd like. Or you can take
charge. I'm fine either way.
And for what it's worth, I can offer the resources of the International
Association of Visually Impaired Technologists. We have a web server and
some money. I could probably pull together a couple hundred bucks if it
would help.
On 10/09/14 15:45, covici@xxxxxxxxxxxxxx wrote:
I could not get anyone to talk about the serial parts of speakup, I
wanted to set up a conference call, but I could not get anyone to
participate.
As for the serial console, the point was that it was not up to kernel
coding standards to patch the kernel directly, what the kernel guys want
us to do is to write a driver, as though speakup were a strange piece of
hardware which would register in the appropriate way and then it could
do any reasonable thing. I was looking at how to do this by looking at
the serial driver so I could look for any serial port, but I got
involved in some other projects, so I had to postpone that work.
John G. Heim <jheim@xxxxxxxxxxxxx> wrote:
John, didn't you once try to form a team to get started on a rewrite
of speakup. What ever happened with that? I'm not sure who said it
but I agree with whomever said the first thing we should do is try to
get a concensus on what we need in a screen reader.
But I am a bit confused by something you said below. Isn't the serial
console code in the kernel up to kernel coding standards? The reason I
ask is that I once asked on the kernel developers list what the right
way to access the serial port was. If speakup does it wrong, that
implies there is a right way, what is that? I didn't really get a
good answer. That's when I started poking around in the serial console
code.
I wish there was a good way to get explanations of this stuff from the
kernel developers.
On 10/09/14 14:23, covici@xxxxxxxxxxxxxx wrote:
The first serial driver I wrote for speakup was like that, I copied
stuff from the serial console, but it had to be changed to conform to
the kernel specs, so you didn't have to patch the actual kernel.
John G. Heim <jheim@xxxxxxxxxxxxx> wrote:
I once spent an afternoon poking around in the serial console code
trying to see how it wrote to the serial port. I never did figure it
out though. Even so, it seems to me that what speakup does is pretty
similar to the serial console.
On 10/09/14 11:23, Littlefield, Tyler wrote:
Re: writing directly to the serial port, Is there another layer that the
kernel provides that we could go through to avoid that issue entirely?
How do other devices work, or is there not any other such modules in the
kernel that do use the serial port like speakup does for synths?
On 10/9/2014 12:08 PM, John G. Heim wrote:
Hmmm... I don't know. I have to say that I remain unconvinced. I've
never seen speakup cause a kernel panic. On the other hand, I have
witnessed the false cause effect. Something happens that causes a
kernel panic and since speakup is part of the kernel, it naturally has
problems. You were on a development server, right? Isn't it more
likely that one of the developers crashed the server amd that, in
turn, caused problems for speakup? I run some development servers here
at the UW math department and it happens all the time. Somebody causes
an OOM (out of memory) event and, yes, that crashes speakup.
I once asked on the kernel developers list for comments on what's
wrong with the speakup code. There is that one biggie, of course,
speakup writes directly to the serial port. But all the other
criticisms were things like not following naming conventions, poor
indentation, etc. Maybe the people who mattered didn't bother to
answer my question. But there wasn't anything in there that would tend
to indicate that speakup is prone to causing kernel panics. Now, any
software package can have a bug. But I have no reason to believe that
speakup is particularly unstable. Quite the contrary in fact.
And even if there is a bug in speakup that can cause a kernel panic,
that's an argument for finding the bug and fixing it. Not for
abandoning it entirely.
On 10/09/14 08:34, Deedra Waters wrote:
Janina,
speakup was the cause because when bossman came down to hook up a
monitor and look, the panick messages had something to do with speakup.
As for backing up their work, they were trying to fix their fuck-up to
begin with. The initial problem wasn't with speakup. However when i was
helping them debug it, speakup made the kernel panick and crash.
Debian i dont think likes people with root access on their box to begin
with, but i think they kind of didn't like speakup in their kernel to
begin with.
I suspect on the other hand that if speakup was a user-space app, it
wouldn't have mattered to them so much. If a userspace program crashes
it doesn't take down the whole box. When speakup does though, it takes
down the whole box.
_______________________________________________
Speakup mailing list
Speakup@xxxxxxxxxxxxxxxxx
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
_______________________________________________
Speakup mailing list
Speakup@xxxxxxxxxxxxxxxxx
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
_______________________________________________
Speakup mailing list
Speakup@xxxxxxxxxxxxxxxxx
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
_______________________________________________
Speakup mailing list
Speakup@xxxxxxxxxxxxxxxxx
http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
