libkernaux — Auxiliary library for kernel development

[kotovalexarian]

Hello. I've started working on libkernaux — auxiliary library for kernel development.

https://github.com/tailix/libkernaux

Now it can read registers cr0, cr4, write to registers cr0, cr3, cr4, perform port I/O, print (using given printing function pointer) and validate Multiboot 2 information. I'm going to implement much more.

I decided to move code to library to use automated unit testing and make code cleaner by eliminating global state.

Library can be built with cross-compiler using "configure" command from README. To build and install it when it was configured with cross-compiler use the following commands (just make && sudo make install doesn't work):

Code: Select all

make libkernaux.a
sudo make install-libLIBRARIES
sudo make install-data

Any feedback/help?

[PeterX]

I personally prefer writing that kind of stuff myself in an Assembler object file. But maybe it will be useful for some people, I don't know. If everything fails, it will at least be useful for your own kernel coding.

You could easily adapt the makefile so that it works with "make" and "make install". Just place the rule for making linkernaux.a as the first rule in the makefile. And create a rule "install" which requires the other install-targets.

I'm not sure if install-libLIBRARIES is a typo.

Also you name the lib linkernaux and the repo libkernaux. That's a bit confusing.

Greetings
Peter

[kotovalexarian]

Also you name the lib linkernaux and the repo libkernaux. That's a bit confusing.

That's a typo. Thank you.

You could easily adapt the makefile so that it works with "make" and "make install". Just place the rule for making linkernaux.a as the first rule in the makefile. And create a rule "install" which requires the other install-targets.

I use autotools, but I'm not very familiar with it.

I personally prefer writing that kind of stuff myself in an Assembler object file. But maybe it will be useful for some people, I don't know. If everything fails, it will at least be useful for your own kernel coding.

The library is for my own kernel development. However, it is abstract enough to be used in any kernel. The idea is that you can use only those functions which you need.

[bzt]

Hi,

Nice, and I agree with @PeterX, I wouldn't use this myself, but it could be useful for some people.

I use autotools, but I'm not very familiar with it.

I think @PeterX is right in this regard too. Your library is intel 32 bit only, and it requires a cross-compiler, so I don't see much point in using autotools here. Having some simple and straightforward makefile rules would be better.

I decided to move code to library to use automated unit testing and make code cleaner by eliminating global state.

These are generally good practice for a user-space library. However I'm sure you can't test most of a kernel-lib (like setting cr3 for example), plus I'm not convinced that eliminating global variables is a good thing for a kernel. I believe using global variables (for a kernel) is not just fine, but also preferable for certain things.

Anyway, keep up, your OS is going to need this lib.

Cheers,
bzt

[kotovalexarian]

I think @PeterX is right in this regard too. Your library is intel 32 bit only, and it requires a cross-compiler, so I don't see much point in using autotools here. Having some simple and straightforward makefile rules would be better.

This will change when I'll start porting my kernel to other architectures. You may say that this is premature engineering, and you will be right. However, it's my personal preference to make things universal and abstract as early as possible, it better fits my high-level thinking in software engineering. I prefer self-documented and unit-tested code than keeping in mind all details, and I think this is a good practice in software engineering despite it has some costs.

These are generally good practice for a user-space library. However I'm sure you can't test most of a kernel-lib (like setting cr3 for example), plus I'm not convinced that eliminating global variables is a good thing for a kernel.

Of course, setting cr3 is just a helper function. There are many things that really should be tested. I have already implemented Multiboot 2 code. Next thing I'm goint to implement in the library is page frame allocator.

[PeterX]

You may say that this is premature engineering, and you will be right. However, it's my personal preference to make things universal and abstract as early as possible, it better fits my high-level thinking in software engineering. I prefer self-documented and unit-tested code than keeping in mind all details, and I think this is a good practice in software engineering despite it has some costs.

That is indeed a matter of personal preference. I program rather the opposite way: Small and KISS-principle. I also prefer the low level coding like bootloader, kernel etc. while others prefer coding the GUI.

Greetings
Peter

[nexos]

You may say that this is premature engineering, and you will be right. However, it's my personal preference to make things universal and abstract as early as possible, it better fits my high-level thinking in software engineering. I prefer self-documented and unit-tested code than keeping in mind all details, and I think this is a good practice in software engineering despite it has some costs.

That is indeed a matter of personal preference. I program rather the opposite way: Small and KISS-principle. I also prefer the low level coding like bootloader, kernel etc. while others prefer coding the GUI.

Greetings
Peter

I used to be the same way until I realized my simple stuff was simple, buggy, and useless. I believe in simplicity, but there has to be a share of complexity in everything. I think using autotools was a great idea! Keep up the good work.

[kotovalexarian]

Updates:

• Improved README, now it covers API and installation process.
• Continuous testing with Travis CI.
• Added stdlib replacement (NULL, bool, FALSE, TRUE, memset, strlen, strncpy, itoa).
• Added serial console to be used for kernel dubugging.

[kotovalexarian]

I've added example for command line parser, which is still a work in progress, but is already useful enough.

Code: Select all

#include <kernaux/cmdline.h>

#include <assert.h>
#include <stdio.h>
#include <string.h>

static const unsigned int ARGV_COUNT_MAX = 100;
static const unsigned int ARG_SIZE_MAX = 4096;

static const char *const cmdline = "foo bar\\ car";

int main()
{
    char error_msg[KERNAUX_CMDLINE_ERROR_MSG_SIZE_MAX];
    unsigned int argc;
    char *argv[ARGV_COUNT_MAX];
    char buffer[ARGV_COUNT_MAX * ARG_SIZE_MAX];

    assert(kernaux_cmdline_parse(
        cmdline,
        error_msg,
        &argc,
        argv,
        buffer,
        ARGV_COUNT_MAX,
        ARG_SIZE_MAX
    ));

    assert(strcmp(error_msg, "") == 0);
    assert(argc == 2);
    assert(strcmp(argv[0], "foo") == 0);
    assert(strcmp(argv[1], "bar car") == 0);

    printf("OK!\n");

    return 0;
}

[kotovalexarian]

I've removed NULL, bool, FALSE, TRUE from stdlib replacement because stdbool.h and stddef.h are available in freestanding environment.

[kotovalexarian]

I've finished command line parser. See usage example here. It supports:

• Simple arguments:

  Code: Select all

  foo bar car => 'foo', 'bar', 'car'

• Escaping in arguments:

  Code: Select all

  foo\ bar car\\cdr => 'foo bar', 'car\cdr'

• Quoted arguments:

  Code: Select all

  "foo bar" car => 'foo bar', 'car'

• Escaping in quoted arguments:

  Code: Select all

  "foo\"bar" car => 'foo"bar', 'car'

[kotovalexarian]

I've started working on measurement units utils (to display and, in future, convert bits, bytes, kilo, mega, giga, kibi, mebi, gibi, etc.). May be useful for debugging kernels with printing (to serial console, to screen).

Code: Select all

#include <kernaux/units.h>

char buffer[64];
kernaux_units_human_bin(4096, KERNAUX_UNIT_BYTE, KERNAUX_UNITPFX_KIBI, buffer, sizeof(buffer));
// buffer is "4096 KiB"

[kotovalexarian]

libkernaux 0.1.0 released!

I've decided to split APIs into stable and work-in-progress. Stable APIs follow semantic versioning. Current stable APIs are the following:

• <kernaux/assert.h>
• <kernaux/libc.h> (memset, strcpy, strlen, strnlen)
• <kernaux/ntoa.h> (kernaux_utoa10, kernaux_itoa10)
• <kernaux/printf.h> (kernaux_[v]printf, kernaux_[v]snprintf; code adapted from https://github.com/mpaland/printf)

GitHub release: https://github.com/tailix/libkernaux/re ... tag/v0.1.0
Distribution (no need for autotools to compile): https://github.com/tailix/libkernaux/re ... 1.0.tar.gz (SHA-256: b80c1d94519a43bd92c2b1a7626bdb5af5aa98dd993b2332d56449b0be7dbc8f)

Install:

Code: Select all

./autogen.sh # requires autotools; not needed if you download distribution archive
./configure CFLAGS='-fPIC'
make
sudo make install

Freestanding version to use in your kernel (i386):

Code: Select all

sudo apt install crossbuild-essential-i386
./autogen.sh # requires autotools; not needed if you download distribution archive
./configure --host='i386-elf' --prefix='/opt/libkernaux/i386' --with-libc AR='i686-linux-gnu-ar' CC='i686-linux-gnu-gcc' RANLIB='i686-linux-gnu-ranlib' CFLAGS='-ffreestanding -nostdlib -fno-builtin -fno-stack-protector -fno-pic'
make
sudo make install

To make it less bloated, for example, manually select only stable APIs:

Code: Select all

./configure --without-all --with-libc --with-ntoa --with-printf

See more options in README.md or with ./configure --help

Also I'm going to provide bindings for Ruby (because I'm actually a Ruby programmer) and safe and unsafe nostd Rust (because I love it). Their versions will equal corresponding version numbers. For now I've only started working on Ruby binding (https://rubygems.org/gems/kernaux/versions/0.1.0). It's version 0.1.0 partially covers stable API (only ntoa).

[kotovalexarian]

libkernaux 0.2.0 released!

Download: https://github.com/tailix/libkernaux/re ... 2.0.tar.gz
SHA256: 00b22e28ecddde5beca8b7d425d91eaf3634ee1d9df0bcf9565938d02353cd49

Breaking changes:

• ./configure - removed options to disable panic calls and returns in <kernaux/assert.h>
• <kernaux/assert.h> - removed preprocessor directives that can disable panic calls and returns

New stable APIs:

• <kernaux/cmdline.h> - simple command line parser

Other changes:

• Now ./configure options also follow semantic versioning
• Bug fixes in <kernaux/cmdline.h>
• Bug fixes in <kernaux/printf.h>

Ruby gem now covers all stable APIs of the library. Rust crate is still empty.

This release is made just to sharpen release process. Don't worry about breaking changes, they won't be made often. I hope that next version won't break anything, so it will have number 0.2.1.

[kotovalexarian]

libkernaux 0.3.0 released!

Download: https://github.com/tailix/libkernaux/re ... 3.0.tar.gz
SHA256: 6887939c01b65a4e864d47f103a06a6ad1639f4bffaa5582c95252c4646c8d2a

Actually nothing interesting here, still in early stage. See NEWS.md.