Hi, Vojtech, > > will be limited to literals (8) or references to previous fields (.len), > > but more complicated expressions could be added. Users could also add > My recommendation is to leave the complex expressions alone and > implement them only if time allows. Usually, the length is directly > stored inside another field anyway. I expect that once you implement > the bitmap parsing, it would not be a problem if this length would be > actually part of a bitfield.
Agreed, I won't work on complex expressions until the need is clear. > >> Skip some data. Either of fixed length (e.g. to skip unknown USB > >> descriptors) or until some pattern is found (e.g. parts of GIF > >> header). > > > > These could be done with a combination of parameters (for known_length > > or similar), the "hidden fields" idea, and the "search" idea. > Nice :-). The "hidden field" is a nice feature but definitely not a > "must have" one. Agreed. > >> Accessing the parsed data at run-time. Currently, you are able to > >> print the data but I found no way to actually work with them. For > >> example, how would I read the latitude from your example once the > >> structure is parsed? This is a very important feature if we want to > >> use Bithenge as a basis for other tools, such as debugger. Optimal > >> solution would be to parse the data into a native C struct. Question > >> is how to populate it. Generate a setter of some kind from the > >> grammar, use some weird macros, ... > > > > The primary way of accessing the data is to use the functions in tree.h > > to access the output tree. As you mention, I will need to add a method > > to get a specific child of an internal node. This way is more flexible > > because the script can be chosen at runtime, so it would be used for a > > debugger or interactive browser. > Ok. > > > > > Another way would be to parse the script file and create C source code > > that declares structs and reads data. This would be an alternative to > > writing the C code directly when you need to parse binary data in > > HelenOS. I didn't include this in my GSoC plan because it wouldn't help > > with the debugger or interactive browser. > I still think that it would be a nice feature to translate the parsed > data into a C struct with which you can work "natively". And I think > that for simple structures with fixed format (i.e. no repetitions, > conditionals..) it should be rather simply to implement it. I'm not sure exactly what you're suggesting. I see two possibilities: - At compile time, you have no idea what formats the program should work with; for instance, with the interactive browser. The program needs to use the tree API (which I will extend). There's no reasonable way to parse into a C struct because you didn't know what the format would look like at compile time. - At compile time, you know which formats the program should work with. This could be handled by a separate program to generate C code from Bithenge scripts. > > I'll try to work a little, but this is still a good point. In my > > proposal, I planned to make these things by the GSoC deadline: > > > > - An interactive browser (7 days) > > > > - A simple DWARF implementation to browse other tasks' memory (9 days) > > > > - Editing support, including interactive editing (11 days) > > > > I think I could do these, but with very limited functionality. For > > instance, the editing support might only work with simple integers and > > booleans. I propose not working on editing yet, and maybe not DWARF > > either; instead, I could improve the language and spend more time > > working on the interactive browser. Of course, the plan could be changed > > later if necessary. What is your preference? > My preference depends which functionality you plan to implement into > these "interactive" tools. From my point of view, I do not care about > eye-candy stuff and I would be happy with command-line tools. > > For me, important functionality of the browser is search (e.g. file > system node where .filename is hello.c) and scalability (i.e. > reasonable performance when iterating over huge inputs). I was only thinking of implementing basic browsing, and in fact I think it should take less than 7 days. > For the editing support, I would say that having C API is a minimum. > It should allow following actions: > * edit primitive values > * add/delete from repetitions > * add/delete optional structs (aka conditional transforms) > Obviously, it must be possible to write the changes back and the > changes must be checked to be valid according to the grammar. If you > would built some command-line editor above this it would be nice. Editing primitive values is fine, but the other two are more difficult. If Bithenge knows the length of a repetition based on a parameter originating from a length field, how does it know to change the length field? If there are pointers in the file, how does Bithenge know to change them? Nontrivial editing seems so open-ended that I think it should be left until after GSoC. > Regarding the DWARF support - I do not know the format well and I do > not know whether it is possible to implement core functionality only > first and extend later. What I would like to see in the end is a You can take a look at the DWARF info in a file with readelf -w <filename>. I think DWARF support is possible, but it might take 2+ weeks to reach a usable state. > Bithenge script that describes some relatively complex and real-world > data structure. It ought to prove that Bithenge works and is able to > work with realistic formats. > > In your timeline, you mentioned FAT format but it can be something > else as well. Ideally something that would demonstrate all > capabilities of your implementation. If that is not possible with > single format, using several simpler ones is possible as well, of > course. For example, TCP frames, call stacks or USB transaction > frames. Another useful example is exploring another task's memory - > e.g. crawling through some linked list when pointed to its head. I still think FAT is a good goal because it needs a variety of different features to decode fully. TCP frames could be a good intermediate goal. > I think you can now concentrate on the repetitions, bitfields etc. and > meanwhile, the rest (browser, editor, DWARF) could be discussed in > more detail. I'll send a new update tomorrow with a plan for the next few weeks. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
