On Wed, Oct 10, 2012 at 02:36:22PM +0530, Suprasad Mutalik Desai wrote: > AFAIK, the "CONFIG_MIPS_VPE_APSP_API" was used to get the console dump of > the SP program running on the VPE1 (usually a bare-iron program compiled > with MIPS provided toolchain) . This option was useful on the MALTA > platform during the initial evaluation of the APRP or APSP mode. kspd has never been a brilliant thing - it's running in an essentially random thread / file context so it's just coincidence something is working at all. Also syscalls from inside the kernel are frowned upon these days and are being eleminated. Another issue was that the provided toolchain you mentioned was the SDE toolchain along with its libraries. The SDE toolchain uses different values for all its constants which requires a compat layer. That should rather stay outside the kernel but as it was, it was burried inside kspd.c. If somebody fixed up kspd I absolutely don't mind resurrecting it but as it was, the sole feedback I ever had was from various other kernel developers. NOT A SINGLE USER. EVER. So I quite liked the nuclear solution for kspd. My suggestion would be to convert the old kspd into some communication facility where the bare metal code talks through the rtlx with a userspace daemon which then does the actual I/O operations. That also solved the ABI issue - as it was, kspd had no concept of which ABI to use. And probably not even the bare metal code should have or it ends up carrying half a libc along ... > Now if this support is removed then is there any alternative provided by > MIPS ?. You have to ask MIPS. I'm only the God of Revenge that rips patches into bits and removes kernel features ;-) Raf
