>
> 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.
>
There's already a README at libnwam.
Either place with pointers in comments to the README is in both
libnwam.h and nwamcfg.c. Just realized that the GUI must be included in
this README in some way.
> 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.
>
Yep. This was updated with Bug 4406 "skipping properties in walkprop
broken", where I had to redo the logic behind how to determine which
properties to skip.
> 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.
>
If nwamcfg allows users to view these objects, then they should be
allowed in "select", "list" and "get". What we don't want users to do
are "set", "walkprop", and "clear", and "destroy". Read-only properties
(like NCU type, parent) are manually checked in "set" and not updated.
The same check is done in "walkprop" and not shown. "clear" doesn't do
this and should be able to - I've logged Bug 5667.
Are the checks in the API checking for the object name? If so, then
nwamcfg can have the same kind of checks in set, walkprop, clear,
destroy: retrieve the name from the handle and check to see if the name
matches the read-only object name. I can't think of another way because
other commands have to be allowed.
What about "export"? Do you want this read-only object to be included in
export? If so, then there's a conflict since the exported configuration
is imported by running nwamcfg.
The README on adding new properties will need to specify what to do if
read-only properties are to be added. I'll update it and push it to the
gate once we determine and how the doc is to be placed.
Anurag
> Thanks!
> renee
>
> ----- Forwarded message from "Anurag S. Maskey" <Anurag.Maskey at Sun.COM>
> -----
>
> From: "Anurag S. Maskey" <Anurag.Maskey at Sun.COM>
> 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 -----
> _______________________________________________
> nwam-dev mailing list
> nwam-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/nwam-dev
>
