| 3 | | I would suggest to create a library that would: |
| 4 | | * define data structures (and API to manipulate them) to describe types (basic types, arrays, structs, unions) |
| 5 | | * enumerate fields |
| 6 | | * compute field offset (address) |
| 7 | | * read and write fields |
| 8 | | * convert between binary and textual representation |
| 9 | | * find targets of links |
| | 3 | Details:: |
| | 4 | The implementation should primarily consist of a versatile library that would provide: |
| | 5 | * An API to dynamically (at run-time) define and manipulate data structures (data schemas) comprising of typical basic and compound data types (integers, arrays, structs, unions, pointers) |
| | 6 | * An API to enumerate the members of such data structures |
| | 7 | * An API to compute field offsets (addresses) |
| | 8 | * An API to read and write values of the members and traverse complex data structures using pointers (with custom pointer resolution routines) |
| | 9 | * A parser which would provide a way how to define the data structures (data schemas) in a textual representation (XML-based description, C-like type declaration or a DSL) |
| | 10 | * A generator which would output the data structure definition in the textual representation which the library can parse again. |
| | 11 | * Support for custom memory back-ends using code plugins (file, task memory [using udebug], block device) |
| 11 | | The type definitions would be defined by plugins: |
| 12 | | * plugin for reading DWARF data |
| 13 | | * plugin for reading textual definitions |
| 14 | | * plugin for specific set of types (e.g. ext2) |
| | 13 | The implementation should also contain a readily available definitions for common data structures (either as code plugins or in the form of textural representation), e.g.: |
| | 14 | * ubiquitous data structures (doubly-linked link lists, hash tables, etc.) |
| | 15 | * ELF file format (with DWARF data) |
| | 16 | * FAT file system structures |
| | 17 | * ext2 file system structures |
| 23 | | On top of this library we can provide tools such as an interactive or command-based browser/editor. It could be also used as part of a debugger and possibly for other debugging purposes. |
| | 24 | As the implementation of the library and to a major extend also the implementation of the end-user interactive editor can be done in standard-compliant C with little to no HelenOS-specific code, it can be also usable in other operating systems. |
| | 25 | |
| | 26 | Difficulty:: |
| | 27 | Medium |
| | 28 | |
| | 29 | Required skills:: |
| | 30 | A successful applicant will have good skills of programming in the C language and experience with designing reusable and extendable libraries with decent internal structure and public API. For the end-user interactive editor the ability to learn and use HelenOS-specific console manipulation routines is also expected. |
| | 31 | |
| | 32 | Documentation:: |
| | 33 | |
| | 34 | * Compact Type Format (compact kernel debugging information used by MDB for Solaris) |
| | 35 | |
| | 36 | Possible mentors:: |
| | 37 | HelenOS Core Team, Martin Decky |
