The "OTG" here is just part of the name of the hardware block in the SoC that provides the USB controller, which is not guaranteed to actually support OTG (role switching) or the device role at all in any particular implementation. I don't remember how exactly it was used on which RPi board… I *thiiink* it was used as the USB 2.0 host controller pre-RPi4, then when XHCI was added, it was moved to the upstream-facing Type-C port? Something like that..??

In D46296#1061077, @emil_etsalapatis.com wrote:

In D46296#1060950, @val_packett.cool wrote:

A couple more notes from testing:

There's some other place where FUSE layer can pick up zero-padded-to-power-of-two things, now with 1024 instead of 4096:

WARNING: FUSE protocol violation for server mounted at /: Returned an embedded NUL from FUSE_READLINK.  This warning will not be repeated.
Len 1024
0000   62 61 73 68 00 00 00 00 00 00 00 00 00 00 00 00  |bash............|
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
…

And trying to just find something in a src tree checkout, there are sporadic errors like

find: ./contrib/llvm-project/llvm/lib/DebugInfo/Symbolize: Bad file descriptor
find: ./sys/dev/qat/qat_hw: Invalid argument
find: ./sys/dev/qat/qat_api/common/stubs: Invalid argument
// etc…

that seem completely random, on one invocation there are none, on another there's a couple…

Thank you for the testing! Are you using writethrough or writeback mode for FUSE? Also, what command line arguments are you using for virtiofsd on the host side?

A couple more notes from testing:

Do we actually need the utility? mount.c says,

Thanks a lot for working on this!

In D41844#1040226, @dfr wrote:

In D41844#992483, @val_packett.cool wrote:

In D41844#992328, @editor_callfortesting.org wrote:

Can we land this without an aggressive MFC and test in CURRENT before the review goes stale?

+1. Will be a lot easier for me to submit my patches then. With those, it almost works well enough for me, the only thing missing is mmap'ed writes.

I'm rebasing this change today and would like to commit it. Would you like me to include your patches? If so, would you prefer them to be folded into the main commit or kept separate as in the tarball you attached?

In D44373#1032959, @jonathan wrote:

I wonder if, instead of changing the in-kernel model, this might be better addressed through interposition, either using LDPRELOAD-ed wrappers that convert open(2) to openat(2) (relative a pre-set "root" FD) or within libc itself?

In D41844#992328, @editor_callfortesting.org wrote:

Can we land this without an aggressive MFC and test in CURRENT before the review goes stale?

Playing with this again, a lot better now!

Ah no, the cache_enter_time thing seems to be unrelated. Maybe it was bad luck that I got it very quickly after porting the patches just doing some ls commands; with pkg fetching packages it has happened both with the patches as they are and without them at all; i.e. no matter what. Not sure what can be done, my attempts to "fix" it (with my nonexistent vfs knowledge) seem to only introduce new panics.

Interesting!! The excl->share thing I was getting seems to happen when I mount /home, but not when I mount /home/val only. (On the host /home/val is a mounted ZFS dataset if that matters… well /home is a dataset too but only has the mountpoint dir.)

Just logging in to a home directory shared with the Linux host, there's a lock order issue:

Thanks @trasz, I'll experiment with building on top of fchroot. I'll post new proposals as separate revisions and leave this closed as-is for historical reference :)

ping!

In D39863#937356, @wulf wrote:

Finally, I got MacBook 14,1 for some time and tried to run this driver on it. It required some extra work and result can be found here: https://github.com/wulf7/freebsd/commits/atopcase

WITHOUT_CLEAN builds should benefit as well then.. (Not sure why people still use it when META_MODE exists but okay :D)

Well, you wouldn't really save any time on a non-incremental build as all the libraries would be rebuilt anyway. The *problem* this solves is specific to META_MODE :)

In D39996#911105, @kib wrote:

IMO it is micro-overoptimization, not a fix for a bug. It is fine as far as init(8) does not use reaper API.
It if starts using it, then the check needs to go away.

In D39863#907564, @wulf wrote:

The sibling should be deleted and recreated as child of spibus to get proper ivars like iicbus does: https://github.com/freebsd/freebsd-src/blob/main/sys/dev/iicbus/acpi_iicbus.c#L459
And I wonder, how it produces interrupts as intel_spi misses some resource handling bus methods

Hey, couple random notes:

Yeah, I guess it would make sense to only report "exiting" when not yet exited.

BTW, is the only difference between P_WEXIT and zombie state is that P_WEXIT gets set earlier in the process?

In D38351#899653, @trasz wrote:

I wonder if, instead of "fake root", you made it so that it uses the actual root vnode for the process, the one that's changed by chroot(2)? That would require implementing fchroot(2), like NetBSD did, and that's assuming you're ok with the NO_NEW_PRIVS flag set, ie the SUID bits being ignored, because otherwise chroot(2)/fchroot(2) would require root privileges. The cap_enter() would then have to set the process' root vp to NULL, or to some dead vnode, when called.

Yeah, I solved the same problem in drm initially by writing a dummy driver too, but now it's been replaced by FB_FLAG_NOWRITE.
This is how we're doing it, it's a bit annoying that we have to check the driver and reach into its softc, ideally flags like that would be a more outer-level thing somehow (?)

Found some interesting discussion from almost a decade ago: https://lists.freebsd.org/pipermail/freebsd-arch/2013-August/014707.html confirming that MONOTONIC should include suspended time:

In D39270#894574, @imp wrote:

How that aligns with Linux and other OSes is going to be messy, I fear.

Oh, what's also pretty neat about the "MONOTONIC includes suspend like OpenBSD" choice is that software doing some security timeouts like sudo does would default to the secure behavior (not prolonging timeouts across suspends) even without doing anything for suspend-awareness / while being just POSIX without any OS-specific code!! :)

In D39270#894014, @imp wrote:

we specifically aligned with Linux here because more software is written for linux and we had a lot of patches in the ports tree to emulate the linux behavior prior to my changes.

In D21612#884481, @dmitryluhtionov_gmail.com wrote:

Сan this link help?
https://patchwork.kernel.org/project/linux-acpi/patch/1472628817-3145-1-git-send-email-wnhuang@google.com/

In D21746#884483, @dmitryluhtionov_gmail.com wrote:

Can this driver generate org.freedesktop.UPower.KbdBacklight events ?

Oops… cr_cansee actually would only deny this with security.bsd.see_other_uids=0 btw. Is there a "fs write" style check anywhere in the common code?

Though, hm, various AT_RESOLVE_BENEATH documentation does collapse it all into one item:

Yeah, makes sense, let's try like this

Hopefully more clear this way?

In D38497#876077, @jfree wrote:

I couldn't figure out a good way to generalize the falloc_noinstall/finstall/fdrop calls since the finstall needs fflags that are unique per special fd. I could move falloc_noinstall and fdrop into sys___specialfd(), I believe.

Wait wait wait… if we decided not to put gettime/settime here, to keep it as an interface only for creating various kinds of descriptors, why are we still going to duplicate the falloc_noinstall/finstall/fdrop dance across the individual functions for each descriptor kind?

In D38459#875880, @kib wrote:

I suggest to add ioctl's to perform the ops on the descriptor, instead of filling the syscall table with more one-purpose entries.

In D38459#875436, @markj wrote:

One wrinkle that I can see is that timerfd lets you specify a clock ID, but this implementation doesn't really do anything with it...

just implement these to as syscalls leaving __specialfd for descriptor creation

sure, D38445 LGTM

ok, let's go with D38392

Remove $FreeBSD$ tags, add header include to the .c file to fix missing-prototype

In D28703#873145, @emaste wrote:

Do you have a public Git branch somewhere that I can fetch your changes from?

btw, what toggles the error is --(no-)undefined-version, no became the default. It seems difficult to make *everything* work with --no-undefined-version, but this was the only thing in the kernel.

Rebase after D38222

Yes, it has failed. I wouldn't be that bothered with a little warning :)

Rebased. Ping!