[haiku-gsoc] Re: [HCD]: xsi semaphore - kernel side

2008/6/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>
> On 2008-06-15 at 23:26:45 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
> wrote:
>>
>> time for me to use this mailing list.
>>
>> I'm looking at the current implementation of haiku semaphore and I see that
>> during boot a few pages, it depends on the number of semaphore, is allocated
>> in order to store semaphore slots. I guess for performances reason.
>>
>> Now I'm wondering if I should do the same for the xsi semaphore, even though
>> only ported application (currently none) will used it, or create them run
>> time
>> when I needed? The latter would avoid waisting a few MB of probably
>> unneeded memory
>> when xsi semaphore are not used.
>
> Please just use a hash table (key_t -> semaphore object).

Ok. The only thing I haven't understand with the standard yet though,
is whether the key_t table
should be shared among IPC primitives (semaphore, message queue, shared memory)
or if I have to declare one for each primitives.

>
> Regarding key_t, I believe it should be defined to a 64 bit integer type.

It is actually defined as long (open solaris), or 32 bits integer type (linux).

> ftok() should probably return ((<node ID> << 8) | (id & 0xff)). This is far
> from perfect, since we cannot guarantee that the IDs are unique this way, but
> I think it's the best we can do, since key_t needs to be an integer type and
> we've got 71 bits of information to encode.

Honestly I've just used the same implementation as all the other OS,
since it is basically
the same among all of them

key_t
ftok(const char *path, int id)
{
    struct stat st;

    if (stat(path,&st) < 0)
        return (key_t)-1;

    return (key_t) (id << 24 | (st.st_dev & 0xff) << 16 | (st.st_ino & 0xffff));
}

I haven't test it yet though.


Anyway, today I hit my first bug while unpacking (tarball) the whole
haiku source tree
from a usbdisk. How should I proceede? Open a ticket as usual and
assign it to me and show
the stack trace, or work silently on it? :)
I have to check if there is already a duplicate. It appears to crash
on put_vnode, that calls
dev_vnode_ref_count and crash.

Regards,
-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it

Other related posts: