Hello Martin, My current task is a implementation of UDF 1.02. Level of restrictions - 1. Read-only. I am doing my project step by step. It means that after I have finished read some part of docs I try to implement it in code. Udf has very «lovely docs» and sometimes I have to check it in code to be sure of my opinion about format file system. It is why I can't separate the reading docs and coding. My timeline is a little different than Google's schedule.
As part of my proposal I have done reading volume recognition sequence and anchor volume descriptor pointer for implementation of mount function. It is my point of start. My first big work it is a OSTA functions fo udf. Papers contain the code but it is was far from HelenOS style. I have done it compliant with my udf server in HelenOS code style. Also I added all descriptors which needed for working with volume. The second part it is the reading of volume descriptor sequence. It could contain primary volume descriptors, logical volume descriptors and partition descriptors. As each of these descriptors could be rewrited, on this step is necessary to use prevailing rules for saving only actual descriptors (according to ecma 167 3/8.4.3). Now I have information about volumes, logical volumes and partitions. So I can start search for root directory. Each logical volume descriptor can direct to fileset descriptor which contain direction to root directory. My next commit will be provide of reading root directory. When I can do it I will be able to read file of names. Julia 2012/5/21 Martin Decky <[email protected]>: > Hello Julia, > > I have noticed that there has been quite a lot of activity in your UDF > branch in the last few days (and even before, during the bonding period). > > I am really looking forward to your first weekly status update. As it seems > that you have already implemented something, would you please also elaborate > on your near-future plans (in more detail than in the original proposal)? > > Finally, I suggest that you merge frequently upstream changes (i.e. from our > mainline branch) into your branch. There might be important bug fixes in the > mainline and merging often with the upstream is usually less complicated and > time-consuming than having to solve a huge heap of conflicts when merging > infrequently and dealing with diverged branches. > > You really should merge now and keep a reasonable merging schedule > afterwards (e.g. merging each week before writing the status report). > Certainly there might be times when merging is not a good idea (e.g. when > there is some breakage in the mainline), but this should be an exceptional > case. Thanks! > > > M.D. > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
