Message board for the users of flat assembler.
> OS Construction > FOOL disk as file system?
now, what is a file?
a file is a string of bytes with a name and a date of creation, and a location.
it is a muldimensional object then.
for a CVS tool, a file is mainly an entity with an identifier, and a set of updates.
then, now, what can be made to have a very good file system?
an ID (UUID for example, but better of course, cause we just made better things, if not, don't do anything at all and return to holidays), and this id is an entry connecting to the current state of the document, and it's history.
but make it simple please, nobody wants to deal with complex stuff where it can be simple.
then, the version control should just be an overlay, or a plugin, or something like this. an option. This option to have a version control is one option into many others. theses options should be stackable, treeable, modifiable, and so on.
an other option can be the cryptography layer, the connection to a software , a class, or anything. it can also be a linkage, a stringage of documents, a machine, an user, and so on. anything can be optionnal, but the file itself is not an option.
this file is then the element we need to handle.
what is a file? really?
it is a string of bytes, somewhere.
even the meta data of a file is an option if we consider this design.
then, a file is an item described by it's location, its size and that's all.
if we need overlay, we should then create another structure, like filemeta.
filemeta will then be a set of metadata used to describe the file as a document.
for example, filemeta will have a name, a datetime, and a pointer to a fileitem.
now if we need crypto or anything, we should make it a fileitem.
this fileitem is just a set of the cryptotool flag and a pointer to the fileitem.
what is now to consider is the fact that to exploit a crypted file, we also need to get the file location and size. these datas are given by the file structure. the file tool will then scan the tree of items to get theses data from the corresponding item.
means that tools to handle files should work only on theirs datas, and ignore the datas from others elements from the tree.
this feature is transparent with fool due to the .call pointer at the beining of every items.
the stacking and pluging feature is also transparent in the fool design, then, this speach end there, and just tell a file is a name, and a pointer to a fptr.
then a filemeta is
.option there is a plugin or a tree of plugin. this item will then be used to pipeline the .file item.
as the problem is not simple ( create new objects in the structure) i plan on the basic functions:
will read the drive and copy the bytes in the ram. or write from ram to drive.
drives are mainly fixed size and will not change during os running.
the disk structure i use for the moment is big:
.call=0 ; function .cmd=4 ; drive command read or write .drv=5 ; drive number, BIOS based .cnt=6 ; count of sectors to read .s=8 ; starting sector .h=9 ; starting head .c=10 ; starting cylinder .off=12 ; where in segment .seg=14 ; where in ram .s0=16 ; number of sectors .h0=17 ; number of heads .c0=18 ; number of cylinders .kb0=20 ; number of kilobytes
needs to reserve 24 bytes for all disk objects.
the idea to correct the problem will be to reserve only one drive access object for each drives.
the applications will ask the system to r/w the device via the only structure for hte drive or application.
no need to make 10 objects for all drive accesses.
only one for all drive accesses from all application.
to do so, a little object is needed.
the minimal unit of data to lacate and quantifies a file.
LBA(32) + bytes(32)=64. to start.
a 4 gigabytes file is very big for me.
the problem is:
.s0=16 ; number of sectors .h0=17 ; number of heads .c0=18 ; number of cylinders .kb0=20 ; number of kilobytes
apparentlly it is a big waste of memory to use them for each disk objects, and a big waste of ressources to build them.
as stated above, this object, drive geometry at least, will be globalised.
let see the procedure itself:
call .id mov al,[si+.s] mov ah,[si+.h] mov bx,[si+.c] mov cx,[si+.cnt] mov dx,[si+.off] push cx dx es .next: dec word[si+.cnt] jl .end push ax bx mov cx,bx mov bl,cl mov cl,ch mov ch,bl shl cl,6 and cl,0c0h or cl,al mov dh,ah pushaw call .atom jnc @f popaw pushaw call .atom jnc @f popaw pushaw call .atom jnc @f .error: popaw pop bx ax clc jmp .tchao @@: add word[si+.off],512 popaw pop bx ax inc al cmp al,[si+.s0] jne @f mov al,1 inc ah cmp ah,[si+.h0] jl @f mov ah,0 inc bx cmp bx,[si+.c0] jl .next mov bx,0 @@: jmp .next .atom: call .reset mov bx,[si+.seg] mov es,bx mov bx,[si+.off] mov ah,[si+.cmd] mov al,1 mov dl,[si+.drv] int 13h ret .reset: mov dl,[si+.drv] mov ah,0 int 13h ret @@: clc ret .id: cmp byte[si+.drv],0 jnl .floppy call .reset jc @b mov ah,8 mov dl,[si+.drv] int 13h inc dh mov [si+.h0],dh mov bx,cx and cl,not 0c0h mov [si+.s0],cl mov cl,ch mov ch,bl shr ch,6 inc cx mov [si+.c0],cx @@: movzx ax,byte[si+.s0] movzx bx,byte[si+.h0] mov cx,word[si+.c0] imul ax,bx imul ax,cx shr ax,1 mov [si+.kb0],ax stc ret .floppy: mov word[si+.c0],80 mov byte[si+.h0],2 mov byte[si+.s0],18 jmp @b .end: stc .tchao: pop es dx cx mov [si+.off],dx mov [si+.cnt],cx ret
as you can see, it use the BIOS int13h and for all disk operation, it will build the disk size field using BIOS drive ID.
but, it can be avoided by using a global drive identification for exemple.
this ID, where to put it?
then, it reloop the problem somewhere in the kernel, if the kernel is really modular, it will not have a fixed location for drives IDs.
th emodularity will be killed a little.
for example, an application that will access the drives will have it's own drive context, but only one time, at a specified location.
for example the application will enter with [desk], and the related drive context is [drive]
desk as ram, and drive, as hard disks and floppies.
Last edited by edfed on 09 Nov 2020, 11:39; edited 2 times in total
|15 Jun 2008, 11:28||
finally, i adopt this sheme previouslly aborded.
it works very well, need some bugfix ( very meticulous work).
bug's are theses:
if you don't mov value at [esi+disk.drv] with the right dl, it don't work at all.
3 essentials functions use disk structure.
reboot, to read the bootsector and jump to it at 0:7c00h, need plain dos ( not tested).
bootcopy, to copy the bootsector on a drive
install, to install the current settings on a drive.
be carefull, use only with test drives.
test config: PC PMMX@233MHz ali chipset 32MB PC100 SDRAM 1025 MB Compact Flash as secondary master LG DVD player as secondary slave floppy drive RTL ???? retwork card SIS 6215 ( hard 24bit/pixel ) SB PCI128 serial mouse AT keyboard
it don't works when i type:
install 128 <enter>
bootcopy 128 <enter>
reboot 128 <enter>
but it has worked only one time with:
and don't hav the time to test more tonight...
|21 Sep 2008, 23:42||
now, f.disk uses a pointer to a fptr to access memory.
and the best, it uses LBA instead of CHS, even for floppy.
it gives this structure:
disk: .call=0 .cmd=4 .drv=5 .cnt=6 .lba=8 .ptr=12 .geometry=16 ;returned by disk operation .kb0=20 ;returned by disk operation
to do a drive id,call an empty disk item (.ptr=0)
.ptr îs a 32bit offset in current address space (org ???)
id ptr=0, then, it is not a valid pointer, and it ends.
i like this '0' value.
next step, link it to a file system.
the first attempt is in bootwriter06
it uses DOS int21h
3Dh, 3Fh, 3Eh.
open, read, close
the dos handle is only used inside this linear stream.
then,it limits my needs from file system to that:
.ptr=4 ; same structure as one pointed to by disk.
.name=8 ; ascci path and name of the file, a command line parameter for example.
.handle ; value returned by dos, but not used by fool.
knowing theses needs, it is easy to do a singular structure around fptr
effectivelly, fptr have all the chances to become a file system structure.
.size is used by disk and updated by fileread.
if you want to read 321 bytes from a 32 bytes file, it will be usefull.
if you wan to set the file size to a sector boundary.
a file would be represented by this on the disk:
xfile: ;lol .call=0 .name=4 .lba=8 .size=12 .ptr=16
there, you see it can be possible to set a ram location for the file.
just to show it is still in ram,at the fptr location.
if fptr = 0, then, the file is on the drive, or nowhere.
this value is not modified on the drive. only moded in ram.
the cached folders will contain the xfiles, xfiles are only file descriptors.
like the DOS handle
then, a file in ram will be descripted by it's descriptor in folder (in ram too). if not in ram, then, read it from drive. and update fptr.
file access can be only with the 'path/folder/file' style.
but after loading, the path is converted into a fptr.
and this fptr is a DOS-like handle.
a little more fool.
to update fptr, i need memory management .
|09 Dec 2009, 05:14||
< Last Thread | Next Thread >
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.