Difference between revisions of "30C3"
Jump to navigation
Jump to search
| Line 22: | Line 22: | ||
** VMs with connected hardware (bert and uwe)? | ** VMs with connected hardware (bert and uwe)? | ||
* Malloc | * Malloc | ||
** Decide whether to continue trying to handle malloc failures in libsigrok. These code paths are never tested, would never be executed anyway due to the realities of virtual memory systems [0], and we could never get this right | ** Decide whether to continue trying to handle malloc failures in libsigrok. These code paths are never tested, would never be executed anyway due to the realities of virtual memory systems [0], and we could never get this all even close to being done right because of the extensive use of glib [1]. So what is the use case we are actually targeting here? | ||
====== Notes ====== | ====== Notes ====== | ||
# Linux/glibc malloc() fails only when it runs out of address space; you'll get OOM killed long before malloc() fails. | # Linux/glibc malloc() fails only when it runs out of address space; you'll get OOM killed long before malloc() fails. | ||
# Although glib offers g_try_malloc() which returns NULL on failure, all glib functions that allocate memory internally use g_malloc(), which calls abort() on failure. This is not considered a glib bug and will never be fixed. In many cases it couldn't even be fixed, without fundamental changes to the glib API, which lacks any mechanisms to signal malloc failure except for the simple g_try_malloc() case. | # Although glib offers g_try_malloc() which returns NULL on failure, all glib functions that allocate memory internally use g_malloc(), which calls abort() on failure. This is not considered a glib bug and will never be fixed. In many cases it couldn't even be fixed, without fundamental changes to the glib API, which lacks any mechanisms to signal malloc failure except for the simple g_try_malloc() case. | ||
Revision as of 10:28, 4 December 2013
We're getting together at the annual CCC conference, 30C3, for a sigrok hackathon. In addition to the usual "whatever we feel like hacking on", we also have several architectural decision to make, and doing this in person is a lot easier. If you want to be part of the conversation and decision-making process, show up!
In addition to the 4 days of the congress, we will also get together the day before (26 December 2013) for a hopefully less crowded and more productive day. Venue is not yet decided.
What's decided here is what goes.
- New sigrok file format
- Improved Configuration Enumeration
- To sr_filter_probes() or not, that is the question.
- frontends have probe location info, they pass it to sr_filter_probes() after all
- very nice for output modules: avoids having to map probe location to bit on all the modules
- waste of time for PV, which will soon do its own reformatting of logic data anyway
- SRD currently needs it, but has a probe mapping mechanism already, so can be adapted
- Rethinking how we enumerate and assign drivers to hardware
- Pre-scan for all resources such as serial ports & USB devices
- How users/frontends resolve ambiguity
- How to handle "gateway" devices such as GPIB adapters, networked servers with instruments, etc.
- Device tree model?
- Testing
- automated unit tests on commit (SR and SRD)
- VMs for *BSD, linux dists on kiutl for automated build/unit tests
- VMs with connected hardware (bert and uwe)?
- Malloc
- Decide whether to continue trying to handle malloc failures in libsigrok. These code paths are never tested, would never be executed anyway due to the realities of virtual memory systems [0], and we could never get this all even close to being done right because of the extensive use of glib [1]. So what is the use case we are actually targeting here?
Notes
- Linux/glibc malloc() fails only when it runs out of address space; you'll get OOM killed long before malloc() fails.
- Although glib offers g_try_malloc() which returns NULL on failure, all glib functions that allocate memory internally use g_malloc(), which calls abort() on failure. This is not considered a glib bug and will never be fixed. In many cases it couldn't even be fixed, without fundamental changes to the glib API, which lacks any mechanisms to signal malloc failure except for the simple g_try_malloc() case.