The f_nodes structure is a leftover from the original family of DOS API compatible RTOS that the kernel is derived from. Those operating systems used the f_nodes structure for file system switches and as locking objects for fine grain locking necessary in an RTOS. You don't need them.
Pat
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?)
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
------------------------------------------------------- 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
