On 1/24/24 15:47, enh via Toybox wrote:
> feel free to push back that "this is too Android-specific"...
It's no sillier than devmem.
You can't malloc more than a long so I'm switching the type to unsigned long and
atolx_range(val, 0, ULONG_MAX).
Should the mlock() be optional? (Maybe -m? Or for
On 1/24/24 11:27, enh via Toybox wrote:
> none of the three existing callers to this function does the chdir() mentioned
> here...
> ```
> // daemonize via vfork(). Does not chdir("/"), caller should do that first
> // note: restarts process from command_main()
> void xvdaemon(void)
> ```
> was the
feel free to push back that "this is too Android-specific"... it's possible
that a better answer to the Android Go folks' "i wish we always had this on
the device" is to just always build it for the device as-is (or if we
really want to hide it away, just bung it in the ghost of toolbox).
On Wed,
This seems to be a popular reinvention. There are three different
variants in the Android tree, and at least another independent one
(intended for Android) on github.
This is the minimal intersection of them all, which will hopefully
still be useful. (It's very close to the system/extras/ Android
none of the three existing callers to this function does the chdir()
mentioned here...
```
// daemonize via vfork(). Does not chdir("/"), caller should do that first
// note: restarts process from command_main()
void xvdaemon(void)
```
was there even a reason why you wanted that in the caller?
