OSDev.org

salloc.c (sector allocator) is a static sector buffer allocator cache for small systems.
salloc expects two parameters - a DWORD LBA sector number and a DWORD flag called clear.
salloc returns a void* to a 512 byte buffer which contains the contents of the file system LBA
sector. This buffer is assigned to the LBA requested.
If the clear flag is set, a buffer of zero's is returned. This buffer is assigned to the LBA
requested and marked dirty. This feature is used FAT32 when a directory needs to be extended
with an additional cluster cleared to zero's.
The header of the headerless buffers (the header is not attached to the buffer as in malloc)
contains pointers for 2 double linked lists, the LBA, the buffer address, a dirty flag and a locked flag.
All buffers are statically linked to a Least Recently Used list and are double linked to a LBA array
of pointers.
To find an LBA the modulus (sizeof (the array)) is used to index the array. Buffer headers are double
linked to this list as the buffers are allocated. Each allocated buffer is moved to the MRU end of the
list and also to the beginning of it's LBA array list. Unlike the usual buffer cache systems only a
pointer to the buffer is returned (there is no back and forth copying).

scommit expects a single parameter - a void* which was returned by salloc and marks the buffer
header as dirty.

sreserve expects a single parameter - a void* which was returned by salloc and marks the buffer
header as locked. Locked buffers are skipped in the selection of LRU to maintain important buffers
in memory.

srelease expects a single parameter - a void* which was returned by salloc and marks the buffer
header as unlocked.

sflush expects a single parameter - a void* which was returned by salloc and writes the buffer if
marked dirty to the drive. If the parameter is 0, all buffers marked dirty will be written.

Invalid buffer pointers are merely ignored when committing, reserving, releasing and flushing.
sverify expects a single parameter - a void* which was returned by salloc. This is an internal routine
with verifies the buffer address with range checking. It calculates the associated buffer header
pointer, so there is no lookup required as with the usual buffer cache systems.

A read_write_sectors (and memset) must be provided.

I tried to study the code and recorded the way in which I understood it. It is good to see it in fast forward and several times because it seems to be much more optimized for code optimization than for reading as text.

It took me 45 minutes to parse and type it manually and I still need to keep reading it to understand how to connect it with other code:

>> Sector Allocator.html <<

mikegonta wrote:salloc.c (sector allocator) is a static sector buffer allocator cache for small systems. ...

I'm afraid that's a bit too little for a description before jumping into the technical details of inputs, outputs, etc.

alexfru wrote:

mikegonta wrote:salloc.c (sector allocator) is a static sector buffer allocator cache for small systems. ...

I'm afraid that's a bit too little for a description before jumping into the technical details of inputs, outputs, etc.

I guess it means that it's a sector cache allocator that deals with sector buffers. A cache made up of disk sectors, presumably contiguous at the start but that could become fragmented later.

It's like saying that it's a low level swap or a set of functions to handle the sectors of a "page file" or "swap" at the lowest level (maybe it would be much more efficient if it kept the sector list of that file or keep just the start and number of sectors of a small cache partition or maybe more exactly a temporary reserved sector area managed by the kernel and file system driver TO AVOID USING FIXED SWAP PARTITIONS OR FILES THAT TAKE UP A LOT OF STATIC SPACE BUT ARE USEFUL ONLY WHEN THE MACHINE IS RUNNING).

But since it's a brief program, that file system layer would need to be added to lock an area of sectors until the computer is turned off (it could be an automatically growing/shrinking area as needed at runtime). It could probably be useful for things like quotas or compressing on the fly (as a small component to keep a minimum free space on disk to allow operations even if it becomes full), or to handle special metafiles.



__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________
I guess the text recording I made and watching it sporadically allowed me to be able to understand the basic intention of the program.

It looks like watching the pure-text recording of how a program or document/book was typed/edited/created makes that text more understandable, the reading more reasoned, and that the intention makes much more sense.

And if we did the program ourselves or if we re-typed it, makes that reading it and understanding and remembering details and the logic about it again becomes so automatic that we get to understand even with our attention span mostly unfocused while watching the recording.

I don't know what you are smoking, but I wouldn't mind having some of it.