OSDev.org

Hi,

Something that I haven't seen "spoken" of here very much is a kernel registry, some way to keep information available using a kernel call.

For example, an application may want to store the top-left pixel position at close time so that it can use that same position when it loads next time. Something like: I think XML would be a good source to do this, but decided to make my own using my own format.

To create the two entries above, a couple of calls such as: To retrieve a value: Anyway, if you are interested in what I have come up with, have a look here.

A (drop-in) demo/skeleton source code is included. The main idea was to be simple and easy to use. The code is currently experimental since I haven't tested it thoroughly. Comments are welcome.

Thanks,
Ben

BenLunt wrote:Hi,

Something that I haven't seen "spoken" of here very much is a kernel registry, some way to keep information available using a kernel call.

Kernels are about mechanism. This information looks more like policy, which I personally think lives in user land.

For example, POSIX kernels provide security mechanisms with almost no policy (based on separation of processes and access conrol based on user ids), but the act of logging in using a user name and authenticating that user is policy, and done entirely in user space.

BenLunt wrote: For example, an application may want to store the top-left pixel position at close time so that it can use that same position when it loads next time. Something like:

Code: Select all

"kernel/ApplicationName/Main/Window/Top = 100"
"kernel/ApplicationName/Main/Window/Left = 100"

I think XML would be a good source to do this, but decided to make my own using my own format.

Because, why not? We're all here because we like re-implementing things

This is also probably a bad example though. An application could simply save such information in an application specific manner (such as an .ini file), or use a system provided library to store the application data in an application specific registry hive/location, and get all these benefits.

* No synchronized access to some shared resource required.
* Maintaining settings in memory for applications that are not even running is not required

BenLunt wrote: To create the two entries above, a couple of calls such as:

Code: Select all

  registry_write_int("/Kernel/ApplicationName/Main/Window/Top", 100);
  registry_write_int("/Kernel/ApplicationName/Main/Window/Left", 100);

To retrieve a value:

Code: Select all

  int ret = 0, Left;
  ret = registry_read_int("/Kernel/ApplicationName/Main/Window/Top", &Left);
  if (ret == sizeof(int))
    ; // Left now contains the value of 100

Anyway, if you are interested in what I have come up with, have a look here.

A (drop-in) demo/skeleton source code is included. The main idea was to be simple and easy to use. The code is currently experimental since I haven't tested it thoroughly. Comments are welcome.

How/when should the values be persisted?

Presumably, a user level process could maintain the persistence on an ongoing basis, but the format doesn't look like it is very friendly for incremental updates, it looks like an all or nothing write of the entire registry contents.

Incremental updates could, however, be achieved by splitting the structure of the register hives, and the values in the hives.

So, when writing the registry file, you write:

- Root hive details (id=1)
- Child hive details (parent hive id=1, id=2)
- Child hive details (parent hive id=1, id=3)
- Grandchild hive details (parent hive id=3, id=4)
- Value in root hive (hive id=1, value id=5)
- Value in child hive (hive id=2, value id=6)
- Value in grandchild hive (hive id=4, value id=7)
- Value in root hive replacing original value (hive id=1, value id=5)

You can then stream the file sequentially, building up the in-memory registry based on the structure implied by the ids. Later values with the same ids as earlier values overwrite those earlier values, allowing incremental updates, making the registry more like an append only log. Very robust (no data is overwritten) and speedy (only write value changes) at the cost of having to compact the log every now and then. Each entry can have it's own checksum, so invalid entries can be detected and skipped, but you'd need some mechanism to resynchronize the stream if you want to recover values after an error.

A strict policy of "no policy in the kernel" made Linux device node creation horribly complex. BSDs implemented a device filesystem in the kernel, making system administration easier. I'm all in favour of simplifying administration and use, but I don't how this registry would. All you need is easy-to-use IPC and a server process, surely? (It doesn't even have to be fast IPC in any way.) Or a library as thewrongchristian states, but that may be a problem if two process try to write at once.

Fun factoid: The MS Windows registry is so slow, only Microsoft programs use it. (In general.) Other programs use their own files, perhaps only using a single registry key to find their files. This leads to the question of how a registry differs from a filesystem? Aside from registries being designed to store very small amounts of data, there's not much in it. They're both key-value stores, often with a hierarchal structure to the keys.

Edit: I'm not sure where I was going with this. (I guess I shouldn't be posting tonight.) I don't have anything against policy in the kernel, but I don't see why you'd want a registry in there. Then again, I can't see why you'd want resource forks but LEAN has them.

Thank you guys for your comments.

I probably failed to mention that my target audience is for the beginner. Of course those of us who are further along in our development, as it well appears you guys are, would of course use something more secure, complex, etc. However, my target audience has always been the ones starting to learn. Hence the simplicity of the design.

For example, in the USB on real hw thread I am currently participating in, Bonfra may wish to store the address of the UHCI his code found: or something along those lines, maybe with a few others to store information about the hardware found. I am sure he is not worried about security or any other of the fine points you guys mentioned at the moment. :-)

Again, thanks for the comments. They are very much welcomed.

Ben
- https://www.fysnet.net/osdesign_book_series.htm

BenLunt wrote:I probably failed to mention that my target audience is for the beginner. Of course those of us who are further along in our development, as it well appears you guys are, would of course use something more secure, complex, etc. However, my target audience has always been the ones starting to learn. Hence the simplicity of the design.

Now you mention it, I can see how it would be nice for beginners. I'm glad someone is writing good stuff for them.