Hi Bart, > well, at the time of setting up SVN I asked Jim if he could > set up sourceforge so the patches to go to the existing > freedos-cvs mailing list (where CVS commits were sent)
I do not know how many people read that list, but my suggestion was more to talk about the code rather than reading it :-). After all, I can read the SVN commit list and diffs easily via the web interface or my SVN client, but this does not tell me what the code changes mean and what the background of their design is ;-). > Anyone with admin rights, Aitor? Jim? Pat? you can do this on SF: > click "Project Admin" > click "Feature Settings" > click "manage" next to "Subversion" > add an svnnotify hook, and type [email protected] > as the email address. Sourceforge.net seems to have problems at the moment but it seems that Aitor and Pat are indeed the people to ask :-). > * there are only two near fnodes, and almost all operations use the > first fnode, fnode[0] except for dos_rename(), which also uses > fnode[1] I remember part of that, and I think it is a good idea that you now hardcode the 0 / 1 index now instead of the old alloc scheme. Actually by making dos_rename the first f-node-free implementation you could already get down to a single global f-node :-). > * file state is only kept in SFTs: > an open/creat uses fnode[0], then copies the state to an SFT > a read/write copies state from the SFT to fnode[0], does its work on > fnode[0], then copies back to the SFT. > a close copies from the SFT to fnode[0], and closes the file. F-nodes largely overlap SFT afair, but also have the dir entry (relevant for performance?). Looking at your changes, it seems you move towards dynamic transformations between SFT and F-Node shape of the data, to make F-Nodes more "virtual" and get them closer to being abandoned. Certainly not trivial :-). > * For FAT16 kernels, the SFT layout is documented in RBIL > * For FAT32 kernels, the SFT layout follows that of MSDOS 7.10 > (not documented in RBIL). Documented in MSDN then? Could this cause significant classic DOS app / driver incompatibilities when using FAT32 kernels? > * the share support also needed some changes, because it needs to walk > the SFTs instead of the far fnodes to merge changes. That sounds really interesting. Does it mean we need FreeDOS specific SHARE now and will be able to use "any DOS" SHARE in the future? Note that our SHARE could use tuning to reduce the memory footprint (or rewrite in ASM?) and that people have made patched versions (Japheth?) for compatibility reasons... >> Otherwise I >> would ask why r1416 rmdir drops the 00/eof check (does it?) >> and why r1397 drops the dos_commit-only way of close(?) and >> how get_f_nodes_cnt works, among other things... > r1416: > Look at what dir_read(fnp)==1 means in fatdir.c... You mean it already implies end of directory? > r1397: > dos_commit was no longer necessary: a commit (int21/ah=68,6a), in > DosCloseSft() just calls dos_close() without closing the SFT. Still do not get it, but I assume you know what you are doing :-) > get_f_nodes_cnt() was an intermediate function that no longer exists > (to keep individual changes small) > It just walked the SFT chain and computed the FILES= value. Strange, seems to be meant the other way round: The user sets FILES and then the SFT uses the available number of handles, with the JFT of each task saying which SFT items are in use? Eric :-) ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Freedos-kernel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
