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 ;-)