erysdren has quit [Quit: Konversation terminated!]
tuaris has quit [Quit: Leaving.]
jmairboeck has joined #haiku
diver1 has joined #haiku
Diver is now known as Guest741
diver1 is now known as Diver
Guest741 has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
Given a device ID, what's the "correct" way to get its mount path on Haiku?
<trungnt2910[m]>
I know that I can use fs_stat_dev to get the ino_t of the root, and then use _kern_entry_ref_to_path to obtain a path.
<trungnt2910[m]>
The problem here is the only public function that exposes _kern_entry_ref_to_path is get_path_for_dirent, and that seems to imply that doing this for anything other than the output of readdir results in undefined behavior.
<PulkoMandy>
You can create a BPath from an entry_ref, I don't know what this does internally
<PulkoMandy>
_kern_entry_ref_to_path, apparently?
<PulkoMandy>
So that seems a reasonably public way to do it, but C++ only, do you need it in C?
<PulkoMandy>
It seems no one has needed a public get_path_for_ref yet, but that could be added in Entry.h if you need it (there is already a get_ref_for_path there)
JakeSays1 has quit [Read error: Connection reset by peer]
<trungnt2910[m]>
<PulkoMandy> "So that seems a reasonably..." <- The file is C, yes.
<trungnt2910[m]>
How does the Haiku kernel deal with entry_ref? Can we give arbitrary dev_t, ino_t, and string name values and expect the kernel to return a valid entry_ref as long as a file matching these conditions exist?
<trungnt2910[m]>
Or do these values need to be obtained from a prior invocation of some syscall, like _kern_read_stat or _kern_read_dir?
<PulkoMandy>
trungnt2910[m]: the kernel is able to locate any file by just the dev_t and ino_t, so if you have these, you can access the file. To access things that are stored in the directory entry (file name, permissions, etc) you need an entry_ref, that's the dev_t and ino_t of the parent directory plus the filename of the entry in that directory
<PulkoMandy>
Really, if you need a public function to convert an entry_ref to a path in C, I'd suggest you just add that to Entry.h, there's no reason to not have it there and it will be simpler and clearer than what you have now?
Diver has joined #haiku
<trungnt2910[m]>
<PulkoMandy> "Really, if you need a public..." <- Yeah I'll do that later today.
<trungnt2910[m]>
What I need is converting an dev_t and ino_t pair from C code though.
<trungnt2910[m]>
So Entry.h isn't appropriate for my case.
<trungnt2910[m]>
Also, a few more questions about Haiku:
<trungnt2910[m]>
- Does Haiku have a mechanism for apps to watch for network changes, like what `net_daemon` is currently doing?
<trungnt2910[m]>
- Does Haiku have an API to retrieve another process's start time? I can see a way to retrieve the process's _CPU_ time but that might be reduced because of sleep time so...
matt1 has joined #haiku
matt1 has left #haiku [#haiku]
mmu_man has joined #haiku
<PulkoMandy>
For network changes I guess you can look at the NetworkStatus replicant source to see how it's done there?
CPYou has joined #haiku
orealis has quit [Read error: Connection reset by peer]
<PulkoMandy>
I don't see anything for tracking a team "real" time from outside the team
orealis has joined #haiku
Diver has quit [Ping timeout: 480 seconds]
<trungnt2910[m]>
OK then, there is a certain function that tries to distinguish PIDs using a process's start time, on Haiku I'm using the area_id of the process's app image.
<trungnt2910[m]>
Hmmm I can see a start_watching_network function but it requires a BMessenger...
orealis has quit [Read error: Connection reset by peer]
<trungnt2910[m]>
And, last question, does Haiku provide a way to read another process's memory, other than attaching a debugger or using clone_area (which requires the target area to be set cloneable)?
orealis has joined #haiku
<PulkoMandy>
Probably not, that would be a security hole and that's the reason we added a flag to allow areas to be clonable
<PulkoMandy>
In beos you could clone anything
CPYou has quit [Remote host closed the connection]
HaikuUser has joined #haiku
HaikuUser has quit []
<x512[m]>
It is possible to directly access C++ API from C by using mangled functions (_ZN...).
<trungnt2910[m]>
x512[m]: yeah but I don't think it's a good idea to create a BMessenger or BLooper from the runtime.
<trungnt2910[m]>
Or am I missing something? Can an app have multiple instances of these?
<x512[m]>
It is only one BAPplication, but it can be multiple BLooper's.
<trungnt2910[m]>
<PulkoMandy> "Probably not, that would be a..." <- As for security, why don't you just use a check using the effective UID or the same check used by `_kern_install_team_debugger`?
<trungnt2910[m]>
That's how process_vm_readv works on Linux, it uses the same access check as ptrace, but it doesn't bear the cost of actually installing a debugger (so, for example, multiple processes can use that call on the same target).
<trungnt2910[m]>
It seems like Haiku provides `pthread_attr_get_np` but does not seem to expose it through any headers.
<trungnt2910[m]>
I know that `pthread_getattr_np` is available under `_GNU_SOURCE` but why isn't `pthread_attr_get_np` exposed? On some BSDs both seem to be exposed without any problems.
<trungnt2910[m]>
The fact that pthread_attr_get_np is available but not declared through headers is causing confusion for some CMake configuration scripts.
Diver has quit [Quit: Leaving.]
<x512[m]>
trungnt2910: Should be added to public header?
<trungnt2910[m]>
Yeah I can make a patch in 5 minutes but just asking in case it really is something intended.
<trungnt2910[m]>
Probably add that somewhere under _BSD_SOURCE.