I'm working with dmwaters on getting a speakup-enabled installcd for sparc64. Currently gentoo-sources-2.6.21 fails to build the ltlk driver for it (haven't tested others yet, have to check which ones would be available for sparc, i.e. not ISA and so on). HOSTCC drivers/char/speakup/makemapdata drivers/char/speakup/makemapdata >drivers/char/speakup/mapdata.h HOSTCC drivers/char/speakup/genmap drivers/char/speakup/genmap drivers/char/speakup/speakupmap.map >drivers/char/speakup/speakupmap.h CC drivers/char/speakup/speakup.o drivers/char/speakup/speakup.c: In function ‘say_line’: drivers/char/speakup/speakup.c:900: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’ drivers/char/speakup/speakup.c:900: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’ CC drivers/char/speakup/speakup_drvcommon.o In file included from drivers/char/speakup/speakup_drvcommon.c:15: drivers/char/speakup/serialio.h:8:24: error: asm/serial.h: No such file or directory drivers/char/speakup/speakup_drvcommon.c:23: error: ‘SERIAL_PORT_DFNS’ undeclared here (not in a function) make[3]: *** [drivers/char/speakup/speakup_drvcommon.o] Error 1 make[2]: *** [drivers/char/speakup] Error 2 make[1]: *** [drivers/char] Error 2 make: *** [drivers] Error 2
Couple things If you could try it on another previous kernel to see if it has similar results, that'd be helpful. There doesn't seem to be an asm-sparc64/serial.h under 2.6.20 either.
From what Daniel said, this is a problem with the gentoo patch for speakup. So the problem is that asm-64/serial.h doesn't exist. It exists for many archs but not for sparc64. The variable from that header file it uses is SERIAL_PORT_DFNS . Daniel suggested that I find a way to include what is needed from include instead of asm but nothing in include seems to provide this. After grepping through the whole source for that variable, it seems to me that most drivers that use the variable either define it themselves or include it from asm/serial.h .
I'm not sure if there is an easy fix for this... Most archs provide an asm/serial.h file, but sparc doesn't. I found this comment: /* * SERIAL_PORT_DFNS tells us about built-in ports that have no * standard enumeration mechanism. Platforms that can find all * serial ports via mechanisms like ACPI or PCI need not supply it. */ Presumably sparc is one of those platforms. However, speakup uses SERIAL_PORT_DFNS for addressing serial ports. Presumably there's some other cross-platform way it should be doing it instead. I don't see this being fixed any time soon. I'm tempted just to mark speakup as unselectable on sparc -- speakup's serial access needs reworking, and you don't have ISA.
It seems some architectures just define an empty SERIAL_PORT_DFNS to prevent stuff that uses it from breaking (ex: parisc). From what i'm seeing in the speakup source it doesn't necessarily need it if a serial port is forced, not very "GUI" but it should work right?
speakup built fine with a dummy asm-sparc64/serial.h with an empty #define SERIAL_PORTS_DFNS. However i don't think davem will like this fix, i'd rather patch speakup to do the empty def when __sparc__ or just an empty rs_table[]
My interpretation of the code is that SERIAL_PORT_DFNS (i.e. a non-empty rs_table) is required. spk_serial_init(): If you specified (forced) a serial port on the command line, it loops through rs_table until it finds an entry for it. If there is no entry for it, ser remains NULL so it then immediately gets dereferenced: quot = ser->baud_base / baud; ---> kernel crash (gotta love speakup code) If you didn't force a serial port, an entry inside rs_table is used based on the 'index' parameter to the function. If rs_table is empty then this will always result in an array overrun --> kernel crash (maybe a delayed one) I think that either of these codepaths will happen when the synth is loaded even if you don't have the hardware. Trace: __initcall(speakup_dev_init); // executed during boot speakup_dev_init calls synth_init synth_init calls do_synth_init do_synth_init calls synth->probe (random example) synth->probe is synth_probe() in speakup_apollo.c synth_probe() calls serprobe() for index 0 (and later 1,2,3) serprobe calls spk_serial_init() then we end up with either one of the two codepaths above, both of which will crash the kernel. That said, the user could compile just speakup with no serial synth drivers (or find some way of not loading them) and just use the userspace-driven software synthesizer. So, yes, we could hack speakup to compile without SERIAL_PORT_DFNS, with the understanding that trying to load a serial synth will crash the kernel, but the user can (hopefully) safely use the software synthesizer driver, but will this actually be useful? I guess Deedra is our only user at this point in time, who I think uses serial hardware, and fixing speakup to work with serial without SERIAL_PORT_DFNS will definitely take some time.
oh crap.. i386/x86_64 now has the same problem :( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26
I don't see any fix to this without rearchitecting (and somewhat crippling) speakup. We'll probably be dropping this patch until a nice solution can be found.
I was just alerted to this bug today, and wanted to add a comment. If the speakup patch is dropped, it will be a major step backward in terms of accessibility for gentoo linux. Currently, gentoo is the only distro that I know of which can be installed completely independently by a blind person, and if this patch is removed, we will remove that capability. Thanks much.
I know it's a problem for you, it's not a fun situation. It's a problem for me either way -- speakup has caused us several serious kernel bugs for users who do not even include speakup in their kernel configuration. The patch is so big and horrible, it really decreases the quality of our kernel patch set. Right now there's just no way speakup will work on 2.6.22. It won't even compile. The only solutions I have come up with involve having a userspace agent apply a speakup line discipline to a serial port. If we have this, we might as well pump most or all of speakup out to userspace as it would be much nicer there. However this is against the design goals of speakup. I have no other ideas for how to approach this cleanly. Sorry.
