eg. Read from files on the disk, and make ones...etc.
I haven't seen any tuts on this subject, and I think that this is quite
an important subject.
What is an OS with out files?
thnx alot,
--=[KaoZ]=--
Files
-
markus
you need a filemanager!!!! - there are many tutorials for it
you need a filemanager for your OS!
Thats realy not SIMPLE!
whats an OS without an FILEMANGAER? not realy an OS!
A Filemanager is very important for an OS!
greets markus
Thats realy not SIMPLE!
whats an OS without an FILEMANGAER? not realy an OS!
A Filemanager is very important for an OS!
greets markus
-
jamethiel
RE:you need a filemanager!!!! - there are many tutorials for
With all due respect, an OS without a file system interface can be quite usable.
My OS, as of last night, is capable of recompiling itself from source, but doesn't have a file system interface yet. All my current OS development is hosted on a system without a file system. I may add a file system, but it would mainly be for data and possibly application source, but probably not the system source and base applications for quite a while to come.
With a persistant object store, you write your filesystem solely in terms of objects, without reference to on-disk structures, and rely on the persistant object store to keep everything straight. As an added bonus, the filesystem doesn't need checking after an unexpected shutdown because persistant object stores are designed to do atomic updates every so often.
Oh, and a disk-based filemanager can be quite simple if you discard the UNIX/C bag-o-bytes metaphor for file access and go for a more unusual approach. The people writing Exo-kernel based systems take advantage of this, for example.
I fully intend to implement files as a bag of 1024-byte blocks. Or maybe 4096-byte blocks, that way I might be able to use the MMU to provide memory-mapped files, which would make the interface -far- simpler... (yes, I am considering having memory-mapped files be the -only- filesystem access).
My OS, as of last night, is capable of recompiling itself from source, but doesn't have a file system interface yet. All my current OS development is hosted on a system without a file system. I may add a file system, but it would mainly be for data and possibly application source, but probably not the system source and base applications for quite a while to come.
With a persistant object store, you write your filesystem solely in terms of objects, without reference to on-disk structures, and rely on the persistant object store to keep everything straight. As an added bonus, the filesystem doesn't need checking after an unexpected shutdown because persistant object stores are designed to do atomic updates every so often.
Oh, and a disk-based filemanager can be quite simple if you discard the UNIX/C bag-o-bytes metaphor for file access and go for a more unusual approach. The people writing Exo-kernel based systems take advantage of this, for example.
I fully intend to implement files as a bag of 1024-byte blocks. Or maybe 4096-byte blocks, that way I might be able to use the MMU to provide memory-mapped files, which would make the interface -far- simpler... (yes, I am considering having memory-mapped files be the -only- filesystem access).
-
jordanpwalsh
RE:you need a filemanager!!!! - there are many tutorials for
just have your self a little 64k ramdisk and when the os shuts down have it write the contents to disk... when it starts up read it back.. there will really be no order at all but it will appear there is.
-
jamethiel
I see no filemanager here.
That's almost what I'm doing.
I have a 360k blockfile loaded from tracks 2 - 21 of a 1.44 meg disk on startup (the startup image is on the first track). There is a special command to write it back down to disk. I just access each block by number, no file system or anything. If I wanted to, I could expand it to take up the rest of the disk, but that would increase the bootup time proportionately.
I have a 360k blockfile loaded from tracks 2 - 21 of a 1.44 meg disk on startup (the startup image is on the first track). There is a special command to write it back down to disk. I just access each block by number, no file system or anything. If I wanted to, I could expand it to take up the rest of the disk, but that would increase the bootup time proportionately.