Hello all the 8086 hobbyists, Here is a new design change proposal, coming from first thoughts about the future implementation of a kind of TMPFS in ELKS. TMPFS would be the complement of the recently introduced ROMFS, that targets embedded systems with kernel and RootFS in the Flash memory, but without any write capability. It is intended for R/W folders like /tmp, /run, and /dev (for dynamic device file creation), with many but very small or even empty files (for devices). It could also be used as an initial RootFS in RAM in the future. For a minimal footprint in memory, it should not allocate memory in standard 512B / 1K blocks (like the RAMFS), but in small blocks of paragraphs, aka segments. Today the memory manager (MM) stores the table of the free segments (= holes) in the kernel space, with a maximum of 38 entries: #define MAX_SEGMENTS 8+(MAX_TASKS*2) #define MAX_TASKS 15 As space in kernel DS is limited, the proposal is to scatter that table into the whole available memory, as the usual chained-list of free & allocated segments (SLOB). The other table of the swapped segments would be kept in the kernel DS, for an obvious reason :-). Pros: - ability to allocate many small segments for TMPS inodes and file data - more space in the kernel DS for additional features Cons: - less efficient memory allocation (cost of list traversal) - memory fragmentation, even with current best-fit algorithm To mitigate the cons, we could use later some well known & more sophisticated memory allocation schemes (tree, buddy, SLAB, etc). But as ELKS is more for educational / experimental purpose than for a heavily loaded production environment :-P, I think it should be kept simple. Any idea to improve the proposal is welcome, MFLD -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
