Os Libraries collection

[AlfaOmega08]

Hello Os Developers! I'm trying to collect (or rewrite) a set of classes which can be used in operating systems. I hope these classes are going to help you in your os coding.

All the classes must follow a set of rules:
The class should be as complete as possible ignoring only old and unused features (like all the varities of GDT types, use only Code, Data and TSS instead)
Good names to classes, functions and variables
Functions should be as short as possible and avoid side effects (low cyclomatic complexity)
Parameters shall be checked for correctness
Functions shall never return NULL or 0. We throw an exception instead
Often good code is better than comments and self-descriptive. However we use comments when code is not crystal clear.
Rigid style: tabs, braces on new line on the same column, one statement per line, spaces between if, while, for, etc and () but not between function name and parentesis.
Code must be portable (can be compiled on any compiler)*
The class itself should have few or none dipendences (class coupling).

Optionally we'll provide unit tests for the gTest framework to check the code.

I'm hosting classes at http://oslibs.altervista.org . Feel free to comment, to signale a bug or error, or suggest a new class.

Actually only some Gdt classes are available but I'm planning many others. Well... what do you think?

[JamesM]

Functions shall never return NULL or 0. We throw an exception instead

Never use exceptions in a kernel. The handling mechanisms are not (kernel) thread safe - they rely on TLS.

Also, exceptions are EXTREMELY SLOW. Zero-cost only applies to the hot path - as soon as you take an exception you smash your cache loading the exception tables

[Solar]

Also, exceptions are EXTREMELY SLOW. Zero-cost only applies to the hot path - as soon as you take an exception you smash your cache loading the exception tables

While I disagree with the original poster's requirement about not returning 0 or NULL: Exceptions are not significantly slower than appropriate and complete error handling done a different way. You still have to deconstruct all objects you no longer need, you still have to come up with some appropriate error message, and outside of the hot path the performance hit of an exception shouldn't make that much of a difference.

There are arguments against exceptions in kernel space, but a blanket statement that "they are extremly slow" simply doesn't fit.

@ OP: C++ isn't the first choice for kernel work for many here. Requiring exception support further reduces your audience...

[JamesM]

Also, exceptions are EXTREMELY SLOW. Zero-cost only applies to the hot path - as soon as you take an exception you smash your cache loading the exception tables

While I disagree with the original poster's requirement about not returning 0 or NULL: Exceptions are not significantly slower than appropriate and complete error handling done a different way. You still have to deconstruct all objects you no longer need, you still have to come up with some appropriate error message, and outside of the hot path the performance hit of an exception shouldn't make that much of a difference.

There are arguments against exceptions in kernel space, but a blanket statement that "they are extremly slow" simply doesn't fit.

@ OP: C++ isn't the first choice for kernel work for many here. Requiring exception support further reduces your audience...

I didn't mention deconstructing any objects, or general cleanup. I did mention parsing and trawling the EH tables, which, as I mentioned, is a cache killer. Exceptions should be exceptional.

[AlfaOmega08]

While I disagree with the original poster's requirement about not returning 0 or NULL

Returning 0 or NULL is harmful. The caller must remember to check the return value. If it doesn't the error will propagate, probably provoking a fault.
Exceptions instead must be handled in a way or another.

[Solar]

Exceptions should be exceptional.

No disagreement there.

Returning 0 or NULL is harmful.

See JamesM's post. Exceptions should be exceptional. While I might go along so-so with NULL being a potential killer, returning zero (or some other out-of-domain value, like EOF) is simply the way to signal non-exceptional failure of some kind.

The caller must remember to check the return value. If it doesn't the error will propagate, probably provoking a fault.

And if the caller does not add a catch block, there will be a terminate(). If the caller does not add a catch block in the right position, there will be a meaningless error message and no way to properly recover from the failure. The end result - especially in kernel space where you cannot simply "abort & retry" - is the same as for a rogue NULL pointer: You just lost your OS session, see you again after reboot.

Exceptions are not a magic band-aid for shoddy programming. They are a nice tool in object-oriented programming, but enforcing them for a general purpose, kernel space library collection, by forbidding functions to return 0 or NULL, is a Code Smell (tm).

[AlfaOmega08]

Exceptions should be exceptional.

No disagreement there.

Neither I.

Returning 0 or NULL is harmful.

See JamesM's post. Exceptions should be exceptional. While I might go along so-so with NULL being a potential killer, returning zero (or some other out-of-domain value, like EOF) is simply the way to signal non-exceptional failure of some kind.

I didn't mean to say that a function can't always return 0. Sure it can. I meant 0 should not be used like a null alias. For function where 0 is natural to be returned it's ok. If you look at the code you'll notice that exceptions are used if arguments are invalid only. Isn't that exceptional?

However, do you think I should avoid using exceptions? I love returning void instead of an error code... and it makes the code more clear than a return -24235, with a descriptive message and all...

[AlfaOmega08]

All the code here is distributed according to the CC-BY-SA and/or GPLv3 licenses.

No, thank you, but I will not be using this any time soon.

Can you please give more details about this?
And the "Whoa" thing, I suppose it was because of the unsigned int * right? I wrote it before creating a TSS class so unsigned int seemed the most simple type since void * isn't accepted by delete... going to fix it anyway...

[Solar]

Code: Select all

#pragma pack(2)
class TaskStateSegment
{
public:
	TaskStateSegment() {};
	TaskStateSegment(const TaskStateSegment &copy) {};
	~TaskStateSegment() {};

private:
	int Res1;
	unsigned long long rsp0;
	unsigned long long Res2[11];
	unsigned short Res3;
	unsigned short bmpOffset;
};
#pragma pack(8)

• How does #pragma go along with your requirement to "compile on any compiler"? In DescriptorTableRegister.h you mention that #pragma pack is for MSVC, and that __attribute__((packed)) is for GCC, but don't use either of them. Be consistent.
• I am not even sure you can pack a class like that. (A struct, yes, but a class? Might be, I am not sure.)
• Your copy constructor is empty, i.e. nothing will be copied...
• You are aware that what you have there is a data structure with no way to access the data members?

And the stuff is completely undocumented. I don't care how "clean" your source may be, I expect a C++ header to contain proper documentation of all of a class' functions since I don't want to look up the code to find out what I am expected to do with it. YMMV, but that's me.

Oh, and +1 on the "no viral license in my kernel" thing.

[JamesM]

Yes, you can pack a class, in C++ the only difference between class and struct is the default access. Class has private by default, while struct has public.
struct Test { virtual void test() = 0; }; is perfectly valid.

You can pack it as long as it has POD type. Add virtual functions and the compiler could blow up.

[AlfaOmega08]

You can pack it as long as it has POD type. Add virtual functions and the compiler could blow up.

That's correct. If you run the tests, it is successful if the class is "#pragma pack"ed or __attribute__((packed)) and a failure if not.

How does #pragma go along with your requirement to "compile on any compiler"? In DescriptorTableRegister.h you mention that #pragma pack is for MSVC, and that __attribute__((packed)) is for GCC, but don't use either of them. Be consistent.

I wrote the TaskStateSegment very quickly, not paying much attention. It was just to use it in the Gdt::TssDescriptor class. I'm still working on that.

Your copy constructor is empty, i.e. nothing will be copied...
You are aware that what you have there is a data structure with no way to access the data members?

See above.

Oh, and +1 on the "no viral license in my kernel" thing.

Well... I tought to use GPL3 and CC-BY-SA, being (IMHO) the two most appreciated licenses in the open source world. Suggestions are appreciated...

And the stuff is completely undocumented. I don't care how "clean" your source may be, I expect a C++ header to contain proper documentation of all of a class' functions since I don't want to look up the code to find out what I am expected to do with it.

I read many times that good naming can substitute comments. And that commenting every function or variable can be verbose. What will a Gdt::Descriptor::getBase do? I believe it's quite intuitive...

However, those classes are just examples. I setup the website in a hour, wrote the classes pretty quickly just to give an impression of how it should look like. That said I appreciate your signalations and I'm going to correct my inconsistences...

[JamesM]

You can pack it as long as it has POD type. Add virtual functions and the compiler could blow up.

This particular class isn't going to have any.

I know; I was merely adding the caveat for the curious.

[Solar]

Well... I tought to use GPL3 and CC-BY-SA, being (IMHO) the two most appreciated licenses in the open source world. Suggestions are appreciated...

As being said, viral licenses won't do because they take away other people's ability to use a license of their own chosing for their kernel. Public Domain or BSD-alikes are the "nicest" licenses out there. I wrote about that elsewhere.

I read many times that good naming can substitute comments.

It can, but it doesn't always. Especially with C / C++, where you have seperate header files, these headers should

• contain the absolute minimum amount of code, and
• not leave any questions unanswered.

However, those classes are just examples. I setup the website in a hour, wrote the classes pretty quickly just to give an impression of how it should look like.

Accepted.