EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: src/ reorganization
From: "Jeff Hill" <[email protected]>
To: "'Davidsaver, Michael'" <[email protected]>, "'Andrew Johnson'" <[email protected]>, <[email protected]>
Date: Wed, 8 Dec 2010 08:58:26 -0700
> > excas      = cas/ex

btw, I believe that this is in fact roughly where it (the example pcas
service) used to be before it was moved some time back when it was decided
to include an example server in the templates.

there is currently this

src/cas/example/directoryService

there used to be also this (as I recall)

src/cas/example/simple

> > > rsrv       = ioc/rsrv

Perhaps this (rsrv) goes in under ca also if we are partitioning along
functional boundaries. Yes it is only used in the IOC, but it seems to
belong with ca if we have any hope of consolidating to only one ca server
implementation in the future, and that server will presumably be maintained
under ca.

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Davidsaver, Michael
> Sent: Wednesday, December 08, 2010 8:28 AM
> To: Andrew Johnson; [email protected]
> Subject: RE: src/ reorganization
> 
> 
> 
> > -----Original Message-----
> > > = src/ reorganization
> > >
> > > When I look at the src/ directory I see seven categories:
> > >
> > > tools - Build system helpers
> > > libCom - Things with no dependence on IOCs or CA
> > > template - the make*App.pl scripts and templates
> > > ioc - Everything related to PDB mechanics
> > > std - Standard record definitions and soft device supports
> > > ca - CA client library
> > > cas - portable CA server
> >
> > Compare your ideas with my Unbundling (3.15/++) item on
> > http://www.aps.anl.gov/epics/wiki/index.php/Future_Development_Ideas
> 
> The only significant difference is the separation between DB processing
> mechanism, and standard record types.
> 
> 
> > > as         = ioc/as
> > We should split up src/as with the asDbLib files going to src/ioc/db
> > and the
> > asLib files to src/libCom/as.  The CA gateway uses asLib but shouldn't
> > have to
> > be linked against the rest of the IOC as it doesn't need it.  I think
> > this
> > split is clean and should be reasonably obvious to whoever does it.
> 
> Noted.
> 
> In the interest of not doing too much at once I'd like to do that this
> in stages.  The first stage to be just moving whole directories.  The
> second would be file moves.  Third would be merging the lib*Ioc
> libraries.  The intent is that to ensure that things remain buildable
> after each step.
> 
> Does this seem acceptable?
> 
> > > bpt        = ioc/bpt
> > > db         = ioc/db
> > > dbStatic   = ioc/dbStatic
> > > dbtools    = ioc/dbtemplate
> > > misc       = ioc/misc
> > > registry   = ioc/registry
> > > rsrv       = ioc/rsrv
> > > RTEMS      = ioc/RTEMS
> > Could the src/RTEMS files be moved into src/libCom?  That's where all
> > of the
> > other OS-specific source files are now found (or should be IMHO), and
> > it lets
> > people build other non-IOC applications on top of our OSI layer.
> 
> Yes I think so.  The application created only uses the IOC shell.
> 
> > > vxWorks    = ioc/vxWorks
> > src/vxWorks no longer exists in the lp:epics-base (3.15) repository,
> it
> > was a
> > hold-over from the 3.13 compatibility code which I've already deleted.
> 
> Noted
> 
> > > ca         = ca
> > > cas        = cas
> > > excas      = cas/ex
> > > gdd        = cas/gdd
> > I agree with Jeff about using src/ca/client and src/ca/legacy sub-
> > directories.
> > I'd suggest combining the src/cas/{generic,io/bsdSocket,generic/st}
> > source
> > directories into one src/ca/legacy/pcas though, and delete the parts
> of
> > src/cas that we don't use any more.
> 
> I understand this to be:
> 
> ca    = ca/client
> cas   = ca/legacy/pcas
> gdd   = ca/legacy/gdd
> excas = ca/legacy/pcas/example
> 
> Is this correct?
> 
> > > = Library mergers
> > >
> > > From what I can tell most of the *Ioc libraries can't really be used
> > > independently of one another.
> > > It seems to me that they fall into three groups.
> > >
> > > dbBase = asIoc, dbIoc, dbStaticIoc, dbtoolsIoc, miscIoc, rsrvIoc,
> > >          registryIoc
> > >   The basic processing mechanisms which operate on dbCommon.
> > >
> > > dbStd  = recIoc, softDevIoc, testDevIoc
> > >   The standard recordtypes
> > The testDevIoc library is device support for regression testing and
> can
> > probably be moved out of Base into the lp:epics-base-test project.
> > That means
> > the src/dev/softDev directory can become src/std/dev.
> 
> So
> 
> src/dev/softDev = src/std/dev
> src/dev/testDev = src/std/test  (pending removal)
> 
> 
> Also, it was suggested to change the library names to libdbCore and
> libdbRecStd.
> 
> > > dbHost = asHost, dbStaticHost
> > >   Host tools like dbExpand use this
> >
> > See above for discussion about src/as.  dbStaticHost is being replaced
> > by DBD
> > file processing code written in Perl (which exists), so I think we
> > could drop
> > this library completely.  The new Perl code would become something
> like
> > src/ioc/tools.
> 
> Noted.




References:
src/ reorganization Davidsaver, Michael
Re: src/ reorganization Andrew Johnson
RE: src/ reorganization Davidsaver, Michael

Navigate by Date:
Prev: RE: src/ reorganization Davidsaver, Michael
Next: [Bug 687435] [NEW] Callback subsystem behavior for muitlple callbacks Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: src/ reorganization Davidsaver, Michael
Next: RE: src/ reorganization Davidsaver, Michael
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·