acpi warnings during jam (gcc2 build on ubuntu 9.04)

[scottmc]

src/add-ons/kernel/bus_managers/acpi/oshaiku.c: In function `AcpiOsDeleteLock':
src/add-ons/kernel/bus_managers/acpi/oshaiku.c:666: warning: passing arg 1 of `free' discards qualifiers from pointer target type
src/add-ons/kernel/bus_managers/acpi/namespace/nsxfeval.c: In function `AcpiNsGetDeviceCallback':
src/add-ons/kernel/bus_managers/acpi/namespace/nsxfeval.c:660: warning: unused variable `Flags'
src/add-ons/kernel/bus_managers/acpi/utilities/utdelete.c: In function `AcpiUtDeleteInternalObj':
src/add-ons/kernel/bus_managers/acpi/utilities/utdelete.c:265: warning: assignment makes integer from pointer without a cast
src/add-ons/kernel/bus_managers/acpi/utilities/utdelete.c:285: warning: assignment makes integer from pointer without a cast
src/add-ons/kernel/bus_managers/acpi/utilities/utglobal.c: In function `AcpiUtInitGlobals':
src/add-ons/kernel/bus_managers/acpi/utilities/utglobal.c:869: warning: assignment makes integer from pointer without a cast
src/add-ons/kernel/bus_managers/acpi/utilities/utglobal.c:911: warning: assignment makes integer from pointer without a cast
src/add-ons/kernel/bus_managers/acpi/utilities/utlock.c: In function `AcpiUtDeleteRwLock':
src/add-ons/kernel/bus_managers/acpi/utilities/utlock.c:167: warning: assignment makes integer from pointer without a cast
src/add-ons/kernel/bus_managers/acpi/utilities/utlock.c:168: warning: assignment makes integer from pointer without a cast
src/add-ons/kernel/bus_managers/acpi/utilities/utmutex.c: In function `AcpiUtDeleteMutex':
src/add-ons/kernel/bus_managers/acpi/utilities/utmutex.c:299: warning: assignment makes integer from pointer without a cast

[scottmc]

formatting fix only

[phoudoin]

Oh, an evil warning in oshaiku.c :-)

I'll try to fix that, after switching to gcc2.

[phoudoin]

I most probably wont fix the "assignment makes integer from pointer without a cast" warnings, as these are due to a wrong assertion made by ACPI-CA implementers on ACPI_MUTEX type being necessary pointers, which is wrong under Haiku (it's sem_id, aka integer instead).

[mmlr]

Any reason why it wouldn't use an actual mutex?

[phoudoin]

Hum, let see... nope. :-)

[czeidler]

The oshaiku.c warning I fixed some time ago. I forgot to include a header... From a TODO in the haiku specific part a mutex is not used because it don't support timeouts. As far as I see this is right. Is this correct? should I use pthread_mutex instead?

[axeld]

Those aren't available in the kernel. You might want to fall back to use semaphores, at least I think that extending mutexes would make them considerably more complex, but Ingo would know more about that.

[bonefish]

It's not particularly complex. See the attached patch for a possible mutex_lock_with_timeout() implementation (utterly untested, though). It's mostly identical to the mutex_lock() implementation, save for the use of thread_block_with_timeout_locked() instead of thread_block_locked() and the additional cleanup needed when the timeout does indeed occur. Since in such a case it is also necessary to fix the mutex' count field (!KDEBUG), the new field ignore_unlock_count had to be added to work around a race condition with mutex_unlock().

[stippi]

I read through the patch and I don't understand what happens in line 692 and 693.

[bonefish]

possible mutex_lock_with_timeout() implementation

[bonefish]

Replying to stippi:

I read through the patch and I don't understand what happens in line 692 and 693.

Thanks, that was indeed incorrect. The intention was to update the last pointer of the new first object.

[stippi]

Ah cool, so I wasn't on the wrong track. Am I assuming correctly that all list links have the "last" pointer, but only the one of the first link is maintained at all?

[bonefish]

Replying to stippi:

Ah cool, so I wasn't on the wrong track. Am I assuming correctly that all list links have the "last" pointer, but only the one of the first link is maintained at all?

Exactly. Normally a last pointer would be in the list structure, but in this case we want to save the space in the mutex structure and use this somewhat unusual way.

[scottmc]

Strange, this one has a possible patch attached to it, but the has a patch checkbox is crossed out, so that you can't check it. Was this fixed by hrev37680?

[czeidler]

Yes the main problem is fixed. There are still some warnings but nothing important (?).