Memory mapped files (or file mapped virtual address space for one program/process/thread)

[konard]

Are any plans for this? It is actually the only critical dependency for my database/platform to be ported to BareMetal OS and I'm still stuck with Windows and Unix here.. May be it will be even more efficient not to use small pages (4KiB) but instead to use (2MiB) pages.

This technique allows to give an infinite memory to any program/process (that is limited only by hard drives).

It does not require to be BMFS, but it also good to have example like this. It will allow to split space of hard drive between multiple threads, so each will work with separare virtual address space, that is storable and extendable by hard drives or ssds.

https://github.com/Konard/LinksPlatform (this is project that I'm going to port to BareMetal OS sooner or later)

[IanSeyler]

Using 2MiB pages would be ideal as that is what BareMetal already uses for memory mapping.

I'll investigate how this could be added. I'm just not sure of how caching should be configured.

[konard]

May be it is a good idea to make memory mapping as a "plugin"? So the developer can deside how to optimize caching? And provide a simpliest example how to implement it?

[ohnx]

@konard Making BareMetal-OS a modular OS, where you could select extra features to suit your needs, is an interesting idea.

[konard]

At least we can select features (modules or packages) that should be included OS (before compiling or writing to disk/flash). It can be done through modification of code, or through plugin system. By hand or automatically.

[effbiae]

Maybe, as with another famous kernel, a config file (optionally generated
by a menu system) can choose to include or exclude code.

The code might be best kept in one repo or optionally got from another
repo. (Hybrid system).

I'm almost at the point of switching to BM but being able to map disk
blocks into an address space is important for me.

Jack

On Thursday, December 31, 2015, Konstantin Dyachenko <
notifications@github.com> wrote:

May be it is a good idea to make memory mapping as a "plugin"? So the
developer can deside how to optimize caching?

—
Reply to this email directly or view it on GitHub
ReturnInfinity/BareMetal-OS#105 (comment)
.

[IanSeyler]

Fixing the memory mapping that is currently being used is here: https://github.com/ReturnInfinity/BareMetal-kernel/issues/14

All further development is going into BareMetal-kernel. I'm moving away from a sort of "general purpose" OS to a more "server node" type of OS.

Fixes/additions may be back ported into BareMetal-OS but I'm not sure of its roadmap at the moment.

[konard]

So what repository is most ready to be used? https://github.com/ReturnInfinity/BareMetal-OS or https://github.com/ReturnInfinity/BareMetal-kernel ?

[ohnx]

@konard BareMetal-kernel is most up-to-date, but lacks many of the features present in BareMetal-OS. However, most of the big changes in the kernel are also committed to this repository.

[IanSeyler]

@konard BareMetal-OS at the moment as there is no way to control an instance of just BareMetal-kernel yet as I stripped out the CLI.