Re: unresoved symbol _gp_disp

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Oct 04, 2007 at 08:29:59PM +0200, Andi Kleen wrote:
> From: Andi Kleen <andi@firstfloor.org>
> Date: 04 Oct 2007 20:29:59 +0200
> To: "Steven J. Hill" <sjhill@realitydiluted.com>
> Cc: veerasena reddy <veerasena_b@yahoo.co.in>,
> 	linux-mips <linux-mips@linux-mips.org>,
> 	"linux-kernel.org" <linux-kernel@vger.kernel.org>
> Subject: Re: unresoved symbol _gp_disp
> Content-Type: text/plain; charset=us-ascii
> 
> "Steven J. Hill" <sjhill@realitydiluted.com> writes:
> 
> > > I have written a loadble module ( which gets complied
> > > along with kernel) which does some floating point
> > > operation.
> > >  
> > NO FLOATING POINT in the kernel PERIOD. Either use integer
> > operations, or redo your software architecture and do the
> > floating point in userspace.
> 
> You can use floating point; you just have to make sure to 
> save the FP context explicitely and disable preemption. Details
> on how to do this vary by architecture.
> 
> The problem is that FP code typically takes often a lot of CPU time
> and it is quite antisocial to disable preemption for a long time
> because that impacts real time latency for everybody.
> 
> Besides many uses can be relatively easily rewritten to fixed
> point.

He said he was using software floating point which from a kernel perspective
really just is integer stuff anyway.

Hardware floating point in a MIPS kernel would be require solving a few
interesting problems; the kernel floating point assist software is only
designed to support userspace.  Or alternativle well written FP code
that avoids all the corner cases which would normally be handled by the
kernel fp software.

The biggest argument against floating point use in the kernel is that most
of the time it's an indicator for poor division of work between kernel
and userspace.

  Ralf