Index
> OS Construction > Idea for OS file system.Goto page Previous 1, 2 |
| Author |
|
|
anton 09 Apr 2004, 12:04
JohnFound wrote:
Hello. This is good idea. But I think string file names is not problem. New processors (with Ghz kernel) may process strings extrimely fast (in comparition with disks access time). There is other problem. 8-bit ASCII string coding is not optimal. Many characters cannot be used. (0-31, 128-255 and other). My idea is to use 6-bit string coding. It allow to use 64 characters: 26+26 (big and small) - latin characters, 10 - dec numbers, and underline character ( "_" ). Character with number 0 - string terminator. There is other idea to use 6-bit string coding with numbering (your idea). |
|||
09 Apr 2004, 12:04 |
|
|
anton 09 Apr 2004, 12:19
There is question for JohnFound.
How users will identify their files? By numbers? It makes their to remember file numbers. I think that is not good. |
|||
|
09 Apr 2004, 12:19 |
|
|
JohnFound 09 Apr 2004, 12:52
anton wrote: There is question for JohnFound. Of course it is not good.  And of course, there will be some simple data base with human readable names of the files. The advantage is that the programs will find it's files by number and if the human readable names are deleted, all applications will work OK.
Reagrds. |
|||
|
09 Apr 2004, 12:52 |
|
|
anton 09 Apr 2004, 13:09
Question to JohnFound.
What you think about 6-bit filename string coding. (see my previus messages)? |
|||
|
09 Apr 2004, 13:09 |
|
|
JohnFound 09 Apr 2004, 13:26
anton wrote: Question to JohnFound. Actually I think that modern OS should have unicode names. And about novadays CPU that can process strings without problems - I think that there are better tasks for CPU than processing strings all the time. 
Regards |
|||
|
09 Apr 2004, 13:26 |
|
|
f0dder 09 Apr 2004, 21:32
I wonder if filenaming parsing is a problem at all with modern filesystems, even with rather slow processors like 200mhz and below. Has anybody ever time this, or does the idea come from "I don't like fiddling around with filename parsing myself"?
If the idea of numeric files + filename database is used, doesn't this make the filename database very vulnerable to disk errors, filesystem bugs, etc? (assuming the database is kept in one place). Did you study any existing filesystems before coming up with this idea? Also, I agree with JohnFound about unicode. I really hate unicode and thing that ll other languages should be discarded in favour of english, but... I also live in the real world , and OEM charsets are more problems than they're worth (not to mention they probably won't do very well for stuff like chinese?) |
|||
|
09 Apr 2004, 21:32 |
|
|
JohnFound 10 Apr 2004, 08:23
Hi f0dder.
Actually, when I open this thread (look at the date of the first post) I never think that it will become so popular. This is simply very raw idea about FS for my future (  ) OS.
f0dder wrote: I wonder if filenaming parsing is a problem at all with modern filesystems, even with rather slow processors like 200mhz and below. Has anybody ever time this, or does the idea come from "I don't like fiddling around with filename parsing myself"? It depends of how the software is written. The OS make filename processing on every "open" of the file. So, the importance (in terms of speed) of this processing depends of many factors: If the program needs to read many small files, filename parsing can take veen more time than real reading of the data. Also, you know, the developper can simply make sequences like this with one file: "open, read 10 bytes, close, open, read another 20 bytes, close, and so on many times). Of course all this can be optimised with better written software, but in big projects like open source OS, where many programmers write different parts of the OS, such optimizations are very hard to be provided. So, if the OS works mainly with numeric identifiers, some of these problems can be avoided. Quote: If the idea of numeric files + filename database is used, doesn't this make the filename database very vulnerable to disk errors, filesystem bugs, etc? (assuming the database is kept in one place). Well, I don't think it will be more vulnerable than FAT structure for example, but note that destroing FAT means total lost of all files, but destroing the filename database will means only lost of filenames (in most cases only the part of filenames) but the files can be restored with simple scan of the disk for first file sectors. Actually in above described FS there is not possible to destroy all files at all destroing some data on the disk. Quote: Did you study any existing filesystems before coming up with this idea? No, I am not. But my OS is in the stage of ideas and I never though that so many people will be interested. btw: This FS is not exactly my idea. The most of the ideas are from FS of DOS 3.3 for Apple II computers. Many ears ago, I wrote the OS compatible with DOS 3.3 as school project and I implemented this FS in it. Later on PC XT, I began to wonder why the FAT system is implemented in so stupid way that destroing one sector of the disk may destroy all files.
Quote: Also, I agree with JohnFound about unicode. I really hate unicode and thing that ll other languages should be discarded in favour of english, but... I also live in the real world I think that this is simply because we are so used to 8 bit ASCII table. UNICODE is good idea (but AFAIK not in MS implementation that is different from the standard) Regards |
|||
|
10 Apr 2004, 08:23 |
|
|
neonz 11 Apr 2004, 11:42
JohnFound wrote: Hm, I don't know how Linux reaches this (are you sure?), but at first: Linux does not have TSS for each process. It only uses TSS task switching when changing cpl (cpl0 <-> cpl3). IMHO |
|||
|
11 Apr 2004, 11:42 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|