Runtime library, lib/silcutil/
==============================
+ o silc_malloc et. al. to respect --with-alignment.
+
o Fix universal time decoding (doesn't accept all formats) in silctime.c.
+ o Add directory opening/traversing functions
+
+ o regex from /lib/contrib to lib/silcutil, define SILC Regex API. (***DONE)
+
+ o Additional scheduler changes: optimize silc_schedule_wakeup. Wakeup
+ only if the scheduler is actually waiting something. If it is
+ delivering tasks wakeup is not needed.
+
+ o silc_stringprep to non-allocating version.
+
+ o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least.
+ SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled
+ in separately.
+
o Add functions to manipulate environment variables. (***DONE)
o Add functions to loading shared/dynamic object symbols (replaces the
SIM library (lib/silcsim) and introduces generic library). Add this
to lib/silcutil/silcdll.[ch]. (***TESTING NEEDED WIN32, TODO Symbian)
- o Add directory opening/traversing functions
-
- o silc_getopt routines
-
- o Add silc_stream_get_root and add get_root stream operation. It
- returns the root of the stream or NULL if stream doesn't have root.
-
- o Change some stream routines (like socket stream API) to accept ANY
- stream and use silc_stream_get_root to get the socket stream from the
- given stream. This will make various stream APIs more easier to use
- when user doesn't have to dig up the correct stream.
+ o silc_getopt routines (***DONE)
o The SILC Event signals. Asynchronous events that can be created,
connected to and signalled. Either own event routines or glued into
- SilcSchedule:
-
- SilcTask silc_schedule_task_add_event(SilcSchedule schedule,
- const char *event, ...);
- SilcBool silc_schedule_event_connect(SilcSchedule schedule,
- const char *event,
- SilcTaskCallback event_callback,
- void *context);
- SilcBool silc_schedule_event_signal(SilcSchedule schedule,
- const char *event, ...);
-
- Example:
- silc_schedule_task_add_event(schedule, "connected",
- SILC_PARAM_UI32_INT,
- SILC_PARAM_BUFFER,
- SILC_PARAM_END);
- silc_schedule_event_connect(schedule, "connected", connected_cb, ctx);
- silc_schedule_event_signal(schedule, "connected", integer, buf,
- SILC_PARAM_END);
- SILC_TASK_CALLBACK(connected_cb)
- {
- FooCtx ctx = context;
- va_list args;
- SilcUInt32 integer;
- SilcBuffer buf;
-
- va_start(args, context);
- integer = va_arg(args, SilcUInt32);
- buf = va_arg(args, SilcBuffer);
- va_end(args);
- ...
- }
-
- Problems: Events would be SilcSchedule specific, and would not work on
- multi-thread/multi-scheduler system. The events should be copyable
- between schedulers. Another problem is the signal delivery. Do we
- deliver them synchronously possibly from any thread to any other thread
- or do we deliver them through the target schedulers. If we use the
- schedulers then signalling would be asynchronous (data must be
- duplicated and later freed) which is not very nice.
+ SilcSchedule. (***DONE)
o If the event signals are added, the SILC_PARAM_* stuff needs to be
- moved from silcbuffmt.h to silctypes.h or something similar.
+ moved from silcbuffmt.h to silctypes.h or something similar. (***DONE)
o In case the SILC Events are done we shall create a new concept of
parent and child SilcSchedule's. When new SilcSchedule is created a
would be linked and could be accessed from any of the schedulers.
It should be possible to retrieve the parent and enumerate all children
from any of the schedulers.
-
- SilcSchedule silc_schedule_init(int max_tasks, void *app_context,
- SilcSchedule parent);
- SilcSchedule silc_schedule_get_parent(SilcSchedule schedule);
-
- o Additional scheduler changes: optimize silc_schedule_wakeup. Wakeup
- only if the scheduler is actually waiting something. If it is
- delivering tasks wakeup is not needed.
-
- o Structured log messages to Log API. Allows machine readable log
- messages. Would allow sending of any kind of data in a log message.
+ (***DONE)
o Base64 to an own API (***DONE)
o Timer API (***DONE)
- o Add builtin SOCKS and HTTP Proxy support, well the SOCKS at least.
- SILC currently supports SOCKS4 and SOCKS5 but it needs to be compiled
- in separately.
-
- o silc_stringprep to non-allocating version.
-
o silc_hash_table_replace -> silc_hash_table_set. Retain support for
silc_hash_table_replace as macro. (***DONE)
o Thread pool API. Add this to lib/silcutil/silcthread.[ch]. (***DONE)
- o Fast mutex implementation. Fast rwlock implementation. Mutex and
- rwlock implementation using atomic operations.
-
- o Compression routines are missing. The protocol supports packet
- compression thus it must be implemented. SILC Zip API must be
- defined.
-
o Add new functions to SilcStack API in lib/silcutil/silcstack.[ch]. Add
silc_stack_[set|get]_alignment. It defines the default alignment used
when allocating memory from stack. It can be used to specify special
allocation possibility. (***DONE)
o silc_stack_alloc shouldn't require multiple by 8 size argument, it
- should figure it out itself.
-
- o silc_malloc et. al. to respect --with-alignment.
-
- o Add '%@' format to silc_snprintf functions. It marks for external
- rendering function of following type:
-
- /* Snprintf rendering function. The `data' is rendered into a string
- and allocated string is returned. If NULL is returned the
- rendering is skipped and ignored. If the returned string does
- not fit to the destination buffer it may be truncated. */
- typedef char *(*SilcSnprintfRender)(void *data);
+ should figure it out itself. (***DONE)
- It can work like following:
-
- char *id_renderer(void *data)
- {
- char tmp[32];
- id_to_str(tmp, sizeof(tmp), (SilcID *)data);
- return strdup(tmp);
- }
-
- silc_snprintf(buf, sizeof(buf), "Client ID %@", id_renderer, client_id);
+ o Add '%@' format to silc_snprintf functions.
(***DONE)
o SILC Tls (Thread-local storage) API to lib/silcutil/silcthread.[ch].
o Generic SilcResult that includes all possible status and
error conditions and generic errno API. (***DONE)
+ (o Structured log messages to Log API. Allows machine readable log
+ messages. Would allow sending of any kind of data in a log message.) maybe
+
+ (o Change some stream routines (like socket stream API) to accept ANY
+ stream and use silc_stream_get_root to get the socket stream from the
+ given stream. This will make various stream APIs more easier to use
+ when user doesn't have to dig up the correct stream.
+
+ Add silc_stream_get_root and add get_root stream operation. It
+ returns the root of the stream or NULL if stream doesn't have root.) maybe
+
+ (o Compression routines are missing. The protocol supports packet
+ compression thus it must be implemented. SILC Zip API must be
+ defined.) maybe
+
(o SilcIpAddr abstraction. Ipv4 and Ipv6 support to the abstaction.)
maybe
to all send(), recv(), sendto() etc. Bad thing is that we'd have to
define all socket options, sockaddrs, etc.) maybe
+ (o Fast mutex implementation. Fast rwlock implementation. Mutex and
+ rwlock implementation using atomic operations.) not for now.
+
(o mmap) maybe
All PKCS routines should now take callbacks as argument and they should
be delivered to SilcPKCSObject and SilcPKCSAlgorithm too. (***DONE)
+ o The asynchronous functions to perhaps to _async to preserve backwards
+ compatibility with synchronous versions, and make easier to migrate
+ from 1.1 to 1.2.
+
o Change PKCS Algorithm API to take SilcPKCSAlgorithm as argument to
encrypt, decrypt, sign and verify functions. We may need to for exmaple
check the alg->hash, supported hash functions. Maybe deliver it also
const char *option; /* Option name */
const char *display_name; /* Option displayable name */
SilcParamType type; /* Option data format */
+ void *default_value; /* Option's default value */
+ SilcUInt32 default_value_len; /* Default value length */
} *SilcAcceleratorOption;
For software accelerator it could be for example:
- { "min_threads", "Minimum threads", SILC_PARAM_UINT32 },
- { "max_threads", "Maximum threads", SILC_PARAM_UINT32 },
-
- The accelerator itself doesn't have to use the option structure to
- parse the options if not wanted. It is defined for the caller so
- they can learn the supported options in a well defined way.
+ { "min_threads", "Minimum threads", SILC_PARAM_UINT32, (void *)2, 4 },
+ { "max_threads", "Maximum threads", SILC_PARAM_UINT32, (void *)4, 4 },
o Diffie-Hellman acceleration