EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  <19961997  1998  1999  2000  2001  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: Ascii databases
From: [email protected] (Nick Rees)
To: [email protected]
Date: Tue, 9 Jan 96 17:39:12 HST
> A primary goal of the new way of handling the database definitions is that
> ascii files work the same on both the development platforms and on vxWorks.
> This lead to the decision NOT to use the c preprocessor.

Yes, I agree, it's a compromise, and I think you probably made the right
decision.

> Another goal was quick loading of ascii files. Thus the path mechanism is
> not as general as that supported by the c preprocessor, i.e. the rules
> always determine a unique place to locate an include file. The rules
> work very well on Unix (less than 1 second to load all menus, record types,
> devices, and drivers supplied with base). On vxWorks if NFS is used performance
> is still acceptable. If NFS is not used then there is about a 2 second
> overhead for every file opened. This is not acceptable (> 2 minutes to load).
> This is the only reason for dbExpandAscii.

Yes, but these times would be about the same if you had a search path
mechanism since I believe all the files in base are actually in one
directory which, (if you were sensible) would be the first in the path.

> A last goal that we have always had for Application S/R systems is to allow
> developers to simultaneously work on applications using different epics
> releases. That is why getrel creates soft links to base, etc. The App S/R
> systems in turn create soft links to base in any sub directories necessary.
> dbExpandAscii assumed the same model. The only other method I can think of
> is to use environment variables to define things such as base. This
> would mean that the application developer has to continually change the
> vales of the environment variables whenever he/she moves between applications. 

UAE does this slightly differently. First of all it doesn't use getrel.
There are soft links so the user can set his path to scan down them
(and hence satisfy your different epics releases concern), but there
are no links directly to the base directory in the source tree. Also,
the build process does not use the soft links - it uses Make variables
which are defined in a configuration file (like Epics base does).
It also makes a point of ensuring that the application directories are
pretty much position independent so the directory structure is left up
to the individual site. This enables me to send you a tar file of my
xyz driver and you can unpack it where you want to and it should make
cleanly.

> As regards to using # as the comment character. This is what is used by
> most shells (csh sh ksh bash)...

As I said, fine...

> One additional comment. Jeff Hill pointed out that using the word ascii
> everywhere is not a good idea. I am going to change things so that .db is the
> normal extension for all database related files. I also want to combine
> dbLoadAscii and dbLoadRecords into one utility called dbLoadDatabase. The
> word ascii will probably disappear everywhere.

Fine...

Back on my soap box...

Overall, I feel that the justification for the path mechanism is not
terribly strong and would prefer it to be a more normal search path
one (for both VxWorks and Unix). My reasoning is:

1. I don't like having path information that enforces a particular
   directory structure embedded in files (especially when I use a slightly
   different structure), and (to a lesser extent) that I have to be in
   a particular directory before I can execute a command. I feel this
   could make the files more difficult to maintain and transfer between sites.

2. Most of the Epics ascii (db) files tend to cluster in a very few
   directories with the vast majority of them in one. Thus, as long as the
   search path is in the right order efficiency probably won't be affected
   too much.

3. On VxWorks the database could be loaded incrementally with a different
   search path each time. Typically you could forsee loading the record
   device and driver definitions separately from the actual database info.

4. You can always use dbExpandAscii. This would be fully done via a make rule
   and so would be fairly transparent and since it was running on Unix it
   would be fast. (A hell of a lot faster than makesdr at the moment).

5. I don't like having a mechanism called `path' which is different to all
   other path mechanisms. This is both confusing and goes against the
   experience we have built up with the existing path mechanisms which seem
   to work well and are very flexible.

As a suggestion for debate is that:

1. A search path list can be be specified by some mechanism for all database
   loading tools on both VxWorks and Unix.
2. There be an implicit entry at the end of the search path list which is the
   directory in which the current file being scanned resides. If you want the
   current directory in the search path you have to add . to it.

The latter allows us to use the all.ascii directly from the base
distribution (and other summary files from other directories) and would
remove the necessity for any path commands in the base release.

The following are suggestions for various means of specifying the path
mechanism.

1. As a parameter to the various commands. (On VxWorks the commands may
   only have a single string parameter which had embedded spaces and this
   string would be parsed to form an equivalent of argc and argv).

2. As an environment variable, with paths delimited by colons.

3. As a command in the files, with paths delimited by colons.

In the best of all possible worlds you could have all three mechainisms
(but I am not doing the coding) with, probably, the first overriding
the second which overrides the third (as in makefiles). It probably
wouldn't be too hard to dream up a simple substitution mechanism (i.e.
use a plus sign to represent the existing, colon delimited, path
string) which could almost reproduce the current mechanism.

Finally I should say that I welcome people other than Marty to comment
since diverse views may help. If you all shout me down I'll shut up
gracefully. I also don't any of the history behind this decision or
even whether it is used by medm and so can't be changed without causing
a great deal of users a great deal of strife (another command line
flag?). Thus, if there are these historical I would be interested in
hearing that too.

Comments?

Nick Rees

Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
Hilo, HI.  96720                          Internet: [email protected]


Navigate by Date:
Prev: Returned mail: Cannot send message for 1 hour Marty Kraimer
Next: Re: Ascii databases Marty Kraimer
Index: 1994  1995  <19961997  1998  1999  2000  2001  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: Ascii databases Marty Kraimer
Next: Re: Ascii databases Marty Kraimer
Index: 1994  1995  <19961997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·