c0deR3D

Had been using this quite some time ago, it is sad that it has only 1-CPU support, preventing some SMP bugs from emerging.

Wonder if it's hard to make it SMP, if too many places use something like #ifdef CONFIG_ARCH_IS_UM to tell whether it is single CPU, it might be hard.

Same here.

When would Apple silicons made natively support for OSes such as Linux? Apple seemlingly reluctant to release detailed technical reference manual for M-series SoCs, which makes running Linux natively on Apple silicon challenging.

Reminds me of User Mode Linux, which AFAIK, runs only on Linux, maybe *nix.

Nope, mine runs on a native Linux box featuring Intel i7-1370P and 32GB RAM. Maybe Xilinx has some tuning which makes Yocto become slow at parsing the recipe dependency and the likes.

I've tried asking the Xilinx community, and got only a reply saying that there is a database in Yocto which limits the scalability.

Your scenario makes me suspecting that it is Xilinx flavored Yocto causing the problem. I think that removing some unused Xilinx-specific layers/recipes can reduce the prologue and epilogue execution time.

Got me wondering, how does it works?

Out of curious, does BPF now capable of capturing all the context switch events such as CPU trap?

Also, if the overhead is negligible, maybe the author can try to merge this into mainline with the use of static key to make the incurred overhead switchable. In spite of the static key, the degree of the accompanied inteferences on cache and branch predictor might be an intriguing topic though.

In the near future, people can control appliances with purely their own consciousness, and the only prerequisite is that it requires a minimum consiciousness level, which is reachable for most of the human being. Lastly, we usually think that people living in the Stone age are primitive people. Are they?

https://twitter.com/Michell51304

If this is the case, it's weird then. Why releasing CPU for only a glimpse saves battery?

Sure, I'd try remove the app from the power efficiency restricted app list, which by default are enforced on all apps.

Yes, I was using Bluetooth headphones at the moment. I don't have the app name at hand, but I know that the app is also a file manager.

So there's probably jitter in my headphones, or the app was not suppose to do music playback smoothly because that's not its main usage.

Nope, mine is a playlist with only 3 local-stored tracks. Yes, I loop these 3 tracks all the time.

Is it then possible that one can "decorate" the elevator music? At least at a interference level. :p

If I want to porting it to x86_64, except the register width, what else do I mainly need to take care of? Thanks!

I don't think that the vanilla scheduler would get abandoned, instead, it would then acts as a fallback scheduler when customized userspace scheduler crashed or getting an update and so on.

BTW, is there any recommended open source dynamic binary patching tool?

Have been using Intel Pin, but fine-grained patches would incur noticeable performance regression permanently.

Thanks!

But comes to C/P value, Intel is totally ruined.

I'm impressed. This should be awared when programming on embedded system.

Sometimes, a capacitor's failure also cause invisible damage to other ICs, it's pretty annoying since some ICs can't just use volt-meter to check if it is still functional.

Why using XX32F103C8T6 instead of its complete model at specification of UART?

Formal Verification is truly needed especially on this.