directory, the build system root directory, or the "src" directory is
now using the "haiku-image" target instead. The variable
HAIKU_ORIGINAL_JAM_TARGETS is set to the original JAM_TARGETS value, so
that a UserBuildConfig can base its decisions on it.
The feature is only available with Haiku's jam version.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20194 a95241bf-73f2-0310-859d-f6bbb57e9c96
we do now check whether the target the compiler has been configured for
looks compatible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20189 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes bug #242. The value is currently stored in a separate file.
* Removed some unused codes from ServerProtocol.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20188 a95241bf-73f2-0310-859d-f6bbb57e9c96
not-yet-mounted ClientVolume was not removed, which could cause query requests
to crash the server.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20184 a95241bf-73f2-0310-859d-f6bbb57e9c96
the code is now very compact, on par with other Mesa drivers
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20172 a95241bf-73f2-0310-859d-f6bbb57e9c96
modifications for BONE/Dan0). As test file systems are included:
* A Reiser FS 3.6 read-only implementation (should be a virtually unmodified
version released as 1.0.1 on BeBits).
* A not quite finished RAM FS.
* A BeOS-specific networking FS. It works well as far as I've tested it, but
is utterly insecure at the moment and missing nice GUI preflets. It's also
amazingly slow which, I hope, is mainly caused by the UserlandFS layer and
BeOS R5 net server. We'll see as soon as it can be compiled for the Haiku
kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20171 a95241bf-73f2-0310-859d-f6bbb57e9c96
The kernel arg logic was faulty, and wasn't using strlcpy properly (which returns the size of the src string, not the remaining size). Replaced it with a simpler, but less efficient series of strlcat()s.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20162 a95241bf-73f2-0310-859d-f6bbb57e9c96
The first use is to let the kernel decide what the preferred syscall mechanism is at boot time and copy the
appropriate user space code there. Can be used for routines the kernel can decide best how to use (memcpy, some
timing routines, etc).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20161 a95241bf-73f2-0310-859d-f6bbb57e9c96
the new cpuid stuff was apparently exacerbating an existing problem where various bits of low level
cpu code (specifically get_current_cpu) weren't really initialized before being used. Changed the
order to set up a fake set of threads to point each cpu at really early in boot to make sure that at
all points in code it can get the current 'thread' and thus the current cpu.
A probably better solution would be to have dr3 point to the current cpu which would then point to the
current thread, but that has a race condition that would require an int disable, etc.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20160 a95241bf-73f2-0310-859d-f6bbb57e9c96
away cpuid info into the current cpu structure. Trouble was the code was running before the current
thread pointer was set on each cpu, so it was always looking up cpu 0's structure and saving there,
leaving the other ones uninitialized. Surprisingly this works fine on my machine, but obviously fails
on others (cpuid info would have been zeroed probably). Solution is to change the order that things
are brought up on each cpu to set the current thread pointer first. I don't really like that solution
but it'll work for now. Added a comment to the effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20154 a95241bf-73f2-0310-859d-f6bbb57e9c96
stale dependencies after renaming or deleting object files.
This will avoid link error like the one that was caused by the
recent mesa update.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20148 a95241bf-73f2-0310-859d-f6bbb57e9c96
debugged automatically in a consoled session, when they crash. Note,
that after a recoverable error (like a debugger() call) one can
"detach" the debugged team in gdb, "quit", and continue as if
nothing happened. 8-O
* The input server will no longer be killed when starting the debugger
in a consoled session. Not sure why it was done; it simply works as it
is now.
* Replaced all printf()s and fprintf()s by debug_printf() or TRACE(()).
The debug server prints little enough anyway. In fact only when something
crashes or an unexpected error occurs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20145 a95241bf-73f2-0310-859d-f6bbb57e9c96
(generous 1s for delivery and for reply). This allows for the registrar
main thread to be debugged. Before the libbe initialization in gdb would
block, since it constructed the global be_roster which waited forever for
a reply from the registrar.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20144 a95241bf-73f2-0310-859d-f6bbb57e9c96
