This dummy was intended for boot code, however, atomic_add seems to be
already properly defined in boot code.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
Older versions will not work anymore because of the API changes in
network kit (removal of nonstandard B_PROT_* status codes). x86 and
x86_64 packages have to be updated again.
Use standard error codes instead.
This allows using error code returned by the underlying functions
directly, and makes it possible to use strerror for debugging. So, we
can also remove StatusString() from the various *Request classes.
* The package info area toggles a package's rating to a "Rate package..."
button when the mouse hovers it.
* Clicking that button opens a window where one can enter a rating.
* Totally not working yet, but I want this in VCS.
This uses a variable CLANG that should be set to the Clang version. For
now, this has to be done manually (e.g. when invoking jam using jam
-sCLANG=34), but later, this will be auto-detected.
Work towards bug #10396
* Displays standard CPUID, and shows what the
internal CPUID used by OS.h *should* be.
* Should help out in identifying new CPU's
as all end users have to do is run sysinfo
to get the CPU info + value for OS.h
Nested functions are a (again, broken) GNU extension which is not
supported by Clang. It has been replaced by a bunch of gotos and a
variable that works as a return address.
Variable length arrays of non-PODs are not part of the C++ standard, but
a GNU extension that never worked correctly. Instead, BStackOrHeap array
is used now, which makes sure that it's not too big for the stack, calls
all constructors and is valid C++.
Use the EPFL (Easily Parsed File Listing) format. This is one of the
formats that WebKit allows for directory listings, and it's easily
parsed and generated.
Previous implementation based on the actual load of each core and share
each thread has in that load turned up to be very problematic when
balancing load on very heavily loaded systems (i.e. more threads
consuming all available CPU time than there is logical CPUs).
The new approach is to estimate how much load would a thread produce
if it had all CPU time only for itself. Summing such load estimations
of each thread assigned to a given core we get a rank that contains
much more information than just simple actual core load.
* Previously PE binaries would trigger the "incorrectly
executable" dialog. Now we get a special message for
B_LEGACY_EXECUTABLE and B_UNKNOWN_EXECUTABLE
* Legacy at the moment is a R3 x86 PE binary. This could
be extended to gcc2 binaries someday far, far, down the
road though
* The check for legacy is based on a PE flag I see
set on every R3 binary (that isn't set on dos ones)
* Unknown is something we know *is* an executable, but
can't do anything with (such as an MSDOS or Windows
application)
* No performance drops as we do the PE scan last
* Tested on x86 and x86_gcc2
