Gordon Ross wrote on 9/13/22 1:01 AM:
Or improve its portability (does it really need to look inside proc_t?)
This is only needed to get the pid of the current process, through
"curproc->p_pidp->pid_id", with curproc defined as threadp()->t_procp
The pid is passed to user level so that it can
Or improve its portability (does it really need to look inside proc_t?)
On Mon, Sep 12, 2022 at 7:00 PM Gordon Ross wrote:
>
> We could integrate fuse into illumos to avoid that kind of thing.
>
> On Mon, Sep 12, 2022 at 5:02 AM Jean-Pierre André
> wrote:
> >
> > IMHO this is the culprit :
> >
We could integrate fuse into illumos to avoid that kind of thing.
On Mon, Sep 12, 2022 at 5:02 AM Jean-Pierre André
wrote:
>
> IMHO this is the culprit :
>
> --- ../oi-include/sys/thread.h 2020-11-19 19:37:31.170054900 +0100
> +++ thread.h.2 2022-09-12 10:48:43.877644300 +0200
> @@ -158,7
IMHO this is the culprit :
--- ../oi-include/sys/thread.h 2020-11-19 19:37:31.170054900 +0100
+++ thread.h.2 2022-09-12 10:48:43.877644300 +0200
@@ -158,7 +158,6 @@
struct _kthread *t_intr; /* interrupted (pinned) thread */
uint64_tt_intr_start; /* timestamp when time
This is accessing t_procp->p_pidp, so it looks very much like the
kernel has been recompiled after or
have been changed, without the fuse kernel module being recompiled
(or at least being downloaded).
You probably only need to recompile with current headers and download.
This has already
Hello!
I made a pkg update today, and was surprised to get a panic on using my
fuse file system "exfat" on USB3, which i use for 1-2 years now.
Maybe some illumos patch is causing this (?)
I have build the exfat bits on the new BE, to no success..
$ fmdump -Vp -u
