Modular Kernel Source Possible?

[Steve Fendyke]

Heya

Basically, I have a problem with my kernel. It has a basic console at the moment and that's it. It doesn't use paging (yet) and it hasn't event got ISR/IDT support.

However, i noticed the source file was getting quite long. HOW can I split it into little chunks that can be compiled into separate .o files and then reconnected? If anyone could demonstrate how they could be split and give me the linker command to used i'd be chuffed.

Hope it's clear what i'm asking for! If not, just yell at me lol

Thanks in advance,

-Steve

[Pype.Clicker]

well, the process is quite well-known in any good-practice C book:

- split (conceptually) your file into modules
- write <module>.h files that declare what each module export to the rest of the world (functions, constants, structures, and other types)
- move code for each module to <module>.c files
- include <needed>.h in module that requires it so that the interface to the module is known
- use the "-c" flag for component compilation: you'll have a separate .o file for each .c you got.
- link them together with ld <all .o files> -o kernel

[Pype.Clicker]

that being said, replacing the 'if scancode == xxx' by a translation map will dramatically shorten your sourcecode

[Steve Fendyke]

Ah yeah. But wouldn't that mean that every time you compiled the main kernel you'd have to compile the input.c, the memory.c and so on? Or could you complile the main kernel seperately and then skip straight to the last step?

Thanks

-Steve

[Steve Fendyke]

Translation map? I'm not familiar with that term. How does that work?

I was ORIGINALLY going to set it out as an array. Then I opted for "switch, case" statements. But then I finally figured....let's make it simple and obvious for myself. It doesn't get simpler than "If" lol. So I kept there. I figured it was gonna get hard enough as is without making it more so lol. Thanks for the idea tho. I might change over now i've learnt some things.

-Steve

[Candy]

Translation map? I'm not familiar with that term. How does that work?

I was ORIGINALLY going to set it out as an array. Then I opted for "switch, case" statements. But then I finally figured....let's make it simple and obvious for myself. It doesn't get simpler than "If" lol. So I kept there. I figured it was gonna get hard enough as is without making it more so lol. Thanks for the idea tho. I might change over now i've learnt some things.

-Steve

A translation map is an array. You make an array with say 128 entries, in which each says what the key corresponding with that code should produce in <whatever charmap you use... usually ascii>. You then create a second, for shifted characters. That's all there's to it, and it shortens your code quite a bit.

[IRBMe]

Ah yeah. But wouldn't that mean that every time you compiled the main kernel you'd have to compile the input.c, the memory.c and so on? Or could you complile the main kernel seperately and then skip straight to the last step?

Not necessarily. The make utility and Makefiles come in handy here. Basically what make will do is only recompile the object files which are older than the c files they depend on (rules defined in Makefile). So if you only change memory.c then next time you build your kernel using make, only memory.c will be recompiled, and the object files will be relinked.

[Brendan]

Hi,

A translation map is an array. You make an array with say 128 entries, in which each says what the key corresponding with that code should produce in <whatever charmap you use... usually ascii>. You then create a second, for shifted characters. That's all there's to it, and it shortens your code quite a bit.

Close, but not quite - you'd need 4 arrays:
normal: 'A' key = 'a', '1' key = '1'
shifted: 'A' key = 'A', '1' key = '!'
capslock: 'A' key = 'A', '1' key = '1'
shift+caps: 'A' key = 'a', '1' key = '!'

To do it properly with switch/case and if/then you'd end up with a huge number of conditional branches, which will run slower and be harder to debug than tables/arrays.

Then one day you might start looking at internationalization, where you could just use different tables instead of rewriting all the code (for most keyboards). I guess I should point out that if you're interested in internationalization, the keyboard driver shouldn't be built into the kernel like this, or there should be some way of inserting other code between the keyboard driver and kernel. As an example, Japanese keyboards usually work in conjunction with a "visual aid", where the visual aid is used to select which word/symbol is meant based on the "syllables" typed in (otherwise they'd need keyboards with a few hundred thousand keys, one for each symbol/word/character).


Cheers,

Brendan

[Still Steve Fendyke]

Sorry, it's Steve Fendyke. I just can't log in as me at school.

"As an example, Japanese keyboards usually work in conjunction with a "visual aid", where the visual aid is used to select which word/symbol is meant based on the "syllables" typed in (otherwise they'd need keyboards with a few hundred thousand keys, one for each symbol/word/character)." - Oh, does that work like predictive text input on a mobile phone?

Once i've myself a nice table sorted out, I can't see any reason why I couldn't have one for each keyboard (for instance) and then let the user select which table to load into memory? For now though, i might just stick with a single 'bank' of four arrays for now. I think I can handle coding that.

Thanks for all the help guys,

-Steve

[Brendan]

Hi,

"As an example, Japanese keyboards usually work in conjunction with a "visual aid", where the visual aid is used to select which word/symbol is meant based on the "syllables" typed in (otherwise they'd need keyboards with a few hundred thousand keys, one for each symbol/word/character)." - Oh, does that work like predictive text input on a mobile phone?

Yes (at least I think so, even though I'm not Japanese, Chinese, Korean, etc and I've never used the predictive text input on a mobile phone ).

Basic idea would be that when one key is pressed a list of all possible symbols/words is presented, sorted from most likely to least likely. As more keys are pressed this list is reduced.

Once i've myself a nice table sorted out, I can't see any reason why I couldn't have one for each keyboard (for instance) and then let the user select which table to load into memory?

If you're considering Unicode (which would be needed for non-latin keyboards/characters), then you'd need tables with at least 3 bytes per scancode. You might aswell call it 4 bytes per scancode so you can have 8 flags to use for various things. So, one keyboard type becomes 4*128*4 bytes, or 2 Kb. There's at least 118 keyboard types (as supported by Microsoft: http://www.microsoft.com/globaldev/refe ... oards.aspx), so you'd be looking at using 236 Kb just for the keyboard tables.

On top of this you'd need to support some variations, for e.g. US keyboards have two "Alt" keys, while a lot of keyboards have one "Alt" key and one "AltGr" key, where the "AltGr" is used to select completely different characters. To support this you may need to use twice as many tables...

Have a play with Microsoft's keyboard layouts (the link above) - it'll show you each keyboard layout and which characters are generated when certain control keys are pressed.

Then there's the extra "visual aids" for all languages that have one symbol per word, and support for USB keyboards (and scanning the USB devices).

Now the reason I'm dribbling on like this is that (IMHO) you're going to have to make a choice between 3 options. First option is to create a huge monolithic kernel that contains everything (ie. support for all devices including all keyboards). I don't consider this sane as the kernel would end up being too large for most computers to load!

The next option is to force your users to recompile the kernel to suit the hardware. Depending on the target audience for your OS (and if you want to distribute the kernel as source code) this might be a good approach.

The last option is to load the correct device drivers for the hardware during boot (either using a config file or auto-detecting). This is how all modern OS's (that I know of) do it. This even includes Linux for an increasing number of devices, even though they started with the previous "compile before use" option (note: Linux isn't modern, the general design of Unix & derivatives dates back to the 1960's).

So, do you really want any keyboard and/or video code in your kernel?

For now though, i might just stick with a single 'bank' of four arrays for now. I think I can handle coding that.

Despite everything I wrote, I think this is a good idea to begin with - it makes it easier to debug, etc and looks more impressive than a screen full of text that doesn't respond to the user .


Cheers,

Brendan

[mystran]

Close, but not quite - you'd need 4 arrays:
normal: 'A' key = 'a', '1' key = '1'
shifted: 'A' key = 'A', '1' key = '!'
capslock: 'A' key = 'A', '1' key = '1'
shift+caps: 'A' key = 'a', '1' key = '!'

Except typing @?${[]}\~ (to start with) on (say) Finnish keyboard, you also need to use AltGR. So you actually need:
1 map for normal
1 map for shifted
1 map for caps
1 map for caps/shift
1 map for altGR (or mode_switch or whatever you call it)

Also sometimes Altgr and altgr + shift are mapped to different values so that's one map more. Then you also might want to think about the numpad in some way?

[Candy]

Close, but not quite - you'd need 4 arrays:
normal: 'A' key = 'a', '1' key = '1'
shifted: 'A' key = 'A', '1' key = '!'
capslock: 'A' key = 'A', '1' key = '1'
shift+caps: 'A' key = 'a', '1' key = '!'

Except typing @?${[]}\~ (to start with) on (say) Finnish keyboard, you also need to use AltGR. So you actually need:
1 map for normal
1 map for shifted
1 map for caps
1 map for caps/shift
1 map for altGR (or mode_switch or whatever you call it)

Also sometimes Altgr and altgr + shift are mapped to different values so that's one map more. Then you also might want to think about the numpad in some way?

How about:

1 map for normal
1 map for shifted
1 map for altGR
1 map for altGR/shift
1 map for caps-inverses-shift bools

The last indicates of shift-caps brings normal or shift (false would be shifted (say, 0), true would be normal (say, A)). This brings the full combination and only takes 4*256 + 256/8 = 1024 + 32 = 1056 bytes of load. For normal languages (without a huge set of other buttons or syllables or word-images or hieroglyphs or ligatures).

[Solar]

There's at least 118 keyboard types (as supported by Microsoft: http://www.microsoft.com/globaldev/refe ... oards.aspx), so you'd be looking at using 236 Kb just for the keyboard tables.

You're thinking so monolithic here... how about a well-defined interface for (runtime-loadable) /usr/share/keymaps/...?

[Steve Fendyke]

The next option is to force your users to recompile the kernel to suit the hardware. Depending on the target audience for your OS (and if you want to distribute the kernel as source code) this might be a good approach.

To me that makes more sense. And like you demonstrated with Linux, that doesn't mean the code has to stay like that. I can always change it and make it more user-friendly as and when I find that that's required. And it will be open source. I don't know which "licence" or whatever yet. But however it ends up, i'll make it free to anyone who happens to want to see it, and maybe learn from it

Not to mention, the chances are that a person using a chinese keyboard will be chinese, or a german keyboard will be german. I couldn't very well support all sorts of keyboard but only have the console display in English. Wouldn't exactly be internationalisation!

I'm going to get working on putting some of those of arrays into practice. Thanks to everyone who's helped me out here. It's given me lots of ideas. Even if I don't put them into effect now, it's given me something to think about.

Cheers.

-Steve

[Solar]

Not to mention, the chances are that a person using a chinese keyboard will be chinese, or a german keyboard will be german. I couldn't very well support all sorts of keyboard but only have the console display in English. Wouldn't exactly be internationalisation!

Being German, I tell you that not having Umlaute displayed by the console is quite OK if at least the special characters (=, ?, +, *, |, <, >, ...) are in the right places. I have learned the US keyboard layout by now, but you can surely imagine how troublesome it is for a not-so-geeky type to find that shift-8 through shift-9 have changed from ()= (German) to *() (English) - especially if you are a quick typer...