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
