EPICS Home

Experimental Physics and Industrial Control System


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

Subject: Re: EPICS base V4: iocCore database
From: Marty Kraimer <[email protected]>
To: Jeff Hill <[email protected]>
Cc: 'Andrew Johnson' <[email protected]>, Bob Dalesio <[email protected]>, Ralph Lange <[email protected]>, Eric Norum <[email protected]>, Benjamin Franksen <[email protected]>, Ken Evans <[email protected]>, Ned Arnold <[email protected]>, Matej Sekoranja <[email protected]>, Marty Kraimer <[email protected]>
Date: Mon, 21 Feb 2005 08:41:35 -0600


Jeff Hill wrote:

Hello Marty,

Here are my comments.

Yes, PP should be on the list for next rev of CA.

Primitive Types
---------------

o Past versions of CA were based on size locked types - i.e.
"typedef epicsInt16 dbr_int_t;". However, my experience is that
users seldom bothered to use dbr_xxx_t, and my current
perspective is that size locked types should not be in interfaces
used by users. Data access is an example of an interface that
binds to the user's selected primitive data type instead of
requiring that users recode to yet-another size locked data type
system.
o Data access is more fool proof because it uses overloaded
functions instead of a data type code and a void pointer.

o We can generate C and Java bindings for data access as needed.


Don't these, or at least the set that reproduces V3 functionality, need to be defined now?

The problem I have with Data access is that it seems to be a solution to a set of undefined requirements.

Let me focus the problem a little more.

What will the V4 Gateway be?  How will it store data?

I think that answering these two questions will go a long way to deciding if and how Data access is a necessary component.


o Data access supports safe conversion between all of the
primitive types available in C. If the source is out of range for
the destination the operation is not performed and an error is
returned to the user. This has already been implemented.


Is this what we want?
Let me give an example

An IOC has a field that is an unsigned 32 bit integer.
A java application asks for the fields as a signed 32 bit integer.
The java application only uses the field as a bit mask.

Should CA return an error if the value happens to have the high order bit = 1?
I say no.

For an IOC perhaps we should just not support conversions that can cause problems.
This is what I proposed in "EPICS V4 epicsTypes".

On
linux-x86 the object code is less than 16kB of object code for
scalars and 26kB for arrays. The array code includes a high speed
loop customized to each conversion. We could use a type
independent loop to save space, but that would not perform as
well.
DBD
---
o For multi-dimensional arrays I see an element count (capacity)
for each dimension, but not a starting element for each
dimension. This is probably correct for specifying fields.


Correct. The offsets, etc are an issue for database access but not database definition.

For
links it might be important to specify the starting element when
targeting a slice from another record's array.


Good point.


String Lib
----------
o This interface precludes implementations which store the string
in homogenous fixed sized non-contiguous blocks. This is
important when avoiding memory fragmentation, and when
efficiently using available memory. The data access interface
*does* allow storage of strings in fixed sized non-contiguous
blocks. Admittedly, the data access daString interface has
postponed the numeric conversion issue by leaving that up to the
string storage implementation. In any case memory management is a
*very* important issue that has side effects in other parts of
the design.
How to implement arbitrary length strings is a big issue especially memory management.
Also supporting UTF-8 is a big issue.

We do NOT want to create our own complete string library including the equivalent of the printf and scanf family. But what do we need? Big issue.

Struct Lib
----------

o This seems to be a subset of the data access interface and
associated libraries.

And perhaps the only subset needed?

o Indexing structure fields using a field name string may be too
inefficient for high throughput situations?

Agreed. The example was only to show that applications that do not know about the structs can still access elementary fields.

I am envisioning that structs will be the way to make "atomic" access to multiple fields. To make the atomic access the an application will have to work with the struct rather than just accessing individual fields.

o There is no way to introspect the available fields, and there
values, in an unknown structure (i.e. traverse functionality in
data access).

It should be easy to provide introspection for structs. Thus generic applications can be written that can access arbitrary structs. The V4 gateway, for example, will probably need to support arbitrary structs.


Marty



Replies:
RE: EPICS base V4: iocCore database Jeff Hill
References:
RE: EPICS base V4: iocCore database Jeff Hill

Navigate by Date:
Prev: RE: EPICS base V4: iocCore database Jeff Hill
Next: Re: [Fwd: RE: EPICS base V4: iocCore database] Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: EPICS base V4: iocCore database Jeff Hill
Next: RE: EPICS base V4: iocCore database Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024