search for: info_flag

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional

Arnaud: in today's commits, I removed three lines that you apparently added on August 10: 1.1.1.1.8.1 (aquette 04-May-05): if (mode == HU_WALKMODE_INIT) 1.1.1.1.8.1 (aquette 04-May-05): { 1.1.1.1.8.1 (aquette 04-May-05): dstate_setflags(item->info_type, item->info_flags); 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): /* Verify variable setability/RW */ 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): if (get_current_data_attribute() != ATTR_DATA_CST) 1.1.1.1.8.6.2.5 (aquette 10-Aug-05): dstate_setflags(item->info_type, ST_FLAG_RW); 1.1.1.1.8.1 (...

...ommand line just like you would do with instant commands/setvars, plus the driver preferred way of communication is through NUT variables): the closest thing you can do is to: 1. set a var (let's say "zig.zag") to a value (so there should be both a bare "zig.zag" item_t with info_flags ST_FLAG_RW and a QX_FLAG_SETVAR "zig.zag" one in nutdrv_qx) or use an internal var that gets its value from something other; 2. use that var (either the user-provided one, "zig.zag" , or the internal one) to fill the query (preprocess from NUT-form to device-form and write to d...

...t; Now, I know that there can be queries that need to be preprocessed > (QED<date> and the like, right?), Correct. > the closest thing you can do is to: > 1. set a var (let's say "zig.zag") to a value (so there should be both > a bare "zig.zag" item_t with info_flags ST_FLAG_RW and a > QX_FLAG_SETVAR "zig.zag" one in nutdrv_qx) or use an internal var that > gets its value from something other; > 2. use that var (either the user-provided one, "zig.zag" , or the > internal one) to fill the query (preprocess from NUT-form to > d...

...ning" }, + { 3, "done and error" }, + { 4, "aborted" }, + { 5, "in progress" }, + { 6, "no test initiated" }, + { 0, "NULL" } +}; + + +/* HUAWEI Snmp2NUT lookup table */ +static snmp_info_t huawei_mib[] = { + + /* Data format: + * { info_type, info_flags, info_len, OID, dfl, flags, oid2info, setvar }, + * + * info_type: NUT INFO_ or CMD_ element name + * info_flags: flags to set in addinfo + * info_len: length of strings if STR + * cmd value if CMD, multiplier otherwise + * OID: SNMP OID or NULL + * dfl: default value + * flags: snmp-up...

Hi all! I'm wondering if there's anyone doing any hacking on the snmp-ups driver at the moment. I've started looking at implementing 3phase-support, and this uncovered some rather unpleasant stuff in the snmp-ups driver that I really need to fix in order to get things sane. Those of you that's allergic to SNMP might want to stop reading now, this is rather icky ;)

I am working on a Linux-based boot disk for my project (http://unattended.sourceforge.net/), and I have hit a snag. Under Linux 2.6, the kernel (via HDIO_GETGEO) always reports the C/H/S geometry of an IDE drive as X/16/63. But most BIOSes want to use the geometry Y/255/63. Most partitioning tools (including Parted) will take clues from an existing partition table and adapt to the BIOS values.

...(1) use_kerberos : 0x00 (0) secure_channel_type : SEC_CHAN_WKSTA (2) [2011/01/21 09:50:41.270859, 10] libsmbc:1132(dsgetdcname) dsgetdcname: domCHINEVISIONPRODUCTS.COM, domain_guid:_name: (null), flags: 0x40001011 [20:41.270901, 10] libsmb/dsgetdcname.info_flags) debug_dsdcinfo_fla DS_FORCE_REDISCOVERY DS_DIRECTORY_RED DS_WRITABLE_REQUIRED DS_RETURN_D01/21 09:50:41.270942, 5] lib/gencacche_init) Opening cache file at /vencache.tdb [2011/01/21 09:50:41.2710encache.c:108(gencache_init) Opening cache filat /var/lib/samba/gencache_notrans.tdb [2011/0...