[haiku-commits] Re: r35156 - in haiku/trunk/src/libs/compat/freebsd_network: . compat/sys

  • From: Colin Günther <coling@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 19 Jan 2010 14:33:53 +0100

Axel Dörfler schrieb:
coling@xxxxxx wrote:
+ area = _user_map_file("mmap area", (void*)&firmware->data, B_ANY_ADDRESS, + firmwareFileSize, B_READ_AREA, REGION_PRIVATE_MAP, true, fileDescriptor,
+               0);

The _user_*() functions are syscalls, they are not supposed to be called within the kernel.
You probably want to use vm_map_file() instead.

Bye,
   Axel.



Mmh, where is the vm_map_file() counterpart?
- I looked into munmap()'s callchain, which uses unmap_address_range in the end. Unfortunately unmap_address_range is declared static and thus not accessible by firmware_put().

- I looked into delete_area, quickly finding a comment in _user_delete_area about deleting areas is for userland created areas only. Mmh.

- I grepped for the usage of vm_map_file() throughout Haiku to get a glimpse how the code for unmapping looks there. I found only two locations, both in elf_load_user_image(). And there it looks like it doesn't even is concerned about unmapping.

- I looked in the code for close() in the hope that closing the file might trigger some unmapping. It doesn't look like there is taking place any unmapping along the call chain down to file_close() in vfs.cpp. (The curiousity let me look in the bfs_close(), too, pretty empty in there :)


Now I'm asking myself whether file mapping for firmware loading is the right approach at all. I mean instead of using the previous approach of reading the whole file in by using read(). Because then I could just use free() when firmware_put() is called.

Kind Regards
-Colin

Other related posts: