separates the usage of published and unpublished ConditionalVariables into
different functions.
This allows to stick to the semantics of FreeBSD's condition variable subsystem
where it isn't needed to call cv_destroy. With the refactoring now there aren't
orphaned published ConditionalVariable left over, when shutting down the compat
layer.
Though, allocated unpublished struct cv's aren't cleaned up yet. This will be
addressed in a next commit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34468 a95241bf-73f2-0310-859d-f6bbb57e9c96
and size.
* Made VMArea::Set{Base,Size}() private and made VMAddressSpace a friend.
In vm.cpp the new VMAddressSpace::ResizeArea{Head,Tail}() are used
instead.
Finally all address space changes happen in VMAddressSpace only. *phew*
Now it's ready to be thoroughly butchered. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34467 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Instead, added a new function is_local_link_address() which returns the
interface with the matching link level address, and can additionally test
for unconfigured interfaces.
* Merged the two versions of fill_sockaddr_in() together in ipv4.cpp.
* ipv4 now uses the new is_local_link_address() function to figure out whether
the received packet should be processed or not. This should fix a few DHCP
issues with multiple and configured interfaces as recently explained on the
mailing list.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34466 a95241bf-73f2-0310-859d-f6bbb57e9c96
This makes it more explicit where the fields are modified.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34464 a95241bf-73f2-0310-859d-f6bbb57e9c96
freebsd compat layer.
* Renaming functions where their names aren't preset by FreeBSD to stick
to the coding style guidelines.
* Making use of static Notify functions of Haiku's ConditionalVariable
implementation.
* Removing management of used ConditionalVariables within the compat layer.
This should also fix#5072.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34461 a95241bf-73f2-0310-859d-f6bbb57e9c96
simplify migration of the area management, but as a side effect, it also
makes area deletion O(1) (instead of O(n), n == number of areas in the
address space).
* Moved more area management functionality from vm.cpp to VMAddressSpace and
VMArea structure creation to VMArea. Made the list and list link members
itself private.
* VMAddressSpace tracks its amount of free space, now. This also replaces
the previous mechanism to do that only for the kernel address space. It
was broken anyway, since delete_area() subtracted the area size instead of
adding it.
* vm_free_unused_boot_loader_range():
- lastEnd could be set to a value < start, which could cause memory
outside of the given range to be unmapped. Haven't checked whether this
could happen in practice -- if so, it would be seriously unhealthy.
- The range between the end of the last area in the range and the end of
the range would never be freed.
- Fixed potential integer overflows when computing addresses.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34459 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the condition variable and synchronization subsystem of the freebsd compat
layer which will be committed next.
* Also there was a discussion about adding these functions on the commit
mailing list. The mail in http://www.freelists.org/post/haiku-commits/r34395-in-haikutrunksrclibscompatfreebsd-network-compatsys,3
is a good sum up of it (need to scroll somewhat down, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34458 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed BCatalog member from "cat" to fCatalog.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34457 a95241bf-73f2-0310-859d-f6bbb57e9c96
mode. This fixes focus issues as describen in bug #5020.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34456 a95241bf-73f2-0310-859d-f6bbb57e9c96
* This should improve the reliability in case drivers cannot send a packet when
they are still negotiating the line speed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34454 a95241bf-73f2-0310-859d-f6bbb57e9c96
* playback, tested with 16bit format, with sample rate range from 8 to 48kHz
* recording, fixed at 48kHz 16 bit (read below)
* controlling some mixers, input selector, etc.
I placed the driver in the ac97 directory as it fits better.
Also a few coding style fixes by me.
This driver collides at least with one pci id of the sis7018 driver.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34452 a95241bf-73f2-0310-859d-f6bbb57e9c96
* "Classified" VMAddressSpace, i.e. turned the vm_address_space_*() functions
into methods, made all attributes (but "areas") private, and added
accessors.
* Also turned the vm.cpp functions vm_area_lookup() and
remove_area_from_address_space() into VMAddressSpace methods. The rest of
the area management functionality will follow soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34447 a95241bf-73f2-0310-859d-f6bbb57e9c96
ie. also before BeginJob() has been called.
* This fixes BePDF and Gobe Productive not being able to print under Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34446 a95241bf-73f2-0310-859d-f6bbb57e9c96
CreateAsmStructOffsetsHeader mechanism to generate a header with macros
defined to the sizes of the structures we're interested in and when compiling
in C mode define the structures as "struct { char bytes[size]; }".
It works in principle, but due to how jam works, one would have to specify the
dependency to the generated header for all sources that include it directly or
indirectly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34441 a95241bf-73f2-0310-859d-f6bbb57e9c96
loading the GMARBLES.PCX test file just fine.
* Automatic whitespace cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34440 a95241bf-73f2-0310-859d-f6bbb57e9c96
* catattr no longer pretends B_MIME_STRING to be of type string.
* Added message output for both listattr, and catattr.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34438 a95241bf-73f2-0310-859d-f6bbb57e9c96
required hardware (many current Macbooks).
This driver needs a firmware. The retrieval of this firmware requires
following steps:
a) Download the linux firmware from http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o
b) Download and compile b43-fwcutter from http://bu3sch.de/b43/fwcutter/b43-fwcutter-011.tar.bz2
c) Use b43-fwcutter to cut the linux firmware in pieces.
d) Copy those pieces into /system/data/firmware/broadcom43xx/
e) Prepend them with bwi_v3_ and remove the .fw ending.
f) You also need to create an empty file called bwi_v3_ucode in this directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34435 a95241bf-73f2-0310-859d-f6bbb57e9c96
during the animation, rather than B_OP_ALPHA. This avoids a darker
background than supposed when you cycle through the icons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34434 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Ensure that at least a single allocation fits into the buffer spanning over
the total requested size of the pool. This makes the mixer work again instead
of crash because of a failed allocation...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34432 a95241bf-73f2-0310-859d-f6bbb57e9c96
in uninit_condition_variables(). This method and its counterpart
init_condition_variables() will be removed, once the need for the
sConditionVariableHash will be eliminated.
* Now every initialized ConditionalVariable gets removed right after it is no
longer needed. Ingo what do you think?
* This behaviour matches with the FreeBSD way, where a conditional variable
gets assigned to a sleepqueue only when needed, and is removed from that
sleepqueue the moment the condition is met.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34427 a95241bf-73f2-0310-859d-f6bbb57e9c96
loader's heap. Unlike the BeBook documents, we always lock their memory,
though.
* Added Haiku extension rtm_available() that returns how much space is left in
a pool.
* I've disabled the undocumented functions for now - please open a bug report
if you encounter them used in applications.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34419 a95241bf-73f2-0310-859d-f6bbb57e9c96
