Hi Anurag,

You sent the enclosed notes to a few of us a while back, and I
think you're right, they need to be put somewhere; I'm thinking
a readme in either libnwam or the nwamcfg dir in the project
gate would be a good place.

I'm working on adding a property right now, and they've come in
very handy so far.  :-)  I do have a couple questions, though.
First, are they up-to-date?  They seem mostly to be, but the
name of the skip table mentioned in item G needs to be updated.

My second question is more general; I need some advice on how
nwamcfg should deal with a new object attribute.  The property
I'm adding is a boolean that marks the object as read-only
(more specifically, not user-modifiable).  The initial use is
for the automatic ncp, which nwamd will create and update as
needed (when new links are added to the system).

I would like nwamcfg users to be able to view objects that are
marked read-only; but obviously, they shouldn't be able to change
them.  I'm adding some checks in the API to disallow commit()s
when this property is true; but I think it would be good if the
cli could recognize this property and not go down the path of
allowing the user to enter new values, only to fail when commit()
is attempted.  Do you have any ideas on how best to work this
sort of check into nwamcfg?  I know I should probably come up
with a proposal myself, but I'll confess that the lex/yacc bit
makes my head spin; so I'm taking the easy way out and asking
you, given your experience with and knowledge of this code.

Thanks!
renee

----- Forwarded message from "Anurag S. Maskey" <Anurag.Maskey at Sun.COM> -----

From: "Anurag S. Maskey" <[email protected]>
Date: Thu, 04 Sep 2008 09:43:50 -0400
Subject: Re: some property details to iron out
To: Alan Maguire <Alan.Maguire at Sun.COM>
Cc: Renee Danson <Renee.Danson at Sun.COM>
User-Agent: Thunderbird 2.0.0.12 (X11/20080310)

Because we are still discussing add/removing properties and more can happen 
in the future, I'd like the following README/comments put somewhere (don't 
know an appropriate place yet) so that adding/removing properties are 
documented.  These are basically the steps to follow in libnwam and nwamcfg 
whenever a new property is added (removing a property is making deletions):

A. libnwam.h
   1. Add a #define constant.
   2. If the value for this property will be enums, typedef those enums.
   3. Also, create string representations for these enums using #define 
(used by nwamcfg to print out as list of options and then convert the 
user-typed string back to an enum).

B. libnwam_values.c (Only if A2 and A3 are done)
   1. Create a new table of nwam_value_entry.  This table matches the enum 
to the string.
   2. Add the newly created table to the prop_value_entry_table[].

C. libnwam_{ncp|loc|enm}.c
   1. Add the property to nwam_{ncu|loc|enm}_prop_table[].  Also, add the 
name of the validation function that will be written (if one that already 
exists is not used).
   2. Add the new validation function.  This function takes a nwam_value_t 
and makes sure that the value is correct.

D. nwamcfg.h
   1. Create a constant for the property using #define.  The convention is 
to prefix the constant with PT_.  Try to keep these constants in order for 
easy reading.  If you add to the beginning or end of the list, be sure to 
update constants PT_MIN and PT_MAX.

E. nwamcfg_lex.l
   1. Add the property to the list of <TSTATE> and return a token (which 
will be used in nwamcfg_grammar.y)

F. nwamcfg_grammar.y
   1. Add the token from nwamcfg_lex.l to the list of tokens (each line 
starts with %token)
   2. Set this token to be of type "property_type" by adding it to the 
list.
   3. Define the constant that this token will return.  Add to the grammar 
line "property_type:".  This uses the PT_ defined in nwamcfg.h.

G. nwamcfg.c
   1. Add the property to the array pt_types[].  This array has to match 
the order of #define PT_ in nwamcfg.h
   2. Add the property to the {ncu|loc|enm}_prop_table.  The pt_type is the 
PT_ defined in nwamcfg.h
   3. If this property creates any special considerations with other 
properties (for example, it should be skipped when some other property has 
a specific value, or this property having a specific value skips some other 
property, then add to {ncu|loc|enm}_prop_skip_entry_table[].  Read the 
block comments before the prop_skip_entry_t struct for the format of these 
rules.

Thanks,
Anurag


----- End forwarded message -----

Reply via email to