benefit of writing kernel in c++

[lemonyii]

i fixed it with --no-exceptions. thank you!
and i have some more problems.
this is my TSS (copied from linux2.6.2):

Code: Select all

struct x86_64_tss {
                U32    Reserved1;
                U64    Rsp0;
                U64    Rsp1;
                U64    Rsp2;
                U64    Reserved2;
                U64    IST[7];
                U32    Reserved3;
                U32    Reserved4;
                U16    Reserved5;
                U16    IoBmpBase;
}__attribute__((packed)) ____cacheline_aligned;

there will be some faults with c++, which i have never met in C:

Trive/microk/mm.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here
Trive/microk/proc.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here
Trive/microk/kmain.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here

in fact i have only one tss in hw.cpp:

Code: Select all

LOCAL VOID X64Init(){
    U64 x,y;
    static struct x86_64_tss Tss;
    .....
}

i have fixed it with
__attribute__((packed,align(4096)));// ____cacheline_aligned;
but i don't feel good.
is the method proper or is 4096 proper?

and another question:

Trive/fs/filesystem.cpp:77: warning: deprecated conversion from string constant to ‘WCHAR*’

i got such warnings at such places:

Code: Select all

        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));
        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));
        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));

my definition:

Code: Select all

typedef wchar_t WCHAR;
GLOBAL I64 printk(WCHAR *str,...);

i can't understand what's wrong with it. do i have to use STRING class or sth else?

thank you,
lemonyii

[pcmattman]

and i have some more problems.
this is my TSS (copied from linux2.6.2):

Code: Select all

struct x86_64_tss {
                U32    Reserved1;
                U64    Rsp0;
                U64    Rsp1;
                U64    Rsp2;
                U64    Reserved2;
                U64    IST[7];
                U32    Reserved3;
                U32    Reserved4;
                U16    Reserved5;
                U16    IoBmpBase;
}__attribute__((packed)) ____cacheline_aligned;

there will be some faults with c++, which i have never met in C:

Trive/microk/mm.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here
Trive/microk/proc.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here
Trive/microk/kmain.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here

If ____cacheline_aligned isn't a #define of an attribute, you're actually creating a variable of type x86_64_tss called ____cacheline_aligned - however many times you #include the header containing it.

I'm struggling to figure out what are you intending to do here - care to clarify?

[Candy]

Code: Select all

}__attribute__((packed)) ____cacheline_aligned;

there will be some faults with c++, which i have never met in C:

Trive/microk/mm.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here
Trive/microk/proc.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here
Trive/microk/kmain.o:(.bss+0x0): multiple definition of `____cacheline_aligned'
Trive/microk/hw.o:(.bss+0x0): first defined here

in fact i have only one tss in hw.cpp:

Code: Select all

LOCAL VOID X64Init(){
    U64 x,y;
    static struct x86_64_tss Tss;
    .....
}

i have fixed it with
__attribute__((packed,align(4096)));// ____cacheline_aligned;
but i don't feel good.
is the method proper or is 4096 proper?

How big a cache line is depends on your processor. 4096 is sufficient for the coming while.

and another question:

Trive/fs/filesystem.cpp:77: warning: deprecated conversion from string constant to ‘WCHAR*’

i got such warnings at such places:

Code: Select all

        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));
        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));
        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));

my definition:

Code: Select all

typedef wchar_t WCHAR;
GLOBAL I64 printk(WCHAR *str,...);

i can't understand what's wrong with it. do i have to use STRING class or sth else?

It's telling you that a conversion from "....sdfoijaosg" to a *non-const* pointer is invalid. Make your pointer point to a const WCHAR.

Why WCHAR by the way? What's wrong with wchar_t ?

[Solar]

Trive/fs/filesystem.cpp:77: warning: deprecated conversion from string constant to ‘WCHAR*’

i got such warnings at such places:

Code: Select all

        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));
        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));
        printk(L"\nFS %x : 分配测试: %x ",pMe,base=mallock(pMe,1020));

my definition:

Code: Select all

typedef wchar_t WCHAR;
GLOBAL I64 printk(WCHAR *str,...);

i can't understand what's wrong with it. do i have to use STRING class or sth else?

A string literal - "like this" - gets stored in either the .text or the .rodata section of your binary. Both are "read only", i.e. the memory where "like this" resides cannot be written to. It is constant, char const * (or, in your case, wchar_t const *).

Your definition...

Code: Select all

GLOBAL I64 printk(WCHAR *str,...);

...however takes a pointer (str) to non-constant memory, i.e. your function gives no guarantee that it won't write to the memory pointed to. Now, if you pass a string literal to printk(), your compiler sees a potentially fatal problem coming up (printk() attempting to write to read-only memory), and warns you about it.

Earlier compiler / language versions allowed the implicit conversion from const to non-const in this case, but it has been deprecated, as the compiler warning says.

The solution? Const correctness. Whenever a function does not chance one of its parameters, declare it const. A practice that avoids several other kinds of errors, too.

Besides, indeed why "WCHAR"? The C language has established many typedefs, like wchar_t or uint32_t, which are readily available for your use. And even if, for lack of a standard library, you don't have <wchar.h> or <stdint.h> or <inttypes.h> at hand, it would be good practice to use typedef names that don't arbitrarily derive from the standard, because it just makes your source harder to read.

[lemonyii]

thank you.

If ____cacheline_aligned isn't a #define of an attribute, you're actually creating a variable of type x86_64_tss called ____cacheline_aligned - however many times you #include the header containing it.
I'm struggling to figure out what are you intending to do here - care to clarify?

yeah, i understood. but how can i add both attributes together?

It's telling you that a conversion from "....sdfoijaosg" to a *non-const* pointer is invalid. Make your pointer point to a const WCHAR.
Why WCHAR by the way? What's wrong with wchar_t ?

The solution? Const correctness. Whenever a function does not chance one of its parameters, declare it const. A practice that avoids several other kinds of errors, too.

Besides, indeed why "WCHAR"? The C language has established many typedefs, like wchar_t or uint32_t, which are readily available for your use. And even if, for lack of a standard library, you don't have <wchar.h> or <stdint.h> or <inttypes.h> at hand, it would be good practice to use typedef names that don't arbitrarily derive from the standard, because it just makes your source harder to read.

i corrected it with
printk(WCHAR const* str,...);
but what if i want a non-constant pointer point to a wchar_t* ? say, if my device have a predefined name like "DEV0001", but i may point to some other name like "/dev/hd(0,1)", which may be changed by driver?
why "WCHAR"? because i dont like things like "size_t, wchar_t, uint32_t", especially the suffix "_t", i hate it.
and for these things, i have a header file, which should be included only after my config.h.

Code: Select all

/*================================================
			Trive.h
				lemonyii,2010-04-17
=================================================*/
#ifndef _TRIVE_H_
#define _TRIVE_H_

#ifndef TRIVE
#define TRIVE
#endif 

#ifndef CONST
#define CONST const
#endif 

#ifndef NULL
#define NULL 0ull
#endif 

#ifndef FALSE
#define FALSE 0
#endif 

#ifndef TRUE
#define TRUE 1
#endif 

#define GLOBAL 	extern
#define LOCAL	static

typedef char I8;
typedef unsigned char U8;
typedef short I16;
typedef unsigned short U16;
typedef int I32;
typedef unsigned int U32;
typedef long long I64;
typedef unsigned long long U64;

typedef void VOID;
typedef U64 STATUS;
typedef wchar_t WCHAR;
typedef struct string{
	WCHAR	*pStr;
	U32		Len;
	U32		MaxLen;
	}__attribute__((packed))STRING;

i redefined all the basic types and things like extern. i think it is much easier to understand. and if any advice, i hope you can post here.

and thank you all above and following.
to the german guy, your football team is so united! i'm conqued by it!
lemonyii

[Solar]

but what if i want a non-constant pointer point to a wchar_t* ? say, if my device have a predefined name like "DEV0001", but i may point to some other name like "/dev/hd(0,1)", which may be changed by driver?

If it's changed by the driver, you must not pass string literals to it. In that case, the warning is telling you of a run-time problem at compile time, and you should be thankful for it.

If you have to feed the contents of string literals as non-const function parameters, copy the literal into non-const memory first.

why "WCHAR"? because i dont like things like "size_t, wchar_t, uint32_t", especially the suffix "_t", i hate it.

Well, too bad - that's how the language does it.

I don't do this here either...

Code: Select all

#define BEGIN {
#define END }

...just because I'm a fan of Pascal.

Code: Select all

#ifndef CONST
#define CONST const
#endif 

I know what "const" means. I have to look up "CONST" first if I want to be sure.

Code: Select all

#ifndef NULL
#define NULL 0ull
#endif

Now I've got to check includes and scope to find out whether "NULL" is really "NULL" or whatever you defined it to. Indeed, NULL might have two different types depending of context...

#ifndef FALSE
#define FALSE 0
#endif

#ifndef TRUE
#define TRUE 1
#endif

"true" and "false" are keywords in C++, and C has <stdbool.h> for the purpose...

[const]#define GLOBAL extern
#define LOCAL static[/const]

It gets even better: Now I can have LOCAL member variables! Uh... just that "local" doesn't make any sense there.

i redefined all the basic types and things like extern. i think it is much easier to understand.

Only for you, everybody else has to cope with source that doesn't look like "usual" C++.

I don't want to press this too much, but sticking with how the language does things is important. If you don't like how a language works, chose another, but don't try to redefine the language "your way". It will bite you, if only because it makes it harder for you to understand other people's code.

[lemonyii]

yeah, thank you so much.
things like NULL, TRUE, FALSE was defined in c previously, because they are not defined.
and LOCAL is really a big mistake.
and they are easy to be corrected with notepad++, as the code is still not too much, and i'm still familiar with every line of my code.
but i'll still remain things like U64 and WCHAR. and it is easy enough to understand, just like "DWORD" in windows.


ps: if i dont define NULL, the compiler will tell me "undefined symbol", is it native like true and false?(i use exactly "NULL")

thank you so much!
lemonyii

[Solar]

things like NULL, TRUE, FALSE was defined in c previously, because they are not defined.

Did you get the hint to look at <stddef.h>, <stdbool.h> and their ilk?

but i'll still remain things like U64 and WCHAR. and it is easy enough to understand, just like "DWORD" in windows.

I will freely admit that I'd have to look that one up, too.

But it's of course your design decision to make.

[lemonyii]

oh, NULL is solved, too.
my next step, is to continue writing my kernel, and modify some place as needed.
thank you all above!
lemonyii