load_driver_settings() now accepts absolute paths as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12808 a95241bf-73f2-0310-859d-f6bbb57e9c96
interrupt service register bit is never set, anyway...
Thanks to Korli for reporting.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12801 a95241bf-73f2-0310-859d-f6bbb57e9c96
forwarded to the standard interrupt handler. Untested, though.
For more information on the subject: http://www.ggd.nsu.ru/~serg/bsdfaq/part3.html#316
Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12800 a95241bf-73f2-0310-859d-f6bbb57e9c96
VFS's interface, so that a file system only has to implement one interface.
As a side effect, the automatic file system detection may now work (not yet
tested, though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12786 a95241bf-73f2-0310-859d-f6bbb57e9c96
Not yet used, though - we probably need to rearrange the source files a bit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12727 a95241bf-73f2-0310-859d-f6bbb57e9c96
will return true in the former case).
vm_delete_areas() is now using this information to print out a warning
in this case (so that a missing vm_put_area() can now be found easier).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12693 a95241bf-73f2-0310-859d-f6bbb57e9c96
following 1152 MB - that area only guarantees that the heap can grow this much before
the application need the memory for something else. And even then, the heap range
is reused from top-to-bottom, allowing for maximum heap usage. Of course, if the
memory after the heap range is not claimed yet, it can still be claimed by the heap,
too. Added new syscall to create the reserved range.
Fixed a bug in vm_delete_areas(): when it removed reserved areas, the area list
could get messed up.
Fixed a bug in resize_area(): resized areas could never be deleted (missing vm_put_area())!
resize_area() now supports reserved regions (but not perfectly yet, see ToDo items).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12692 a95241bf-73f2-0310-859d-f6bbb57e9c96
only if memory becomes tight, and then the range is used from end to
start.
This is useful to reserve heap address ranges.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12675 a95241bf-73f2-0310-859d-f6bbb57e9c96
along the protection flags).
Changed the handling of B_STACK_AREA types and anonymous vm_areas: now
every area can overcommit if B_OVERCOMMITTING_AREA was specified.
B_STACK_AREA areas are still automatically overcommitting, but
B_KERNEL_STACK_AREA areas no longer.
vm_store_anonymous_noswap.c now only tests for guard pages if there were
any specified which is only done for B_STACK_AREA areas.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12673 a95241bf-73f2-0310-859d-f6bbb57e9c96
(right now, it's still malloc/free, just encapsulated in an allocator class).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12662 a95241bf-73f2-0310-859d-f6bbb57e9c96
This reduces the stack usage quite a lot, and since file system calls could be
nested (for example, a mounted image on a volume), definitely a must, too.
Might be a good idea for user calls, too, though, although it's not urgent.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12636 a95241bf-73f2-0310-859d-f6bbb57e9c96
After all, there might be real graphics card which behave the same??
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12551 a95241bf-73f2-0310-859d-f6bbb57e9c96
mounted, but no one told it about its volume ID - that caused "mountvolume"
not to be able to return a valid mount point.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12548 a95241bf-73f2-0310-859d-f6bbb57e9c96
file system has been mounted, it would have crashed (that for example
happened if you deleted the kernel settings file...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12547 a95241bf-73f2-0310-859d-f6bbb57e9c96
Lots of cleanup:
- moved B_NO_ENABLE_COUNTER flag definition out of int.h to KernelExport.h, as it's
described in the BeBook (although it's probably not really used that often :))
- int.c no longer has any platform dependent code (+ 0x20 on interrupt numbers is gone);
it's now entirely handled in the arch/x86/ section.
- the io_vectors[] is now statically initialized, instead of allocated from the heap
- removed {install|remove}_interrupt_handler(); they weren't that useful, arch_smp_init()
is now calling install_io_interrupt_handler() correctly instead
- introduced a new arch_int.h header file that currently contains NUM_IO_VECTORS only
(though on x86, it also has ARCH_INTERRUPT_BASE == 0x20).
- changed the return type from {install|remove}_io_interrupt_handler() from "long" to
"status_t"
- rearranged and cleaned the PIC initialization code, made the PIC code more prominent
- changed comments that talk about a non existing 8239 (the PIC chip is actually 8259)
- moved arch/x86/interrupts.h to the source directory, as it's not used outside
- added BeOS compatible interrupts_enabled() function, that should replace our
equivalent (and private) are_interrupts_enabled()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12477 a95241bf-73f2-0310-859d-f6bbb57e9c96
Decreased the pipe buffer to 32768 bytes (it's 4096 on BeOS).
pipefs_select/deselect() did no locking.
Switched to using the BenaphoreLocker where possible.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12381 a95241bf-73f2-0310-859d-f6bbb57e9c96
called kernel_${arch} like on disk. A "jam kernel" will still work, though.
Also updated all those Jamfiles I forgot to update before.
Since makehdimage now runs through (and even builds a working image), I guess
most of the consequences of the "kernel/core" -> "system/kernel" rename task
are solved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12364 a95241bf-73f2-0310-859d-f6bbb57e9c96
If anything is still broken (and was not before :)), please shout.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12361 a95241bf-73f2-0310-859d-f6bbb57e9c96
