[openbeos] Re: building not so custom targets
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 24 Dec 2003 14:17:13 +0100 CET
Hi Jérôme,
Jérôme Duval <korli@xxxxxxxx> wrote:
> 1/ i need to build two targets with the same files.
> Should i do something like this ? Am i sure it'll CC two times the
> file.c and
> not reuse the first one ? Is it the way to do this ?
>
> {
> SubDirCcFlags -DPROG1 -Wall -Wno-multichar ;
> SubDirC++Flags -DPROG1 -Wall -Wno-multichar ;
> }
>
> R5KernelAddon prog1 : bin :
> file.c ;
>
> {
> SubDirCcFlags -DPROG2 -Wall -Wno-multichar ;
> SubDirC++Flags -DPROG2 -Wall -Wno-multichar ;
> }
>
> R5KernelAddon prog2 : bin :
> file.c ;
AFAICT this is not possible, as the object file.o would be compiled
into the same directory, and thus, would overwrite itself. Only one of
the two files would be correct.
You have to put the Jamfiles into two different directories. Have a
look at the src/tests/add-ons/kernel/file_systems/bfs/* directories,
to see how you can do this.
> 2/ How can i extend the #include search to subdirectories ?
> #include "file.h" // file.h is in a subdirectory
See src/kernel/boot/loader/file_systems/bfs:
UsePrivateHeaders [ FDirName storage ] ;
SubDirHdrs $(OBOS_TOP) src add-ons kernel file_systems bfs ;
> 3/ How can i extend source search to subdirectories or a subdirectory
> of the
> parent directory ?
> R5KernelAddon prog1 : bin :
> file.c ; # file.c is in a subdirectory
Have a look in the test sources for BFS, it's that part:
SEARCH on [ FGristFiles
... source files ...
] = [ FDirName $(OBOS_TOP) src add-ons kernel file_systems bfs ] ;
> 4/ Is it mandatory to use locked memory (not with malloc) in
> interrupt handlers
> ?
I am not sure about BeOS there, AFAIK it does not page out memory
malloc'd in the kernel, but I haven't made any tests to prove that (if
someone knows it for sure, please speak up).
However, for OpenBeOS, I wanted to follow the Be model (we have to for
compatibility), and add an allocator that returns memory that can be
paged out.
> 5/ Using cpp in kernel drivers seems possible. Is it just including
> kernel_cpp.h
> and linking kernel_cpp.cpp ? are there some issues i should know
> (virtual
> functions, exporting compliant drivers symbols in a cpp file... ) ?
> R5KernelAddon udf : bin :
> kernel_cpp.cpp
> file.cpp
>
> SEARCH on [ FGristFiles
> kernel_cpp.cpp
> ] = [ FDirName $(OBOS_TOP) src kernel core util ] ;
BTW doesn't this answer your question number 3)?
Anyway, that's enough to get C++ into the driver. I still have to write
a newsletter article about that...
But in a nutshell IIRC, you currently can't have exceptions nor RTTI in
the kernel easily, at least the above method does not support this.
However virtual functions can be used (just the typeid()/dynamic_cast<>
() stuff doesn't work).
Bye & Merry Christmas,
Axel.
Other related posts:
