[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
File System
- Date: Tue, 10 Aug 1999 10:10:36 -0500 (CDT)
- From: joel at OARcorp.com (joel at OARcorp.com)
- Subject: File System
Ralf is the best source for file placement but the general idea is to
place your incluee files in the source tree in the same layout they will
be at the install point. This is by GNU conventions.
On Tue, 10 Aug 1999, Peter Shoebridge wrote:
> I finally got a clean build last night of the latest snapshot and
> started looking at how to integrate the file system drivers I have.
YEAH!!!
Are they "filesystem drivers" or simply "filesystems"?
Once we get the "simple" case (no caching or disk scheduling) working, I
would like to talk about making adding caching and scheduling layers. I
would at least like to have empty layers that say "it is not in the cache"
and a FIFO disk scheduler.
The good news is that my dissertation was on real-time disk caching and
disk scheduling. I have a vision in my head of a layered IO system in
which filesystem, cache algorithm, and scheduling algorithm are
selectable. I have a file system simulator in C++ which lets you evaluate
combinations of the algorithms in the file system layercake. This
simulator includes implemenations of my new algorithms and all the
classics. Here is a list of caching algorithms I implemented in the
simulator:
+ No Cache
+ FIFO Cache
+ LRU Cache
+ Priority LRU Cache
+ Fair Share Cache
+ Priority LRU Cache with Priority Inheritance
+ Fair Share Cache with Priority Inheritance
Here is a list of scheduling algorithms in the simulator:
+ FIFO Scheduler
+ SSTF Scheduler
+ CScan Scheduler
+ NStep CScan Scheduler
+ Scan Scheduler
+ NStep Scan Scheduler
+ Priority Scheduler
+ Priority Scan Scheduler
+ Priority CScan Scheduler
+ Priority NStep Scan Scheduler
+ Fair Share Scheduler
+ Preemptive Priority NStep Scan Scheduler
+ Preemptive Fair Share Scheduler
I do not think these implementations are directly useable without
addressing the class layering from the simulator is uses. More than
likely, we will just have to use it as a reference source for the
algorithms.
Sorry... I got excited. :)
> I have some questions on the layout of files.
Very reasonable.
> I propose at directory libfs under the lib tree with directories for
> each file system under that (e.g. cdfs, fatfs etc), sound ok?
Unless each filesystem has a lot of files, I doubt the second directory
level is necessary.
libfs/
include/
src/
OR
libfs/
include/
include/XXX/
cdfs/
...
wrapup/
Under the current scheme, you do need to end up with a libfs.a which is
listed in lib/wrapup/Makefile.in.
> Next, where would I put common files to those libs (i.e. libcdfs.a,
> libfatfs.a etc.)? Would I have an include directory under the libfs?
> How do they get copied across to the build tree?
See c/src/exec/score/include for an example.
> Any other tips/recomendations regarding file layout??
That's about it from me. :)
--joel
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
- References:
- File System
- From: peter at zeecube.com (Peter Shoebridge)