* Made the output look a bit more like that of the other commands.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20279 a95241bf-73f2-0310-859d-f6bbb57e9c96
Monitor Routing rework
* mostly to fix my issues with dual monitors VGA + DVI which didn't work! ;)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20275 a95241bf-73f2-0310-859d-f6bbb57e9c96
* New "ATOM" BIOS Support for radeons X-series
* This also removes scanning for the BIOS signature for other cards
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20272 a95241bf-73f2-0310-859d-f6bbb57e9c96
the stream after Flattening. Now Unflattening works, but the picture
seems to be empty
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20270 a95241bf-73f2-0310-859d-f6bbb57e9c96
Basically, there was a pretty subtle race between the cpus in main where if the main cpu released the AP cpus and then before the AP cpus had a chance to run the boot cpu started creating the main thread (which causes smp ici messages to be created) the system would livelock, where the boot cpu waited forever for the AP cpu to acknowledge the ICI (for a TLB flush when creating the kernel stack).
Added smp_cpu_rendezvous(), used to synchronize all the cpus to a particular point, and used it a few times in main().
While i was at it i fixed another race that'll probably never happen, but what the hey. Make sure the kernel args are copied into kernel space by the main cpu before letting any other ones use it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20269 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't show up, that means something is still broken in Flatten() or
Unflatten()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20267 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Style issues.
* Renamed CenteredRect to _CenteredRect
since is private and removed the static keyword.
* Corrected copyright dates.
Thank you!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20266 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Made publish_vnode() available in userland. For old style FS add-ons
publish_vnode() is used when they request a new_vnode(). The semantics
of new_vnode() changed considerably in Haiku, but publish_vnode()
seems to do pretty much what the old new_vnode() did.
* The UserlandFS hosted RamFS begins to work under Haiku. It runs pretty
soon out of memory though (under vmware with 256 MB) and node
monitoring is broken ATM.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20264 a95241bf-73f2-0310-859d-f6bbb57e9c96
old interface is completely done in userland ATM.
It becomes more and more obvious that we probably need to provide
the kernel add-on with a bit more information about what the client FS
interface supports in the first place, so we can save unnecessary trips to
the userland. Opening/closing attributes for a FS using the old style
interface could be handled completely in the kernel add-on, for instance
(even if we lose a bit of accuracy wrt to open modes etc.).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20258 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku's userlandfs. I wouldn't expect them to work very well yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20255 a95241bf-73f2-0310-859d-f6bbb57e9c96
need via library libuserlandfs_beos_kernel.so. Fine-tuned the legacy headers
so they can by used by the the kernel interface emulation code as well as by
the add-ons. This is actually a bit hacky, since we build everything in the
Haiku build environment and thus mix these old headers and Haiku's.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20254 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers dir are used instead. Added missing <new> inclusion.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20253 a95241bf-73f2-0310-859d-f6bbb57e9c96
* vm_area and vm_page now have a new field "mappings" where they will store lists
of vm_page_mapping structures. vm_page::ref_count is gone, as it's no longer
needed (it was never updated correctly, anyway).
* vm_caches now have a type field, ie. CACHE_TYPE_RAM for anonymous areas - this
makes the stores a bit less independent, but is quite handy in several places.
* Added new vm_map_page() and vm_unmap_pages() functions to be used whenever you
map in or unmap pages into/from an area. They don't do much more than handling
vm_page::wired_count correctly right now, though (ie. B_LAZY_LOCK is now working
as expected as well).
* Moved the device fault handler to vm_map_physical_memory(); it was not really
used as a fault handler, anyway.
* Didn't notice Ingo's changes to the I/O space region broke lock_memory(). It
now checks the type of the area that contains the memory, and doesn't lock
anymore if not needed which solves the problem in a platform independent way.
* Implemented lock_memory() and unlock_memory() for real: they now change the
vm_page::wired_count member to identify pages that shouldn't be paged out.
* vm_area_for() now uses vm_area_lookup() internally.
* Fixed various potential overflow conditions with areas that reach 0xffffffff.
* Creating anonymous areas with B_FULL_LOCK no longer causes vm_soft_fault()
to be called, instead, the pages are allocated and mapped (via vm_map_page())
directly.
* Removed the _vm_ prefix for create_area_struct() and create_reserved_area_struct().
* Fixed a bug in vm_page_write_modified() that would not have enqueued pages that
failed to be written to the modified queue again when needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20251 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved stuff need for the BeOS interface only into the beos_* namespace.
* Shuffled a few things around to reduce the block cache implementation
dependencies. compat.h and sysdep.c are gone accordingly.
* The whole UserlandFSServer builds now and could (at least theorectically)
drive a FS add-on implementing the old interface. The required emulation of
the BeOS kernel is not yet provided, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20247 a95241bf-73f2-0310-859d-f6bbb57e9c96
interface. The classes actually interfacing with the client FS add-on still
need to be adjusted.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20246 a95241bf-73f2-0310-859d-f6bbb57e9c96
opening bracket) - thanks!
* Shuffled functions a bit around to separate static and exported functions.
* Some other cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20245 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed them, made everything static besides vm_allocate_early() (previous
vm_alloc_from_kernel_args()) which now allows you to specify a different
virtual than physical size, and therefore makes vm_alloc_virtual_from_kernel_args()
superfluous (which isn't exported anymore, and is now called allocate_early_virtual()).
* Enabled printing a stack trace on serial output on team crash - it doesn't hurt
for now, anyway.
* Cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20244 a95241bf-73f2-0310-859d-f6bbb57e9c96
under Haiku. This fixes bug #1033. Thanks!
* Changed IconMenuItem sizing to use the same method as ModelMenuItem which
makes sure the item is large enough for the icon, and which centers the icon
in case the item is higher than the icon.
* Minor cleanup, added some comments about where those classes are used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20240 a95241bf-73f2-0310-859d-f6bbb57e9c96
UserFileSystem -> FileSystem
UserVolume -> Volume
KernelUserFileSystem -> BeOSKernelFileSystem
KernelUserVolume -> BeOSKernelVolume
The BeOSKernel* classes are indeed intended to handle FS implementations
that use the (old) BeOS FS interface. We'll see how well that will work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20239 a95241bf-73f2-0310-859d-f6bbb57e9c96
the "User" part of the way more often used UserFileSystem and the other
classes that had it accordingly for consistency.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20237 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Finish up documentation for BString
* Trying to work a bit more on the structure.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20236 a95241bf-73f2-0310-859d-f6bbb57e9c96
FS interface. Adjusted old hooks, but didn't add the new ones yet. The
module builds now at least.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20235 a95241bf-73f2-0310-859d-f6bbb57e9c96
reason, don't see the obvious. Well, or doesn't if absent...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20230 a95241bf-73f2-0310-859d-f6bbb57e9c96
