Re: [Freedos-kernel] unused SFT fields - f_nodes not needed???
The simple fact is that the f_nodes structure is not needed at all. Before I left the group several years ago, I was planning to rewrite the kernel specifically to eliminate f_nodes and move to SFT. The reason was precisely the incompatibility between this kernel and other programs such as windoze. 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=5588alloc_id=12065op=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=5588alloc_id=12065op=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, I don't know what an f_node is, but you have received 4 replies from: - James (former kernel maintainer) - Bart (former kernel maintainer) - Tom (former kernel maintainer) - Pat (former kernel maintainer and original kernel author) I just wanted to add myself :-)) Ciao P.S.: If you still have no clue, you are in big troubles... :-) --- 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=5588alloc_id=12065op=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???
It's the original data structure used for file systems. It was designed originally as a structure that contained a semaphore, file system type identifier, and a union for file system data. It was simplified for the original DOS-C/FreeDOS kernel, and changes have been made by myself and others to map it into the SFT, so that it now shares this role with the SFT. Pat Roberto Mariottini wrote: Hi Eric, I don't know what an f_node is, but you have received 4 replies from: - James (former kernel maintainer) - Bart (former kernel maintainer) - Tom (former kernel maintainer) - Pat (former kernel maintainer and original kernel author) I just wanted to add myself :-)) Ciao P.S.: If you still have no clue, you are in big troubles... :-) --- 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=5588alloc_id=12065op=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=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
RE: Re: [Freedos-kernel] unused SFT fields - f_nodes not needed???
Hi there, If I understood correctly all the messages (and I think that, as Bart pointed out, this discussion came time ago, and not only once), the biggest difference between f_node and SFT is the fact that SFT are far and f_node are near. So there is the problem to estimate the size of the code: - changing references to f_nodes from near to far (thus with a segment prefix) - modifying segment registers when appropriate against: - the code used to sync both structures - the amount of memory occupied by the f_nodes themselves - the unused entries of the SFT Not to speak about the big amount of work to modify all file system functions to operate with SFT's. I would say that the second set is bigger, thus it would be of benefit for the FreeDOS kernel to get rid of the f_nodes, but I am not completely sure, perhaps someone else can roughly estimate if it worths the work before Eric sets about to it. Aitor - Mensaje Original - Remitente: Pat Villani [EMAIL PROTECTED] Destinatario: [EMAIL PROTECTED] Fecha: Martes, Noviembre 2, 2004 3:00pm Asunto: Re: [Freedos-kernel] unused SFT fields - f_nodes not needed??? The simple fact is that the f_nodes structure is not needed at all. Before I left the group several years ago, I was planning to rewrite the kernel specifically to eliminate f_nodes and move to SFT. The reason was precisely the incompatibility between this kernel and other programs such as windoze. 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 slotsfor 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=5588alloc_id=12065op=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=5588alloc_id=12065op=click ___ Freedos-kernel
Re: [Freedos-kernel] unused SFT fields - f_nodes not needed???
Roberto Mariottini wrote: Hi Eric, I don't know what an f_node is, but you have received 4 replies from: John Price (former kernel maintainer) - James (former kernel maintainer) - Bart (former kernel maintainer) - Tom (former kernel maintainer) - Pat (former kernel maintainer and original kernel author) I just wanted to add myself :-)) Ciao P.S.: If you still have no clue, you are in big troubles... :-) Thanks, 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=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
RE: Re: [Freedos-kernel] unused SFT fields - f_nodes not needed???
On Tue, 2 Nov 2004 [EMAIL PROTECTED] wrote: So there is the problem to estimate the size of the code: - changing references to f_nodes from near to far (thus with a segment prefix) about 1300 bytes. It's not just segment prefixes; lots of pointers get passed around. They're really quite expensive, those far pointers. against: - the code used to sync both structures Most probably less than 1300. - the amount of memory occupied by the f_nodes themselves 120 bytes (2x60). There's also something else, the SFT is quite a clunky structure to work with: with fnodes we have total flexibility, but SFTs suffer backward compatibility hacks to store FAT32 cluster numbers (see RBIL table 1642, which doesn't even mention where Win 98 DOS stores them for the most part, but they need to be spread out over multiple WORDs). Some simple functions such as lseek don't need fnodes. But for something like open() they're quite convenient. Eric: the missing direntry items aren't a big deal: dir_write would need to be changed to do a read/modify/write instead of a simple write. The rest more or less corresponds, indeed. 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=5588alloc_id=12065op=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=5588alloc_id=12065op=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=5588alloc_id=12065op=click ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
