From: JB K. <jbr...@gm...> - 2010-04-10 18:13:34
|
Hi Been going through sigrok source code. It's really well written! It looks like the hwplugins are not runtime loadable, since I see in hwplugin.c: extern struct device_plugin saleae_logic_plugin_info; extern struct device_plugin ols_plugin_info; extern struct device_plugin zeroplus_logic_cube_plugin_info; int load_hwplugins(void) { plugins = g_slist_append(plugins, (gpointer *)&saleae_logic_plugin_info); plugins = g_slist_append(plugins, (gpointer *)&ols_plugin_info); plugins = g_slist_append(plugins, (gpointer *)&zeroplus_logic_cube_plugin_info); return SIGROK_OK; } I got the impression that each plugin would be compiled as its own shared lib and its symbol get imported and device_plugin struct initialized during runtime. Is this something planned for the future? Also, what is the reason for removing dependency on glib? Just curious. The ganglia project has it's own simple linked list implementation, has heavy dependency on libapr, and has runtime loadable module concept, akin to some of the implementation details used in sigrok. Perhaps it might be a good reference: http://sourceforge.net/projects/ganglia/ |
From: Bert V. <be...@bi...> - 2010-04-10 19:30:39
|
JB Kim wrote: > Hi > > Been going through sigrok source code. It's really well written! Thanks! > I got the impression that each plugin would be compiled as its own shared > lib and its symbol get imported and device_plugin struct initialized > during runtime. Is this something planned for the future? The hardware drivers actually used to be shared libs dynamically loaded at runtime, but they were recently changed to linked-in objects. As you noticed, they still sort of look like typical DL plugins. There really wasn't a very good reason to have them dynamically loaded, and what we want to avoid at all costs is people releasing binary-only drivers for hardware to work in sigrok. Indeed, opening up the proprietary/closed protocols and hardware is one of sigrok's specific goals. By linking the drivers into libsigrok as a whole, we make this a non-issue. > Also, what is the reason for removing dependency on glib? Just curious. Mostly that it's an extra dependency, and the little of glib functionality that we use (compared to the huge amount it offers) doesn't really justify having the dependency. Having said that, the windows port needs glib more than the various unix builds, because of some of the cross-platform functionality it offers. So we might keep it after all, now. -- Bert Vermeulen be...@bi... email/xmpp |
From: Peter S. <pe...@st...> - 2010-04-15 04:05:52
|
Bert Vermeulen wrote: > the windows port needs glib more than the various unix builds, > because of some of the cross-platform functionality it offers. Which features specifically? //Peter |