2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 <2008> 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | RE: EPICS Base's support on Phar Lap ETS |
From: | "Jeff Hill" <[email protected]> |
To: | <[email protected]>, <[email protected]> |
Cc: | "'Ken Evans'" <[email protected]> |
Date: | Mon, 18 Aug 2008 17:33:31 -0600 |
Hi Alex, Integration of your efforts into the distribution sounds like a great
idea to me. This will of course be beneficial for LabVIEW / EPICS integration. Ø Only WinSock 1.1 is
supported on Phar Lap That’s unfortunate because newer Winsock interfaces have been
around for a long time, and we do use them to query the list of network
interfaces that are attached. What is implied functionally is that EPICS can populate
the address lists for search requests and beacons automatically
(EPICS_AUTO_ADDRESS_LIST=YES) if winsock II is available – otherwise not. As I
recall, the winsock II interface is not available initially only on certain archaic
W95/98/NT windows OS, and furthermore I think that we are currently not
supporting system that don’t have winsockII because as, at one time, it wasn’t
difficult to upgrade older systems. Ø You cannot create a
process, only one process allowed on PharLap Really not an issue because on such systems {currently RTEMS and
vxWorks} we just spawn off a thread instead. We only need to stub out which one
is allowed in an OS specific code. Ø Thread Priority Range
is (-128 to 127), much like VxWorks' (0 to 256) Ditto – we only need to stub out in OS specific code the code
that maps the priority. So I see three issues that someone will need to look into: 1)
The pharlap constraints are strongly reminiscent, if I recall correctly,
of Windows CE constraints. So perhaps we should try to look for a source code structure
that will allow also Windows CE to be easily integrated. 2)
Packaging is maybe also an important issue as we might prefer to
have a common directory under libCom/osi/os that is shared by pharlap, win32,
and Windows CE so that the code is properly organized for easy maintenance.
Perhaps we will need folders under osi/os called winXX, WIN32, pharlap, and
WINCE? 3)
Do we give up on querying the network interface on pharlap and Windows
CE or is there some OS specific plug-in we can implement? That approach is certainly
easily accommodated by the current structuring of the source code if
alternative callable interfaces exist specific to pharlap. In fact, we already
have an OS specific plug in for winsock as I recall. Thanks for your efforts, Jeff From:
[email protected] [mailto:[email protected]] On
Behalf Of [email protected]
|