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 >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 > ------------------------------------------------------- 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
