[haiku-development] Re: Haiku Userland on Non-Haiku Kernel
- From: Stephan <stephanwib@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 26 Feb 2015 07:43:22 +0100
Hi!
For those who are still interested: I have been very very busy during
the last days so there is not much progress.
Appserver and registrar are running on NetBSD console and (sometimes)
X. The appserver is not quite stable. When I launch an application,
registrar notices that but crashes immediately afterwards. I need a
full debug build of NetBSD (especially libc) to get that properly
debugged.
I read some cosmoe and Haiku source code to get a better
understanding, as well as some other documentation. IIUC all the stuff
cosmoe is trying to emulate is from the kernel kit - that´s where
ports, semaphores, areas etc. live in. That stuff usually lives in the
Haiku kernel while cosmoe puts that in userspace for emulation
purposes. The kernel kit is certainly the most important part. Above
is the app kit where all the basic primitives apps rely on is in - for
example BLooper and BLocker classes. I guess that the app kit pretty
much runs out of the box once the kernel kit is in place.
I´ve also investigated the NetBSD kernel code of semaphores and
message queues. I´ll certainly be able to borrow some ideas or code
when I create Haiku specific counterparts.
So long... ;)
2015-02-20 12:16 GMT+01:00 Stephan <stephanwib@xxxxxxxxxxxxxx>:
> Folks,
>
> this is a breakthrough on NetBSD:
>
> ==================
> ./appserver
> Perror: : Undefined error: 0
> Perror before: : Undefined error: 0
> initialize_before()
> initialize_before() done
> app: fMousePort
> app: fMessagePort
> app: FontServer
> FontServer::ScanDirectory(): opening /usr/share/fonts/ttf/cosmoe
> FontServer::ScanDirectory(): found entry .
> FontServer::ScanDirectory(): found entry ..
> FontServer::ScanDirectory(): found entry Vera.ttf
> FontServer::ScanDirectory(): found entry VeraBI.ttf
> FontServer::ScanDirectory(): found entry VeraBd.ttf
> FontServer::ScanDirectory(): found entry VeraIt.ttf
> FontServer::ScanDirectory(): found entry VeraMoBI.ttf
> FontServer::ScanDirectory(): found entry VeraMoBd.ttf
> FontServer::ScanDirectory(): found entry VeraMoIt.ttf
> FontServer::ScanDirectory(): found entry VeraMono.ttf
> FontServer::ScanDirectory(): found entry VeraSe.ttf
> FontServer::ScanDirectory(): found entry VeraSeBd.ttf
> FontServer::ScanDirectory(): found entry code_alt.ttf
> Directory '/usr/share/fonts/ttf/cosmoe' scanned, 11 fonts found
> app: InitDecorators
> app: Desktop
> Desktop: InitDesktop
> SDLDriver constructor
> Loading SDL Driver...
> SDL driver: initialize
> SDL driver: SDL_SetVideoMode
> SDL driver: input_thread
> SDL driver: UtilityBitmap
> SDL driver: SDL_WM_SetCaption
> SDL driver: SDL_ShowCursor
> SDL driver: exit - success
> SDL Driver succesfully initialized
> SDLDriver::FillSolidRect()
> app: CursorManager
> SDLDriver::CopyBitmap()
> app: BitmapManager
> Master area table key is 0x4100cdbf.
> app: app_server_active_sem
> app: app_server_applist_sem
> app: app_server_decor_sem
> app: PollerThread
> app: Picasso
> info: LinkMsgReader GetNextReply() reports 0 bytes remaining in buffer.
> info: LinkMsgReader reading port 4.
> info: LinkMsgReader GetNextReply() reports 0 bytes remaining in buffer.
> info: LinkMsgReader reading port 3.
> =========================
>
> =========================
> ./registrar
> Perror: : File exists
> initialize_before()
> initialize_before() done
> REG: main()
> Perror before: : File exists
> BApplication 1 called
> 1: fInitError = 0
> info: LinkMsgSender buffered header AS_CREATE_APP [0 1601401467 0].
> info: LinkMsgSender Flush() waiting to send 1 messages of 97 bytes on port 4.
> info: LinkMsgSender Flush() 1 messages total of 97 bytes on port 4.
> info: LinkMsgReader GetNextReply() reports 0 bytes remaining in buffer.
> info: LinkMsgReader reading port 9.
> info: LinkMsgReader read 32 bytes.
> info: LinkMsgReader got header SERVER_TRUE [32 1601401460 0] from port 9.
> 2: fInitError = 0
> 3: fInitError = 0
> 4: fInitError = 0
> 5: be_app and be_app_messenger
> 6: _init_interface_kit_
> info: LinkMsgSender buffered header AS_CREATE_BCURSOR [0 1601401488 0].
> info: LinkMsgSender Flush() waiting to send 1 messages of 100 bytes on port
> 10.
> info: LinkMsgSender Flush() 1 messages total of 100 bytes on port 10.
> info: LinkMsgReader GetNextReply() reports 0 bytes remaining in buffer.
> info: LinkMsgReader reading port 11.
> info: LinkMsgReader read 32 bytes.
> info: LinkMsgReader got header SERVER_TRUE [32 1601401460 0] from port 11.
> info: LinkMsgSender buffered header AS_CREATE_BCURSOR [0 1601401488 0].
> info: LinkMsgSender Flush() waiting to send 1 messages of 100 bytes on port
> 10.
> info: LinkMsgSender Flush() 1 messages total of 100 bytes on port 10.
> info: LinkMsgReader GetNextReply() reports 0 bytes remaining in buffer.
> info: LinkMsgReader reading port 267.
> info: LinkMsgReader read 32 bytes.
> info: LinkMsgReader got header SERVER_TRUE [32 1601401460 0] from port 267.
> 7: cursors created
> 8: fInitError = 0
> REG: Registrar()
> REG: app->Run()...
>
> ========================
>
> Problem was that cosmoe #defines SEMMSL to 250 in kits/kernel/sem.c.
> NetBSD, however, has a default SEMMSL of 60. That caused semget(key,
> SEMMSL, whatever) to fail. I´m on the remote X scenario which is known
> to not render correctly. I can see a misrendered mouse pointer which
> sometimes follows my mouse :) I will see later how it does on wscons.
>
>
> 2015-02-20 7:52 GMT+01:00 Stephan <stephanwib@xxxxxxxxxxxxxx>:
>> Hi folks
>>
>> Current state ist that my suspicion was right and the Semaphore/Ports
>> wrapper is broken on NetBSD. I had a Raspberry Pi 2 at hand with
>> Raspian and I gave it a try.
>>
>> =================
>>
>> get_sem_id: enter
>> get_sem_id: returned id 0
>> create_sem_etc: enter
>> create_sem_etc(): creating sem group 0
>> get_sem_id: enter
>> get_sem_id: returned id 1
>> create_sem_etc: enter
>> get_sem_id: enter
>> get_sem_id: returned id 2
>> create_sem_etc: enter
>> initialize_before()
>> Using key 5002b741 for the port table
>> The size of the port table is 18440 bytes
>> get_sem_id: enter
>> get_sem_id: returned id 3
>> create_sem_etc: enter
>> port_init: exit
>> get_sem_id: enter
>> get_sem_id: returned id 4
>> create_sem_etc: enter
>> get_sem_id: enter
>> get_sem_id: returned id 5
>> create_sem_etc: enter
>> get_sem_id: enter
>> get_sem_id: returned id 6
>> create_sem_etc: enter
>> acquire_sem_etc(3): enter
>> get_sem_id: enter
>> get_sem_id: returned id 7
>> create_sem_etc: enter
>> acquire_sem_etc(7): enter
>> release_sem_etc(3): enter
>> create_port: generated port queue key 16955201 from /proc/14772/exe + 1.
>> Port 0 named tmp_rport0 is using shm key 102b741
>> Port 0 is now attached successfully
>> ===================
>>
>> When I started the appserver, I saw a white stripe on the screen with
>> a big mouse pointer with a black stroke and no fill. I was even able
>> to move that pointer with my mouse.
>>
>> I turned back to NetBSD and invoked appserver again. I was surprised
>> to see a rectangle on the screen with the very same mouse pointer (I
>> wasn´t able to recognise this as a pointer previsously). It became
>> clear that the SDL to framebuffer rendering on Linux is broken while
>> it works correctly on NetBSD. I coudn´t move my mouse there, which is
>> not such a big surprise. Next step is to repair the wrapper on NetBSD
>> or ideally, implement this as a kernel level interface.
>>
>> So long
Other related posts:
