> > 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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|