Hi, Tom is completely right: > in this case, removing 'break;' may have saved 5 bytes in the early > 90ties, but is irrelevant (or even contraproductive) with optimizing > compilers, and leads only to such irrelevant 'why was this changed' > threads.
I have accepted that it is a passion of Arkady (and Lucho) to shrink the kernel byte for byte. Normally I only intervene if I notice that a patch really hurts readability of the code, or if I get the impression that the SEMANTICS of the code change in some destabilizing way. And of course in cases where I cannot resist to comment. But even if it was not clear from my mail: It is true that multi-kilobyte discussions about saving 6 bytes are not worth the effort. If you REALLY want to change the FreeDOS kernel in an impressive way, then remove that far f_nodes. This will improve compatibility, size, and (maybe not at once, but it still) stability. > IMHO if you really want to save space for embedded stuff you should > selectively remove features (e.g. FAT12 or FAT32, LBA, FCB stuff, > whatever). Other examples, partially inspired by Tyler: Simplify config sys parsing, remove most of the country support, maybe in some cases even UMB or HMA handling. FAT32 support already is a compile time option. Talking about Tyler, a SYS without the verbose output and without the SYS CONFIG part can probably be a lot smaller - that would allow to keep one floppy distros "fertile" which would otherwise have no space for SYS ;-). On the other hand, some things are still missing: 5d01h Commit All Files active 3.10 planned 5d02h Close File by Name active 3.10 planned 5d03h Close All Files for Computer active 3.10 planned 5d04h Close All Files for Process active 3.10 planned 5d05h Get Open File List active 3.10 planned 5d0ah Set Extended Error active 4.00 planned The latter is implemented in a short and nice patch by Jason for DOSLFN. Some details about FAR f_node removal: The NEAR f_nodes are only used while InDOS, so it does not hurt to keep them for the moment. The f_dpb field of the struct f_node is the same as the dcb field of a SFT entry. Actually the whole f_node consists of a copy of the directort entry of the file and some values which are - for 2035 - all very closely related to existing SFT fields. http://cvs.sourceforge.net/viewcvs.py/freedos/kernel/hdr/sft.h?rev=1.13&view=markup http://cvs.sourceforge.net/viewcvs.py/freedos/kernel/hdr/fnode.h?rev=1.20&view=markup The f_droot, f_dnew and f_ddir fields are unused, F_DNEW already got removed in 2035, so there are only f_dmod, F_DMOD, F_DDIR and F_DDATE to be handled. You have to be a bit careful with f_flags and f_mode I guess. The f_count, f_mode and f_flags values only use the low byte AFAIR. Direct access to FAR f_nodes only happens in lfn_allocate_inode (which is also the only place where RESERVED_FNODES is handled) and more importantly in merge_file_changes. The merge_file_changes function could be implemented as a loop over SFT entries which converts one entry after another to a near f_node and calling copy_file_changes, does the merge stuff. Not 100% efficient but good enough. There is also config_init_fnodes, but that only allocates memory. The REAL deal with FAR f_nodes happens in xlt_fd, save_far_f_node and maybe in get_near_f_node, get_f_node and release_f_node: If you replace those functions by "convert SFT entry to/from NEAR f_node" functions, you can drop FAT f_nodes altogether (after removing the few abovementioned direct-access-to-FAR-f_nodes (oops, did I write FAT? ;-)) cases in merge_file_changes etc., of course). Eric PS: Removing FAR f_nodes will not remove kernel size on disk that much, but embedded systems will still be happy about the reduced RAM footprint and things will be easier to maintain, improve, and (also nice for embedded systems) it might become easier to create stripped down kernels and non-FAT kernels. If that did not convince you, then maybe it helps to add that FAR f_nodes are a real pain for "undocumented DOS" compatibility and for non-FreeDOS kernel- programmers in general IMHO. ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
