Basically reused the kernel implementation, but needed to hack it quite
a bit and also add an emulation of the required VM interface.
Completely untested yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20406 a95241bf-73f2-0310-859d-f6bbb57e9c96
possibility to initialize the AutoLocker without locking the object even
if it is unlocked yet. Especially in loops Lock()/Unlock() come handy
when an otherwise constantly hold lock needs to be unlocked for a short
time.
I suppose we should move the kernel utils AutoLocker implementation
to headers/private/shared, and drop the less powerful ObjectLocker.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20405 a95241bf-73f2-0310-859d-f6bbb57e9c96
mapped fully read-only (for both kernel and userland). Previously a
kernel read access to a yet unmapped r/w accessible userland address
would cause the page from the lower cache to be mapped with write
permission for userland (on x86 also for the kernel) thus e.g.
allowing a fork()ed child process to write to the parent process'
memory.
Fixes bugs #113 and #928.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20402 a95241bf-73f2-0310-859d-f6bbb57e9c96
and #928. Under certain conditions a fork()ed child process can
write to the parent process' memory.
A fix follows...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20401 a95241bf-73f2-0310-859d-f6bbb57e9c96
{set,clear}_debugger_{break,watch}point(), allowing to set/clear break
and watchpoints for the calling team. When a break/watchpoint is hit,
the team enters the debugger. Handy in situations when the program in
question can't really be started in a debugger (or it would be
complicated to do so). The functions work only as long as no debugger is
installed for the team.
We clear the arch specific team and thread debug infos now, when a new
debugger is installed, thus clearing break- and watchpoints.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20396 a95241bf-73f2-0310-859d-f6bbb57e9c96
valid stderr. Thus one of the FDs for the pipes created for the initial
handshake with the fork()ed child process exec()ing the shell would have
number 2 and would be closed when the child process set up the
stdin/out/err environment for the shell, leading to the child and the
parent being killed by a SIGPIPE when they tried to access the pipes.
This change replaces the pipes mechanism by one using send/receive_data(),
which is probably even faster. I also reduced the handshake_t::msg field
to 128 bytes and replaced the sprintf()s writing to it by snprintf()s.
Fixes bug #627. Although they looked related, bugs #113 and #928 still
persist.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20393 a95241bf-73f2-0310-859d-f6bbb57e9c96
with gcc 4. Fixed resulting build errors (gcc is more lenient for
headers in -isystem directories).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20386 a95241bf-73f2-0310-859d-f6bbb57e9c96
for the kernel. Added missing includes in userland code that uses the
header.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20366 a95241bf-73f2-0310-859d-f6bbb57e9c96
hashtable in case of a read error (NewBlock() also adds the block,
but FreeBlock() only frees it).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20365 a95241bf-73f2-0310-859d-f6bbb57e9c96
start address wasn't aligned and numBytes was a multiple of the page
size, the last page was ignored. A subsequent get_memory_map() would
return NULL as physical address for that page, if it hadn't been mapped
before (that function looks generally suspicious, IMHO). E.g. reads from a
device into an unaligned buffer that hadn't been touched before would
hit that problem. Fixes bug #1075. Might also fix other reported
problems (like #1056), since this bug could have cause all kinds of weird
behavior and crashes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20362 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added new rule HaikuSubInclude for more comfortable subdirectory inclusion.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20352 a95241bf-73f2-0310-859d-f6bbb57e9c96
built for UserlandFS. The latter appears to be working fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20347 a95241bf-73f2-0310-859d-f6bbb57e9c96
update on the directory to be copied before doing it, even if it is up
to date.
Anyway: Ported RamFS to Haiku's FS interface. Change set apparently merged
with older changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20346 a95241bf-73f2-0310-859d-f6bbb57e9c96
untested).
* Added library with the relevant part of the Haiku kernel interface.
The cache interface is missing, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20340 a95241bf-73f2-0310-859d-f6bbb57e9c96
can be emulated -- and pass this info to the kernel add-on. Thus we can
avoid passing requests to the userland that can't be serviced anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20331 a95241bf-73f2-0310-859d-f6bbb57e9c96
add-ons accordingly and removed the syscall.
* Removed send_notification().
* Reimplemented notify_listener(). It used the unimplemented
send_notification(). Now it has a chance to work. Note that
notify_listener() is obsolete. I would already have removed it, if
there weren't lots of FS implementations still using it (Hint!).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20329 a95241bf-73f2-0310-859d-f6bbb57e9c96
(FileSystemInitializer). This will allow for subclassing FileSystem
later.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20328 a95241bf-73f2-0310-859d-f6bbb57e9c96
turn off the inclusion of src/Jamfile, and the rule DeferredSubInclude to
include a subdirectory in UserBuildConfig. Together they allow a developer
working on a subproject to reduce jam's parsing time when only building the
subproject. Relevant mostly on BeOS; on Linux jam is pretty fast anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20321 a95241bf-73f2-0310-859d-f6bbb57e9c96
there and in <wchar.h>. Any reason for not removing them in <wctype.h>? Or
maybe even nicer reverse the inclusion direction, i.e. remove the
duplicate protos in <wchar.h> and include <wctype.h> instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20317 a95241bf-73f2-0310-859d-f6bbb57e9c96
mount -t userlandfs -p "<client FS> <client FS params>" ...
The parameters may change later in order to become a proper driver
settings string.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20310 a95241bf-73f2-0310-859d-f6bbb57e9c96
vnode::covered_by fields. Together with sMountOpLock it allows write
access, either lock alone suffices for read access. Before
sMountOpLock had to be acquired for read (and write) access, which
meant that while mounting/unmounting a FS path resolution would have
to wait. In case of the UserlandFS this would even cause a deadlock
while mounting if the client tried to resolve the path of the device
to be mounted (e.g. by opening it).
* Added a clarifying comment about read access to the
fs_mount::covers_vnode/root_vnode field and removed locking in
resolve_volume_root_to_mount_point() which was not necessary for
explained reasons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20308 a95241bf-73f2-0310-859d-f6bbb57e9c96
* For B_EQUALS queries the first match would be skipped.
* Exact entry name matches were broken, since the used NameIndex::Find()
expected null-terminated keys with the \0 included in the key length
while it was fed only the raw string length.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20306 a95241bf-73f2-0310-859d-f6bbb57e9c96
name (saves copying the name, if that has to be done anyway) and added a
wrapper version with the old interface.
* dir_vnode_to_path() was broken for file systems that didn't support
the get_vnode_name() hook. It resolved the mount point too early, so
that it was searching the mount point and not the FS root dir for the
node. It uses the get_vnode_name() function now (before resolving the
mount point).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20305 a95241bf-73f2-0310-859d-f6bbb57e9c96
connection to the server is lost. The former is required by our mount
command (it stat()s the mount point for some reason unknown to me). The
latter is just to be a good citizen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20300 a95241bf-73f2-0310-859d-f6bbb57e9c96
change.
* The new notification functions are used instead of send_notification()
and notify_listener() now. Mapped them in the BeOS kernel emulation
accordingly. RamFS node monitoring seems to work now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20298 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
* 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
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
* Renamed a few parameters of the FS module hooks:
- *file in the attribute functions to *vnode
- v to vnode
- I could barely restrain myself from renaming the "_*" parameters. I
understand this marks return parameters, but I'd prefer a nicer prefix
or suffix (that doesn't makes you think this is a private/internal
identifier) like "out", "ret", "return", "result", or something similar.
I'd also like to propose renaming {read,write}_link() to
{read,write}_symlink(). Er, and do we need write_link() at all?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20226 a95241bf-73f2-0310-859d-f6bbb57e9c96
reference without being a referring entry.
* Reworked entry renaming. We do now remove the original entry first and
then create a target entry. Renaming directories didn't work before since
there would temporarily have been two links to a directory, which is not
allowed. Replacing an entry was also broken: The original entry was not
removed. Due to reversing the entry creation/deletion order we also do no
longer suffer from the Tracker bug, that entries would disappear from
queries when being renamed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20204 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added missing locking in the query hooks.
* Added live query support similarly as done in BFS:
- Volume manages a doubly-linked list of live queries.
- Volume::UpdateLiveQueries() invoked from several places where it makes
sense (standard indices, Attribute::WriteAt(), and
BVolume::NodeAttributeRemoved()) notifies the live Query objects.
- Adjusted Query to be able to deal with hard links. Unfortunately Tracker
is a bit broken with respect to hard links, particularly in the query
windows. E.g. only one entry referring to a node is shown, and the renaming
method RamFS uses (link new entry, then unlink old one) causes renamed
entries to fall out of queries, even if they should still be in.
(Want a bug report for this, Axel? :-P)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20203 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
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
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
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
Ingo Weinhold