Index
> OS Construction > file systemGoto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
edfed 19 Oct 2007, 15:52
caching hole track or several heads can evectivelly helps
now the problem is not the file system model in drive it is the linking manner in ram that i want to find the nearest possible of the µP mecanism for Real mode for Protected mode and for other µP types exemple: PIC 16F84, 6809, etc all these have a different memory model so the ram disk routine is platform dependant but the global structure need to be the same for all architectures to make easyer the design by one personn: ME thanks for the caching idea making a full head loading seems to be a good idea the limit of 64k is not a problem and is simple to use under real mode wht is the best to index sectors locations? CHS?, LBA? chs is a notation that show the geometric position of the sector assuming the drive is not a flash memory 0 doesn't exists in C/H/S form and can be used like a flag Lba is the linear location of sector and don't care about geometry i prefer C/H/S and you? |
|||
19 Oct 2007, 15:52 |
|
|
Hayden 19 Oct 2007, 18:02
CHS is fine but i prefer LBA indexing for these reasons;
* sectors can be indexed useing only one variable, ie; for a floppy 16-bits would allow me to index a full 2880 sectors. so no need to keep track of C,H,S etc.. ( my boot code keeps track of sectors in LBA and just translates them to CHS just before the call to INT13 ) * LBA indexing can be translated to CHS/PHS quite easily. * LBA scheme works better for protected mode. If you like I'll explain how my code works a little better, it's quite optimized and compact so it might be hard for others to grasp exactly what is going on. anyway i've been meaning to turn it into a r/w int13 handler, maybee i'll get arround to it this weekend _________________ New User.. Hayden McKay. |
|||
|
19 Oct 2007, 18:02 |
|
|
edfed 20 Oct 2007, 14:01
ok
so it needs to manage CHS and LBA format CHS is very usefull cause it like the RGB each component in a part of the DWORD al=sector ah=head ror eax,16 ax=track with LBA, the problem is to respect drive geometry and limit the heads movements but the file system functions are there to make it transparent ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; FINALLY: i'll make it with LBA but i'm not really happy to make that the problem is tha hard ware layer, it will waste a lot of time just to convert LBA to CHS, but it is good because it is more like the RAM. then, HD will be NVRAM Last edited by edfed on 14 Apr 2008, 02:20; edited 1 time in total |
|||
|
20 Oct 2007, 14:01 |
|
|
edfed 05 Dec 2007, 02:20
page 2, file system structure post updated.
you know? the one with the beautyfull JPG driagram  |
|||
|
05 Dec 2007, 02:20 |
|
|
bitRAKE 05 Dec 2007, 05:08
Hayden wrote:
|
|||
|
05 Dec 2007, 05:08 |
|
|
edfed 05 Dec 2007, 05:13
% Most disk BIOS calls use the following parameter scheme:
AH = function request number AL = number of sectors (1-128 dec.) CH = cylinder number (0-1023 dec.) CL = sector number (1-17 dec.) DH = head number (0-15 dec.) DL = drive number (0=A:, 1=2nd floppy, 80h=drive 0, 81h=drive 1) DL = drive number (0=A:, 1=2nd floppy, 80h=C:, 81h=D 
Note that some programming references use (0-3) as the drive number which represents diskettes only. ES:BX = address of user buffer % and return with: CF = 0 if successful = 1 if error AH = status of operation (see INT 13,STATUS) |
|||
|
05 Dec 2007, 05:13 |
|
|
LocoDelAssembly 05 Dec 2007, 05:26
bitRAKE, but it is OK
Quote: CL = sector number 1-63 (bits 0-5) What is "strange" is writting "6" as "6d" (But valid, the "d" subfix means decimal). |
|||
|
05 Dec 2007, 05:26 |
|
|
bitRAKE 05 Dec 2007, 05:37
LocoDelAssembly wrote: bitRAKE, but it is OK 
(time to sleep) |
|||
|
05 Dec 2007, 05:37 |
|
|
edfed 07 Dec 2007, 03:06
ok, cl 0-5 are used for sector now!
in the DOS age, it was limited to 17 sectors in total per head. and i don't know any good reference about the norm after 1986. probably, the helppc need to be updated and modernised!  |
|||
|
07 Dec 2007, 03:06 |
|
|
edfed 08 Dec 2007, 00:12
file system services.
they will be located in boot/fs/ theses services are specialised for this file system. read file: a command line give the file name and path the routine returns the memory location set by the Memory Manager this location is copied into the ram file system. if this file is reopen, then, it will point to the first location without reloading. a modification on an opened file is seen by other applications file reload can be forced. write file: the file doesn't exist on disk, then the disk manager create the file header and prepare the file system to receive the file. the file exist, then it is simply overwriten. if the write result in a fragmentation, the disk manager seek an other contiguous area where to move the file. if no contiguous area found, it test for a possibility to displace the needed sectors, for exemple, a very little file just after the file to save is easy to move. if no possibility of move, the file is fragmented (zoned) a command line give the file name and path if the path doesn't exist, it's created. file delete: to delete a file, is it in ram? if yes, it's erased in ram and ram fs is it on disk? if yes, the entry is erased in fs is it a secure delete? if yes file is fully overwriten with 0 if it's nowhere, ne delete is achieved file creation: the command line give the path and file name. the entry in the path is set if the path doesn't exist, it's created. the file is a 0 byte lengh file. no sector is allocated for it. file system verification: scan the file system for crossing references. normally, there cannot be crossing reference. as a sector cannot be allocated for more than One file. verification of bad sectors, verification of unreferenced sectors. if a sector of a file is shown as empty, set it to full. |
|||
|
08 Dec 2007, 00:12 |
|
|
edfed 09 Dec 2007, 15:24
one big correction to make...
DO not put the file name in an header. it's endless. there is a name in theh folder, and sometimes into the file itself (MP3,WMA,WAV,DOC etc...) so why having a file name in the header? just to follow the idea of somebody??? no i disagree, NO FILE NAME IN FILE SYSTEM HEADERS. but the path in the file header, why not. not really a path, just a two dwords to give the comming entry from the folder sector, and optional... the minimum space occupied is then one sector. the maximum file size is (4G-1)*512+(4G-1) bytes i think it's enough for the 2008 year applications. |
|||
|
09 Dec 2007, 15:24 |
|
|
edfed 18 Jan 2008, 03:01
i relaunch the discussion:
what are the mains functions used by a file system. can you give me some lists of mostlly used functions. it's because i never play with files in my codes and i want to know exactlly wich functions you like to call. and wich you dislike to call. and more deeper, i want to know what you want to obtain by calling such a function. thanks. |
|||
|
18 Jan 2008, 03:01 |
|
|
Hayden 06 Feb 2008, 12:18
Persuedo code: fn = filenum s = string i = integer x = object
fn = open(s,i) -- open file in text or binary mode close(fn) -- close file flush(fn) -- force o/s to flush cached file to disk i = getc(fn) -- fetch char from cache/file s = gets(fn,i) -- fetch sequence of 'n bytes from cache/file putf(fn,x) -- put bytes into file _________________ New User.. Hayden McKay. |
|||
|
06 Feb 2008, 12:18 |
|
|
edfed 06 Feb 2008, 13:21
thanks a lot hayden.
Quote: Pseudo code: fn = filenum s = string i = integer x = object so, only this is realy needed? ok! let's play with asm coding of this: Code: ... filepath db 'usr1/video/dragon ball z - film 1 - à la poursuite de garlik.avi',0 ... file?: .path dd filepath .ptr dd ? .size dd ? .size2 dd ? ... filelist: .size dd @f-$-8 .ptr dd 0 ;to point to the current handle .num rd 20 ; limit the application to 20 files open @@: open file: Code: mov edi,filelist mov esi,file? call openf ... openf: .path = 0 .ptr = 4 .size = 8 .size2 = 12 ... mov edi,[edi+4] ; extract the current file handle mov [edi+filelist.num],esi ... to link the file to the application? mov [esi+.ptr],ebx ... linear location in ram? mov [esi+.size],ecx ...in bytes mov [esi+.size2],edx ...in clusters ( 512, 4096, 1,etc...)bytes ret close file: Code: mov edi, call closef ... closef: mov d[edi],0 mov d[esi+.ptr],0 mov d[esi+.size],0 mov d[esi+.size2],0 ret flush file: Code:
...
am i in the right way about the implementation? |
|||
|
06 Feb 2008, 13:21 |
|
|
f0dder 06 Feb 2008, 14:26
Hm, why emulate libc at the OS kernel level? Imho text/binary distinction has no place in an OS kernel, that should be up to the user binaries.
And what about the more important things like cache-control and async I/O? |
|||
|
06 Feb 2008, 14:26 |
|
|
edfed 06 Feb 2008, 14:40
it's not an emulation, just a way to support multitask functions.
execution context is not a stack, but an array in memory. about the cache control and async I/O, i want it transparent. and synchronised by the PIT IRQ0, to make it a bit more synchrone. the file system services are hard to define without experience. i never play with files, and i'm a little agree in the fact that copying the standard service is not a good idea. but how can i play with files in this file system? fodder: do you have an idea? |
|||
|
06 Feb 2008, 14:40 |
|
|
f0dder 06 Feb 2008, 14:48
Ummm, where did "emulation" and "multitask" enter the picture?
Cache control and async I/O cannot, by definition, be transparent. Once a standard "read" call is done, the application expects data to be in the buffer. |
|||
|
06 Feb 2008, 14:48 |
|
|
edfed 07 Feb 2008, 17:35
i've got a shocking idea...
why make a file system depending on granularity? why not make a linear file system, whithout notion of SECTORS, CLUSTERS, etc...? i was thinking about it cause managing a linear address space is easy, and managing a granular address space is boring. this idea can simplify the implementation and the ram mirroring of this file system. ram exactlly as disk, disk exactlly as ram. one thing change, the minimal file occupation will become the minimal set of pointers + 1 bytes. many little files will be writen on one unique sector, and the access to file system will be a linear access with 64bit pointers for drive > 4GB, 32bit pointers for drives > 16MB, 24bit pointers for the drives =< 16MB no fat, only tables and structures. and for services, only linear accesses to a linear address space, simple and efficient. no? the drive will become a simple tree. there, the paging capabilities of the pentuiums will be usefull, as all linear spaces of drives will be paged in ram. |
|||
|
07 Feb 2008, 17:35 |
|
|
revolution 07 Feb 2008, 17:45
What happens when you want to append bytes to a file one at a time? How do you handle deletions? What happens to free space, how is it reused?
BTW: a FAT is "only tables and structures". BTW2: RAM is allocated by the OS in 4kbyte sections, not 1 byte sections. |
|||
|
07 Feb 2008, 17:45 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|