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
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
* 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
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
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
when the new attribute data was too large to fit into the small data section at all.
This fixes the Trash icon update with a block size of 1024 bytes.
* This also fixes a bug where AddSmallData() required you to write back the inode even
if it failed with B_DEVICE_FULL, but no one did it.
* _RemoveSmallData() no longer requires you to write the inode back on success.
* Made most small data methods private.
* WriteAttribute() now tries to put the data into the small data section even if it
existed as a separate file before (the file is then removed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20103 a95241bf-73f2-0310-859d-f6bbb57e9c96
the timer functions could access invalid memory.
* The endpoint manager now panics if a bound endpoint is not in the hash.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20100 a95241bf-73f2-0310-859d-f6bbb57e9c96
which wasn't enough when tampering with the inode's data, and it also acquired that
lock too late.
Thanks to Stefano for pointing this out.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20079 a95241bf-73f2-0310-859d-f6bbb57e9c96
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20072 a95241bf-73f2-0310-859d-f6bbb57e9c96
Semaphore::ZeroCount() on new semaphores, not on used ones. Found by Stefano, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20052 a95241bf-73f2-0310-859d-f6bbb57e9c96
So the mechanism with the global variable did not work for R5 what caused two USB stacks and host controller drivers to be active concurrently which resulted in completely unpredictable results.
This kind-of-inelegant fix was all I could come up with, if someone has a better idea please send it this way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20003 a95241bf-73f2-0310-859d-f6bbb57e9c96
2048 bytes. This should fix bugs #993 and #997.
On BeOS R5 asking for 2 bytes too much wasn't a problem, as we
only need the first page_entry, and it didn't return any Error.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19992 a95241bf-73f2-0310-859d-f6bbb57e9c96
crashes at a later time. I observed one error at 8033a802, but the address
was allocated by the driver and should have been fully locked.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19988 a95241bf-73f2-0310-859d-f6bbb57e9c96
the BFS Journal lock held.
Since our get_vnode() is no longer unsafe (unlike Be's version of it), we can
get rid of the UNSAFE_GET_VNODE stuff, which also solves this bug.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19916 a95241bf-73f2-0310-859d-f6bbb57e9c96
some Pentium 200 MMX pretend to support MTRRs.
This should fix bug #553.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19899 a95241bf-73f2-0310-859d-f6bbb57e9c96
It's based on ntfs-3g-0.20070102-BETA, and therefore under the GPL license.
Writing is currently disabled for safety reasons, and you'll have to mount
it manually, as the identify hooks are not yet implemented.
Thanks a lot for your work!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19897 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ingo Weinhold