OSDev.org

The title is extremely vague beacuse i don't know how to come with other title, there's no word that can describe it in a short way. Sorry, i apologize.

My keyboard handler seems to be stubborn and either spams my terminal_putchar() function (in a loop) or only tries to find it one time and fails beacuse i'm pretty sure i can't press a key in a single CPU clock tick (not in a loop).

I've tried putting io_wait() (no difference), putting a return with absolutely nothing to return (no difference).

How do i fix this?

If you want to see my code, https://github.com/NunoLava1998/DixiumOS.

Your code is copied from somewhere.
You didn't understood that it must be a keyboard IRQ handler function, not a function that you call as a getchar().
You blame your keyboard driver instead of yourself.

Nuno, you need to learn to write code yourself instead of copying it.

Why does your "include" folder contain source files? Also why do you need "cpuid" and "farpeekw" for your keyboard handler. It is obvious that the code is copied from somewhere. Try writing your own code instead of following no sense tutorials. You just put some random bunch of crap in a file and expected it to work. I would suggest you checking your IDT, IRQ and ISR routines, they are very very important. Without having them working in the first place don't expect your OS to work as expected. You should make a PIT controller before trying to do anything keyboard related just to make sure your interrupts are firing.

mainf is a "main functions C file", not my keyboard handler. I put functions that are not used just in case i need them later.

Yes it is copied from Inline Assembly/Examples (in OSDev).

Also, this compiled without problem:

Working > compiling.

Nuno, did you ever read this essay any of the previous times I directed you towards it, and if you did, did you have trouble understanding it? If you understood it (or think you did), why do you continue to put code in header files?

You might have a reason for doing this, and for the life of me, it could even be a good one. I can't see it as very likely, but I am willing to grant you the benefit of the doubt (despite my better judgment). However, if you are going to do something like that, something which blatantly goes against generally accepted best practices for C and C++ programming, you damn well better explain it somewhere in the comments or code documentation, and be prepared to justify it to anyone else you show the code to.

Programming rules and guidelines exist for a reason, and in a context; they represent the experience of others in what does and does not work. It is fine to break them when the following it doesn't make sense, but if you are going to break one, you need to have a reason why following the rule would make things worse than not following it.

Uh, defs.h is literally the equivalent of cdefs.h in Meaty Skeleton...


Also the essay clearly shows a header file with this code would work perfectly and be a actually-correctly-used-header-file.

Never mind; I misread what Octocone had written. I apologize for the accusation.

However, his point - that the include directory has source code in it - is still salient, even if the 'rule' is less cut and dried. It is up to you how you organize your source code directories, but it is going to confuse people trying to help you if you have a directory marked 'include' that contains the source code as well as the headers. This is something that was pointed out more than one before, and while you are free to do what you choose in that regard, it is going to make it difficult for the rest of us to help you, if only because it is confusing.

The usual practice is to have all (or at least most) of the header files in a single include directory, and have the code that corresponds to them in a separate hierarchy under something such as src. This would give something like:



Noiw, you don't have to follow this layout; it is a Common Practice adopted by most others, and unlike a Best Practice, it is based on conventional rather than from any pragmatic need. However, following a Common Practice eliminates the need to explain why you did something one way an not another; it makes things simpler if you do it, at least for the people who are trying to help you.

The practical upshot of this is that, while you don't necessarily need to justify the decision to break a Common Practice (as you would when breaking a Best Practice), it would really help if you at least explained the model or pattern you are using.

On a side note: it doesn't look as if you have been checking in changes to your code. Generally speaking, any time you have a change to your code, even if it isn't complete, you want to check the change into the repository when you stop working on it, or whenever you reach some significant (to you) milestone. Right now, the code in the repo hasn't been updated in over a month, so anything you've done since then isn't recorded. Since two of the main purposes of a repo are to a) save an offsite copy of the work in case of an accident (e.g., you have a drive failure, you accidentally delete a file, or make changes that have to be reverted because they didn't work out) and b) keep a record of how the code changes over time, you are basically operating without a repo at all, at least since the middle of November. When you are actively changing your code, you want to commit to your local repo as often as you can, to give a fine-grained record of the changes, and push to the offsite repo at least once at the end of every coding session.

I made a new coding repo named DixiumOS (old one was dixium).

https://github.com/NunoLava1998/DixiumOS is the new one,
https://github.com/NunoLava1998/dixium is the old one.

I prefer to keep my current style beacuse in that style i'll have to do this solution which may not work and is confusing...



The reason i put "" around the path is beacuse <> is for our cross compiler's include files, however "" is for the current directory.
So if you have superamazingheader.dll in the current directory and try to call it using
include <superamazingheader.dll> would work if you put it in the include directory of the compiler, but not in this case
include "superamazingheader.dll" would work if it is in the current directory (which means it would work).

(yes, dll is a type of header, seriously.)

Actually, you can configure your cross compiler to use your include/ directory (or sysroot), then you can still do the pointy brackets.
Or you can pass the "-I kernel/include/" flag to GCC. That's what I do.

I didn't know about that, but for simplicity, i'll keep my current design.


Anyway, let's resume our question.

bump; thread has been inactive for 24-36 hours.

But it was still on the front page.

There are not many questions in the OSDev forum, as there are not many people that OSDev.
It is normal for this to stay on the front page.

Anyway, can we resume to the question?

The original question has already been answered, and in the very first reply to this thread. Your keyboard handler doesn't work because the code you copied is supposed to run in response to a keyboard IRQ, but you're trying to run it when the kernel starts (or in a loop).