Index
> OS Construction > file systemGoto page 1, 2, 3, 4 Next |
| Author |
|
|
edfed 09 Oct 2007, 00:20
something very interresting is possible in fasm
org 100h ;org 7C00h call programm ret org 0 dd labelle db 'blalallkdjfhdkjqfhdjkfhezkafds;qn' labelle: db 'kldsncklnd,;:sqncnakljfdfqs' db 'Erfdsjsd,,:' align 512 org 0 dd otherlabel db 'dsd' otherlabel db 'fdfhlkjfljlkzef',0 with org xxxx it is possible to write a multisector structure No??? |
|||
09 Oct 2007, 00:20 |
|
|
Mac2004 09 Oct 2007, 16:39
edfed: Have you consired obtaining a book of OS theory? Os theory books might help you to find some answers concerning file system design.
regards, Mac2004 |
|||
|
09 Oct 2007, 16:39 |
|
|
edfed 09 Oct 2007, 16:46
i don't need this kind of book
the "bibliotheque" is full of books like this i need .txt .pdf .doc .asm .inc .com .hlp files and nothing else thank you what about dma programming what about udma programming what about i/o disk programming what about pic pit int programming? and the floppy disk how can i really control that? and not in theory and you? you probably have a little idea about file system? i need technical documents with exact indications about the norm and the HARDWARE |
|||
|
09 Oct 2007, 16:46 |
|
|
tom tobias 09 Oct 2007, 18:22
http://www.scilutions.co.uk/PCs.htm
http://www.wimsbios.com/index.jsp http://www.x86.org/intel.doc/IntelMotherBoards.html http://www.lvr.com/parport.htm http://dspace.mit.edu/html/1721.1/37331/6-828Fall2003/OcwWeb/Electrical-Engineering-and-Computer-Science/6-828Fall2003/LectureNotes/detail/pc_hardware_and_x86_-programming.htm http://ezinearticles.com/?PIC-Micro-Hardware-Programming-Methods&id=298343 http://www.thaiio.com/parallelportinfo.html |
|||
|
09 Oct 2007, 18:22 |
|
|
Artlav 09 Oct 2007, 18:23
Overexcitement, unsound english knowledge, lack of understanding of the topic - you can choose any two of that. (
 )
edfed wrote: i need .txt .pdf .doc .asm .inc .com .hlp files and nothing else Filesystems HOWTO: http://www.opennet.ru/docs/HOWTO/Filesystems-HOWTO.html Linux Kernel 2.4 Internals: http://www.moses.uklinux.net/patches/lki.html Operating System resource center: http://www.nondot.org/sabre/os/articles Cottontail OS Development Library: http://www.osdever.net/cottontail/ |
|||
|
09 Oct 2007, 18:23 |
|
|
edfed 10 Oct 2007, 00:43
yes thank you very much
i've found the most of documents links on fasm.net thank you i'll use it like it would be to make a fuckin os thanks again |
|||
|
10 Oct 2007, 00:43 |
|
|
Mac2004 10 Oct 2007, 17:11
Quote:
Personally I have written a file system of my own using Fasm so I know what it takes to design and write such a thing. By searching a little bit of theory you actually speed up the designing process. Fewer questions to ask and more understanding of the subject. A good file system is not a trivial task to do. |
|||
|
10 Oct 2007, 17:11 |
|
|
tom tobias 10 Oct 2007, 18:37
Mac2004 wrote:
|
|||
|
10 Oct 2007, 18:37 |
|
|
edfed 10 Oct 2007, 22:36
the first step of the creation of my os is the file system
i need it very simple and the nearest possible of the µP memory management the problem with 512 bytes sectors is that there is no 512 byte paging why??? ask to intel i decide to build the file system with a tree level coding for files 0 ) the root entry is one of x?(depend on user) in the boot sector 1st) the pointer table in the parent folder or a root entry 2nd) an allocation table to show the different zones of the file 3rd) the different zones of the files to load directly in file memory nb the folders are files too all is file a single sector too is a file and to economise memory a single sector will take place in only one sector how? the file size dword is less or equal 512 bytes? so the sector is directly taken from the index how to show the global disk occupation? with a field like in unix this field is pointed by the 'field' entry on boot sector it's a system entry, user canot acces (ring 3 ???) and the boot entry is the root of the boot process folder and development tools evolution of this kind of file system is possible compatibility with others file system is NULL there is no partition table and no bios parameter block and now i stop speaking i'll work
Last edited by edfed on 10 Oct 2007, 23:11; edited 2 times in total |
|||||||||||
|
10 Oct 2007, 22:36 |
|
|
f0dder 10 Oct 2007, 23:00
Why do you need to write a filesystem? For a school class? What are the requirements, etc?
Or do you just want to do it as a hobby project? |
|||
|
10 Oct 2007, 23:00 |
|
|
edfed 10 Oct 2007, 23:09
because i have a little hobby project
|
|||
|
10 Oct 2007, 23:09 |
|
|
Mac2004 11 Oct 2007, 04:01
tom tobias: Thanx for asking
I'am happy to share my thoughts. I will try to explain my ideas briefly.
To say it simple: 1) Files/folders have a header of 512bytes. First 256 bytes are reserved for the file/folder name and the rest are reserved for other data. Folders are basically linked lists of start sectors pointing to subfiles/subfolders. Files and folders are independent of their parent folders. (meaning that the subfiles/subfolders could be recovered in case of parent folder destruction (at least in theory). Presuming that subfile/subfolder sectors are intact one just needs to do sector by sector disk read to recover the file/folder.) 2) All other functions can written to produce basic file system services based on this simple idea. 3) When basic FS services are there one just needs to write actual ramdisk, floppy, ATA etc. implementations of the file system. 4) It's written from scratch and fully by using Fasm. How I tested the code: -- ----------------------- Personally I have tested my file system through ramdisk. I used ramdrive routines to test the first implementation of the file system. Doing so helped me to see whether there are serious bugs present in the file system code or not. I think basic ramdisk routines are rather easy to write. Especially when compared to writing a floppy or ATA driver.
Of course routines like printing strings, numbers, sectors in hex and ascii are very essential. (I guess this is very obvious )
regards, Mac2004 |
|||
|
11 Oct 2007, 04:01 |
|
|
tom tobias 11 Oct 2007, 10:10
Thank you very much, well done. May I ask a few fundamental questions? I apologize in advance, if some of these questions seem utterly banal. I have no experience creating a file system, but it is something in which I have great interest.
Mac2004 wrote:
Mac2004 wrote: Folders are basically linked lists of start sectors pointing to subfiles/subfolders. Mac2004 wrote:
Mac2004 wrote:
fudder wrote:
|
|||
|
11 Oct 2007, 10:10 |
|
|
ManOfSteel 11 Oct 2007, 15:38
@Mac2004:
Quote: I think basic ramdisk routines are rather easy to write. Especially when compared to writing a floppy or ATA driver. Could you give more information on the way you implemented ramdisk support like what functions did you implement? @tom tobias: Quote: For me, FAT offers far too much complexity, in addition to various copyright problems FAT is probably one of the easiest to implement I can think of (ok the LFN support is twisted, but still). There are easier-to-implement file systems like BFS but they are far too primitive to be used as general purpose FS. Then you have the other - far more complex - FS used (natively or not) in the Unix/BSD family and Linux. I think some day I will implement something like UFS or FFS... in a distant future. |
|||
|
11 Oct 2007, 15:38 |
|
|
Mac2004 11 Oct 2007, 20:07
@ManOfSteel: You need to implement basic read/write sector routines. The sector size is 512bytes (usually). Reading/writing ramdisk is just normal memory copying.
.
Formatting is a special case of writing and so on... That's what I meant by saying "easier than writing floppy or ATA driver". There's no need to access io ports to accomplish read/write sector routines. @tom tobias: Your are ok to ask.
Quote:
512bytes comes from the fact that sector size is normally 512bytes. I think disks as linear arrays of sectors. Personally I prefer having an option for long file names. I have been in situations where having 32 chars for a file name wouldn't been enough. The header size is planned to occupy one sector on a disk. I think it's easy access the file/folder that way. You only need to read header sector (=1 sector) from the disk in order access a file/folder. Yes, the remaining 256 bytes of the header do contain similar data you mentioned . Quote: Where do you manage the current location, i.e. the next place to write data on the hard disk, without overwriting existing data? How do you rewrite the starting address and length of the new data in the parent directory? What happens to obsolete data? Once the data is "deleted", do you simply change the pointer, leaving the data where it is, or do you write zeros to all locations? Do you have a method to compress (i.e. recover) former space, now "empty"? I use a bit table where one bit indicates the status of a sector. So one byte can hold the info for 8 sectors. Using the table allows me to find free space from a disk, recover "empty" space and so on.. "Deleted" data can handled 3 ways: 1) by freeing bits from the bit table and clearing the file header. 2) moving the file to "recycle bin", an area of sectors reserved for recycling 3) erasing the file by overwriting all of the sectors and freeing the bits from the bit table.. Quote: Which book do you recommend, for addressing these kind of fundamental questions? Personally I own a copy of Operating Systems: internals and Design Principles by William Stallings. It is an excellent book in my opinion. I think there are others as well, but I haven't had chance see them. Quote: I would profit from a bit more detailed explanation. Do you use a debugger to examine dram after simulating the hard disk operations by writing to memory? I wrote a routine that prints one sector (512bytes) contents on screen both in hex and in ascii. By using the routine I can check whats really happening in memory. It's a little bit like having a "poor man's disk editor"
regards, Mac2004 |
|||
|
11 Oct 2007, 20:07 |
|
|
edfed 11 Oct 2007, 21:35
mac2004
can you show us a disk image of your file system or a structure diagram? i have a very good idea write comments and/or file name in folder and file name in the first sector of the file chain |
|||
|
11 Oct 2007, 21:35 |
|
|
Mac2004 12 Oct 2007, 03:00
Quote:
Here's a short illlustration: -parent folder containing the start sector (=header) of a subfile/subfolder *Let's load the header sector from disk to memory. *Now we have both the name and the rest of the subfile/subfolder info loaded in memory: ------------------------------------------------------------------------- name string (256 bytes) FileID/FolderID (arbitrary constants to show that this a valid file/folder header ) actual file size size in sectors created date&time modified date&time accessed date&time (and so on,,) The actual file/folder starts right after the header sector. Quote:
I think my solution is like that you proposed.. regards Mac2004 |
|||
|
12 Oct 2007, 03:00 |
|
|
Hayden 12 Oct 2007, 09:00
A Garbage collector file system is probably a good 1st free file system to code. each file/directory has a header and data space. the header links files and directories forwards and back and tracks free/used space. As files are deleted they're marked as free. When a new file is written the algo starts at the root and searches the linked list for a big enough space, while doing this you could be doing a semi defag on the fly ect... blah blah...
nb. you could also interlink diretories ect.. ie: a perticular directory may be reached via several different paths starting from the root. _________________ New User.. Hayden McKay. |
|||
|
12 Oct 2007, 09:00 |
|
|
edfed 12 Oct 2007, 09:50
quote:
name string (256 bytes) FileID/FolderID (arbitrary constants to show that this a valid file/folder header ) actual file size size in sectors created date&time modified date&time accessed date&time (and so on,,) /quote: i add a feature a zone table to show the differents fragments of the file, if fragmented only two parameters, zone chs,lba or else, zone size (bytes) the fat chain will start in header just afer file name in my opignion file name mustn't reserve 256 bytes but must be possible to be more than 1 sector so i out a dword at the begining that index the begining of the zone map the last dword in a fat chain sector is the @ of following sector so it becomes fully modular and if file name is short, i onfy use the place it needs and if it's long it can be on severals sectors because file names can be very long ( contain comments into or web links and extra features ) this is to improve the fast of the file system exploration and i want a file name in the parent folder |
|||
|
12 Oct 2007, 09:50 |
|
| Goto page 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|