On Mon, 2015-01-19 at 20:15 +0100, Richard Cochran wrote:
> On Mon, Jan 19, 2015 at 06:05:07PM +0000, Keller, Jacob E wrote:
> > On Thu, 2015-01-15 at 12:42 +0100, Richard Cochran wrote:
> > > On Mon, Jan 12, 2015 at 10:03:42PM +0000, Keller, Jacob E wrote:
> > > > What about section settings for things like the per-adapter stuff? This
> > > > is where it got really complicated.
> > >
> > > Yup, also for per-port defaults, we need to put on our thinking caps,
> > > but it shouldn't mean rocket science.
> > >
> >
> > Ya. I think I have a solution for this.
>
> Here is an idea that I have been thinking over (but not coding ;)
>
> An config has a list for sections and a hash table for config items.
>
> struct config {
> list *sections;
> struct hash *table;
> };
>
> A new config has 'sections' and 'table' initially empty. A 'section'
> has a string name and nothing else (that I can think of now).
>
> In addition to the other field I sketched before, the config_item also
> has a pointer to the 'section' to which it belongs.
>
> The items are hashed into the table using "section_name:item_name".
>
> There is method to add a section, and there are methods to add, query,
> and change items.
>
> config_add_section(cfg, name);
> config_add_item(cfg, section, name, default_val, range, type, ...);
> config_get_item(cfg, section, name);
> config_set_item(cfg, section, name, val); /* called by file/cmdline
> parser */
>
> In addition, the file parser needs to know what to scan:
>
> config_item_type(cfg, name); /* called by file parser */
>
> The add/get/set methods can either work with a polymorphic union, or
> they become a family of calls, with one flavor for each of int,
> double, etc.
>
> Now adding a new option just becomes adding two lines, one default
> with ranges config_add_item() and one call to actually use the option
> somewhere.
>
> Thoughts?
>
> Thanks,
> Richard
I like this approach. I'll probably avoid the polymorphic union being
passed around, as I dislike that it makes it too easy for client of
config code to mis-use the types. They should request the type they
want, and if the configuration option doesn't have that type it should
simply error out.
Then we can simply define the default values and available values in the
config block, and the file parser can simply set.
If nothing is set then it gets the standard default value :)
I really like this approach.
Hopefully I can get to actually coding it soon ;)
Is there a standard implementation of a HASH similar to STAIL_QUEUE?
Regards,
Jake
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
