[openbeos] Re: Status of the Kits
- From: François Revol <revol@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 08 Apr 2003 17:56:25 +0200 (CEST)
En réponse à Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > Node locking was one of the missing things. _k[un]lock_node_() were
> > brought up on bedevtalk some time ago. I wonder if their return value
>
> > is int (+ errno) though. Node locking is still not implemented, but
> > it's not really a pressing issue.
>
> Exactly, it's sufficient when we do this with the real kernel
> interface.
>
FWIW:
00157e40 <Lock__5BNode>:
157e40: 55 push %ebp
157e41: 89 e5 mov %esp,%ebp
157e43: 53 push %ebx
157e44: e8 00 00 00 00 call 157e49 <Lock__5BNode+0x9>
157e49: 5b pop %ebx
157e4a: 81 c3 af 67 08 00 add $0x867af,%ebx
157e50: 8b 45 08 mov 0x8(%ebp),%eax
157e53: 8b 40 24 mov 0x24(%eax),%eax
157e56: 50 push %eax
157e57: e8 e8 f2 f1 ff call 77144 <._init+0x61f>
157e5c: 8b 5d fc mov 0xfffffffc(%ebp),%ebx
157e5f: 89 ec mov %ebp,%esp
157e61: 5d pop %ebp
157e62: c3 ret
BNode::Lock() does just that:
{
return _klock_node_(this->fFd);
}
and same for Unlock.
so the syscall here just return the same thing the BeBook documents
on BNode::Lock().
> > running a separate application), which is going to go away soon,
> > anyway. Don't know about the app server, though.
>
So as for app_server, I know it uses a system call to send back the
framebuffer config to the kernel which has symbol name curscreen IIRC, and
looks like this:
struct kfb_info {
void *fb;
uint32 width;
uint32 height;
uint32 bytes_per_row; // ?
uint32 unknown1;
uint32 bits_per_pixel; // ?
uint32 unknown2;
};
app_server exports this func (from C++):
0004d300 T set_kdebug_framebuffer(void *, long, long, long, long)
which supposedly calls the kernel.
I don't think it uses that more undocumented calls.
François.
Other related posts:
