[openbeos] Re: SK: interacting modules
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 14 May 2002 18:09:28 CEST (+0200)
> On Tue, 14 May 2002, Bruno G. Albuquerque wrote:
> Alright, but who actually sends the notification messages? I somehow
> doubt
> that the kernel does...
It seems that I was wrong:
I've written a small test programm that opens a live query and waits 10
seconds for an incoming message; that's what it got:
118 bytes read:
31424f46 518589bd 76000000 44505551 1BOFQ...v...DPUQ
03393000 000f474e 4f4c0406 6f70636f .90...GNOL..opco
64650100 00000f47 4e4f4c04 06646576 de.....GNOL..dev
69636504 0000000f 474e4c4c 08096469 ice.....GNLL..di
72656374 6f7279c0 02080000 0000000f rectory.........
474e4c4c 08046e6f 64650700 08000000 GNLL..node......
00000b52 54534308 046e616d 65080000 ...RTSC..name...
006d7573 0000 .mus..
And that's obviously a flattened BMessage!
That message was triggered by a live query update from the original BFS
(since ours doesn't implement live queries right now).
But its query_open() function got the same port id as I specified in my
test app, so there is no other entity involved.
Another hint is the fact that I tested this on a Dano system; the
flattened BMessage format isn't compatible with the old one there (and
starts with 2BOFQ) - so it's the kernel which generates that BMessage,
and it's still generating old style flattened BMessages under Dano :-)
So, the kernel *is* able to produce flattened BMessages!
Adios...
Axel.
Other related posts:
