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
