1000. XenServer boots correctly and in reasonable time,
now (meaning hpet timers work). I guess on real hw the bios doesn't
correctly program the hpet timers, so we'll need a bit more work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33289 a95241bf-73f2-0310-859d-f6bbb57e9c96
XenServer actually boots (but slow as hell) with hpet timers enabled, real hardware does
not.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33287 a95241bf-73f2-0310-859d-f6bbb57e9c96
been since long already.
This should help aljen reintegrate his gallium branch sooner than later,
which after the speed improvment on softpipe made last days will
be welcomed, I'll bet ;-)
Maybe it's possible to even have both current Mesa Software Renderer add-on
*and* Gallium-based SoftPipe one. Will need to actually support renderer
selection (in OpenGL preference panel or via a missing OpenGL Kit API),
as today the first add-on found is the only one ever selected...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33282 a95241bf-73f2-0310-859d-f6bbb57e9c96
Without them, embedded controler may have issue accessing some addresses before
installing his own handlers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33273 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved DPC queue creation / deletion before/after ACPI subsystem
init/shutdown repectively, as AcpiInitializeObjects() would
eventually trigger some AcpiOsExecute() call, which need DPC to be ready.
* Still missing: a DPC queue that run each call in its own thread, not sequentially...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33264 a95241bf-73f2-0310-859d-f6bbb57e9c96
* check the path is NOT a directory or a symlink to a directory.
regular or char/block device are considered both valid path to read
from and write to.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33257 a95241bf-73f2-0310-859d-f6bbb57e9c96
strictly necessary yet, it also makes the app_server test environment run
under Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33252 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is important when setting up the TARGET_LIB* constants later, in case
the target platform is not "haiku". (i.e. libbe_test).
* Added TODO about HOST_GCC_BASE_FLAGS being wrong for GCC4. I couldn't find
the proper fix, but it is important whan compiling libbe_test on Haiku.
I worked around this by having the constant defined correctly for the
problematic file. See the TODO comment.
* Small cleanups.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33246 a95241bf-73f2-0310-859d-f6bbb57e9c96
all the USB drivers working with this single compat header. Usefulness might
be questionable, but since I did the work anyway, why not check it in as well...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33243 a95241bf-73f2-0310-859d-f6bbb57e9c96
the original BeOS input_server will fail to detect the error and never close
the device.
* Remove the empty kernel_cpp header and use the one from kernel util instead.
* Add some missing headers for completeness.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33242 a95241bf-73f2-0310-859d-f6bbb57e9c96
return an error.
* Properly use the name length instead of a hardcoded buffer size when composing
the name of the raw device and ensure proper termination.
* Case new ioctls for Haiku as the target platform. Indeed this driver works
fine on BeOS even though it was written natively for Haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33240 a95241bf-73f2-0310-859d-f6bbb57e9c96
anymore. It could happen that the transfer was already in the process of being
finished, so wasn't in the list of pending transfers anymore. Cancel would then
return even though the callback wasn't called yet. This could lead to a callback
being called after a driver was already unloaded (even after it cleaned up the
pipes it used).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33239 a95241bf-73f2-0310-859d-f6bbb57e9c96
