[Freedos-kernel] unused SFT fields <-> f_nodes not needed???
Hi, I tried to check SFT compatibility of FreeDOS, quick conclusion: sft_dcb is never accessed sft_stclust is never accessed sft_relclust is never accessed sft_cuclust is never accessed sft_dirdlust (sic!) is never accessed sft_diridx is never accessed sft_bshare is never accessed sft_ifsptr is never accessed (nor initialized to 0?) Is that correct? I think SFT-messing programs like Windoze will not be happy in particular about all those uninitialized cluster values, the missing DCB pointer, and missing dir entry info. The share / ifs stuff is probably less interesting or set by SHARE / IFSdrivers directly, without kernel interaction. Each SFT uses some header with size info and link pointer, and tools like FILES.COM or Windoze will just search for the last SFT and add extra SFTs - how will FreeDOS react? I think this will create SFT slots for which no fnodes exist. Next point are the fnodes themselves: f_count, f_mode, f_flags, f_diroff, f_dirstart, f_offset, f_cluster and f_cluster_offset all seem to have exact equivalents in the SFT slot structure. Am I misunderstanding something here or could we just throw away half of the f_node fields by using the SFT slot fields instead??? There would be still some remaining f_node fields, but they would be not much more than a copy of the raw directory image data (f_dir) and a pointer to the DPB for the file (f_dpb). I must be misunderstanding something here - if removing f_nodes would be so easy (in terms of: replace fields by very equivalent SFT fields), then why did we have that big project with "near fnodes" instead of just throwing away the fnodes altogether? So please tell me where the big hidden caveat is lurking. Thanks for reading this maso mail ;-). Eric PS: If a DCB and a DPB are the same (?), the only left over f_node purpose would be holding a copy of the raw directory entry of the file. That could be guarded by something like storing a checksum of the starting cluster and filename in the fnode, and re-read the directory entry if the SFT slot has changed unexpectedly (a warning could be shown if the SFT slot has changed unexpectedly when FreeDOS would like to write back the directory entry to disk). PPS: A few bits of f_flags might differ from sft_flags bits. [This mail is based on browsing the SF.net 2035 sources, no CVS updates...] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] unused SFT fields <-> f_nodes not needed???
Hi, Eric Auer wrote: Hi, I tried to check SFT compatibility of FreeDOS, quick conclusion: sft_dcb is never accessed sft_stclust is never accessed sft_relclust is never accessed sft_cuclust is never accessed sft_dirdlust (sic!) is never accessed sft_diridx is never accessed sft_bshare is never accessed sft_ifsptr is never accessed (nor initialized to 0?) Before 2k I was going to move the fnode stuff over to stf. I got sick and forgot most of the things I intended to do to help move FD out of the stone age DOS (v2.xx) to something like M$'ish DOS. To this day I still do not remember. All I have was notes and print outs with writings. It went something like this, Phase I, integrate redirection support. Phase II, implement a simple himem and UMB support. Phase III, fix sft tables and code. Is that correct? I think SFT-messing programs like Windoze will not be happy in particular about all those uninitialized cluster values, the missing DCB pointer, and missing dir entry info. The share / ifs stuff is probably less interesting or set by SHARE / IFSdrivers directly, without kernel interaction. Each SFT uses some header with size info and link pointer, and tools like FILES.COM or Windoze will just search for the last SFT and add extra SFTs - how will FreeDOS react? I think this will create SFT slots for which no fnodes exist. It would be better to go full SFT and not worry about fnodes. Next point are the fnodes themselves: f_count, f_mode, f_flags, f_diroff, f_dirstart, f_offset, f_cluster and f_cluster_offset all seem to have exact equivalents in the SFT slot structure. Am I misunderstanding something here or could we just throw away half of the f_node fields by using the SFT slot fields instead??? ,,,same thing here too. There would be still some remaining f_node fields, but they would be not much more than a copy of the raw directory image data (f_dir) and a pointer to the DPB for the file (f_dpb). I must be misunderstanding something here - if removing f_nodes would be so easy (in terms of: replace fields by very equivalent SFT fields), then why did we have that big project with "near fnodes" instead of just throwing away the fnodes altogether? Good question! So please tell me where the big hidden caveat is lurking. Thanks for reading this maso mail ;-). Eric W/O going into great detail, it does look like you'r on the right track. PS: If a DCB and a DPB are the same (?), the only left over f_node purpose would be holding a copy of the raw directory entry of the file. That could be guarded by something like storing a checksum of the starting cluster and filename in the fnode, and re-read the directory entry if the SFT slot has changed unexpectedly (a warning could be shown if the SFT slot has changed unexpectedly when FreeDOS would like to write back the directory entry to disk). PPS: A few bits of f_flags might differ from sft_flags bits. [This mail is based on browsing the SF.net 2035 sources, no CVS updates...] Start rewriting! Good Luck, James --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] unused SFT fields <-> f_nodes not needed???
Hi Eric, > Is that correct? I think SFT-messing programs like Windoze will not be > happy in particular about all those uninitialized cluster values, the > missing DCB pointer, and missing dir entry info. The share / ifs stuff > is probably less interesting or set by SHARE / IFSdrivers directly, > without kernel interaction. True, perhaps. I don't think Windows XP will fiddle much with SFTs though, except in NTVDM... ;) > Next point are the fnodes themselves: > f_count, f_mode, f_flags, f_diroff, f_dirstart, f_offset, f_cluster > and f_cluster_offset all seem to have exact equivalents in the SFT > slot structure. Am I misunderstanding something here or could we just > throw away half of the f_node fields by using the SFT slot fields > instead??? We could, but I don't think it's a good idea. Working directly with SFTs means bloating the code since these are "far" and not "near". The *far* fnodes can be eliminated and their purpose can be replaced by SFTs. Basically the fmemcpy() that is called in save_far_f_node() and xlt_fd() could be replaced by a function that copies things from or to the SFT for the fnode. Then all the basic functions (dos_mkdir etc) in fat*.c can remain unchanged. That way the two near fnodes become a purely internal FreeDOS kernel implementation detail within fatfs/fatdir.c; the permanent fnodes are gone. I mentioned this before; then Tom replied http://www.mail-archive.com/[EMAIL PROTECTED]/msg00493.html so we have the far fnodes in the HMA now and the rest is "planned to do for an unspecified date". In retrospect the near/far fnode change was a big step into this direction (seperating internal/external representation), it doesn't conflict with it! Bart --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
