Ntpd config file support

[Laurent Bercot]

On 21/03/2014 23:10, Cathey, Jim wrote:

> The only thing BB would need would be to isolate initialization
> into separate functions that would be grouped together by the
> linker.  (And an associated link control file.)  The usual demand-paged
> kernel will take care of the rest.

  Yes, that would definitely be the right approach. However, it conflicts
with code organization, and thus, maintainability: currently, the code is
sharded by functionality, which is sane and sound - but the linker would
need the code to be sharded by type, init or non-init, which is exactly
orthogonal to functionality. I'm not up to date with latest linkers, but
unless you can annotate functions inside a single .c, it means that you
now need to split every single functionality into at least two .c files.
So you need to have headers for the common data structures between two
parts of the same functionality, and you want to isolate the interfaces
so you make the headers private, etc. It's still manageable at this point,
but the increase in complexity is major for a benefit that is probably
marginal. (But a reasonably accurate estimation of this benefit would
definitely be useful.)


> (When using direct-mapped NOR flash, for example,  you
> wouldn't care even then.  With IDE-accessed flash, or rotating
> media, or a compressed filesystem, resident text pages would

  For compressed filesystems, yes. For storage devices, it's not even
certain: depending on the filesystem, newer Linux kernels have an
execute-in-place option, and storage devices have a decent cache so
it's not prohibitive.

-- 
  Laurent