Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: 2 MAXv problems
From: sheng peng <pengsh2003@yahoo.com>
To: tech-talk@aps.anl.gov
Date: Thu, 11 Mar 2010 13:03:21 -0800 (PST)
This is a interesting topic.

I searched thru the vxWorks kernel programmer manual from 5.3.1, 5.5, 6.0, 6.x all the way to 6.8.
Nowhere sprintf is mentioned to be illegal in ISR.
Clearly, printf, malloc ... are not allowed.
But I think all agree that sprintf is fat and heavy, so try use as little as possible.
And if any floating point involved, fppSave/fppRestore are needed.

When I dig into source code, more fun there.
In vxWorks, before AltiVec support, sprintf seems safe, no any funny call there, and the implementation is much lighter than regular GNU implementation.
After AltiVec, when sprintf try to line-up vector, malloc could be invoked!!!
So Steve is definitely right, this sprintf is no good.

When look into GNU implementation, malloc is in many places, so no good.

General speaking, no sprintf in ISR, is not because of floating point, but malloc, and heavy/fat anyway.

I have to say one of the major reason the sprintf gets into ISR is because people try to make code OSI compatible.
But epicsInterruptContextMessage  is too simple to use. It takes only a string, no any other parameter.
This is the major reason people use sprintf to prepare that string.

epicsInterruptContextMessage should be really written to use logMsg/printk and support a few parameters.

Regards,
Sheng

BTW, according to QNX manual, in QNX, strcpy, strxxx ... except strdup are ISR safe, so does memcpy ...




Navigate by Date:
Prev: Re: Building EPICS for multiple Linux distributions Rod Nussbaumer
Next: RE: Building StreamDevice 2-4 / SynApps / Win32 John Dobbins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: 2 MAXv problems Joachim Rahn
Next: Problem while Launching EDM Hiren Patel
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·