Hi Taylor. Dne 6. dubna 2012 17:35 Taylor Killian <tay...@taylorkillian.com> napsal(a): >> Probably, an opposite function - convert format to the struct - would >> be more useful. The scenario I have in mind is that the developer >> first wants to get a feel for the thing and just browses (more or >> less) manually existing data and afterwards, starts coding. > > I'm not sure what you mean by "manually existing data". Do you mean, > for example, using the library to view data on a UDF partition, and > how it is structured. Then coding? That is definitely a goal of mine > for this project, however I will not be able to define every format a Sorry that I did not express myself more clearly. The scenario I meant was: developer would like to implement an ext2 FS service. The approach could be: read documentation of ext2 and code it :-). But there would be definitely parts where the developer would not be completely sure how the data structures are organized.
One approach is to start hacking until it works. Other way is to write their description in our editor's language and view some disk image. If the data looks wrong, the developer would just change the description and would not need to code anything. Once he got the structures right, he could generate the structs and then code the logic. For example, when we were implementing USB HID drivers, something similar would be very useful to us because we spent a lot of time manually decoding HID descriptors (the specification was without real-world examples useless). Similar case is USB configuration descriptor with appended interface and endpoint descriptors. - Vojta > developer might want during the scope of this summer. My hope is to > provide a framework, so that adding a UDF or USB or TCP descriptor > will be a simple task. > > >> For the timeline: I would appreciate if the advanced functionality >> would appear earlier. For example, without the variable-length >> structures or dynamic offsets (e.g. first byte specifies where the >> data starts) it editor would be just a little bit smarter hex viewer. > > Thanks for that, looking over my proposal, I realized that my > priorities were a little out of order. I have moved complex structure > handling from week 9 to week 3/4. Also, as for selecting the first by > for where the data starts, that is a subgoal of week 4, when the > interface is first created. Later, in week 8, that goal refers to > being able to type in a byte address and have the library identify > which field and structure it belongs to. > > Also, I realized that some of my goals could probably be compacted, so > that I am working on multiple goals in a week, rather than a single > goal. The updated timeline reflects this. I have also included 2 weeks > for testing the library on various different structures in order to > verify the library will be able to handle complex structures in real > world applications. If anybody has a unique complex structure used in > the real world that they would specifically like this library to read, > please let me know about it so I can test the library on it. Right now > my tests will deal with the FAT filesystem, UDF filesystem, and USB. > >> >> That is for my first impression. I may add more comments later. >> > > Thanks again for the input. > > Taylor > > _______________________________________________ > HelenOS-devel mailing list > HelenOS-devel@lists.modry.cz > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list HelenOS-devel@lists.modry.cz http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
