summaryrefslogtreecommitdiffstats
path: root/src/core/nvo.c
diff options
context:
space:
mode:
authorMichael Brown2008-10-29 19:17:02 +0100
committerMichael Brown2008-10-30 22:47:14 +0100
commit0a6c66a83018c64d961ee4e8601ae8950cbee00b (patch)
treec4adb1baea7c87b4e0bbd9f7d1f9127e738065d5 /src/core/nvo.c
parent[romprefix] Further sanity checks for the PCI 3 runtime segment address (diff)
downloadipxe-0a6c66a83018c64d961ee4e8601ae8950cbee00b.tar.gz
ipxe-0a6c66a83018c64d961ee4e8601ae8950cbee00b.tar.xz
ipxe-0a6c66a83018c64d961ee4e8601ae8950cbee00b.zip
[settings] Add the notion of a "tag magic" to numbered settings
Settings can be constructed using a dotted-decimal notation, to allow for access to unnamed settings. The default interpretation is as a DHCP option number (with encapsulated options represented as "<encapsulating option>.<encapsulated option>". In several contexts (e.g. SMBIOS, Phantom CLP), it is useful to interpret the dotted-decimal notation as referring to non-DHCP options. In this case, it becomes necessary for these contexts to ignore standard DHCP options, otherwise we end up trying to, for example, retrieve the boot filename from SMBIOS. Allow settings blocks to specify a "tag magic". When dotted-decimal notation is used to construct a setting, the tag magic value of the originating settings block will be ORed in to the tag number. Store/fetch methods can then check for the magic number before interpreting arbitrarily-numbered settings.
Diffstat (limited to 'src/core/nvo.c')
-rw-r--r--src/core/nvo.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/core/nvo.c b/src/core/nvo.c
index 13078022..e5c07d98 100644
--- a/src/core/nvo.c
+++ b/src/core/nvo.c
@@ -203,7 +203,7 @@ void nvo_init ( struct nvo_block *nvo, struct nvs_device *nvs,
nvo->nvs = nvs;
nvo->fragments = fragments;
settings_init ( &nvo->settings, &nvo_settings_operations, refcnt,
- "nvo" );
+ "nvo", 0 );
}
/**