Are they same?
Could some one please explain in detail. I have gone through the web links and found both do the resource management.
Is one is newer than the other one?
How a multimedia application can utilize this in its code.
CKRM (Class-based Kernel Resource Management) project started to give better resource management in linux kernel and later its been stoped and not mearged with linux kernel.
Later similar project started for same purpose called cgroup and mearged with 2.6 onwards.
We can also get more details from linux source code Documentation's cgroup directory.
In my system its: /usr/src/linux-3.14.1/Documentation/cgroups
Related
I want to inject memory errors on my system to check whether RAS/EDAC system really works and logs errors on my memory (during boot or any runtime). I came across with many tools but I don't know which one to actually trust. The machine I want to test is a Sandy Bridge machine running Linux kernel 5.15.0-58-generic version. Specificially, I want to test my system with Einj tool (https://docs.kernel.org/firmware-guide/acpi/apei/einj.html). Although I followed the earlier steps in the link (BIOS supports Einj, CONFIG_DEBUG_FS, CONFIG_ACPI_APEI, CONFIG_ACPI_APEI_EINJ config parameters are set on my kernel), the files mentioned in the document: /sys/kernel/debug/apei/einj etc. are not present. How can I proceed with this tool? Or is there a better way/tool to inject memory errors to check the EDAC subsystem?
I want to know about LXC and came across this site: https://linuxcontainers.org/lxc/introduction/; in this site, it talks about LXC, LXD, among others.
I am a bit confused, I am under the impression that LXC is a Linux kernel feature, so it should be present in Kernel itself. However, looking at the above site viz: https://linuxcontainers.org/lxc/introduction/, is this same when we say LXC (the kernel feature)? Or is LXC provided to the Linux kernel by https://linuxcontainers.org/lxc/introduction/?
How can I understand this subtle difference?
Most of the core features needed to operate Linux in containers are built into the kernel -- namespaces, control groups, virtual roots, etc. However, to assemble a usable container platform from these features requires a considerable amount of infrastructure. We need to manage container storage, create network links between containers, control per-container resource usage, etc. User-space programs can, and are, used to provide this infrastructure, and the tooling that goes with it.
I have written a series of articles on building a container from scratch that explains some of these issues:
http://kevinboone.me/containerfromscratch.html
It's possible in principle to build and connect containers using nothing but the features built into the kernel, and a bunch of shell scripts. Tools like LXC, Docker, and Podman all use the same kernel features (so far as I know), but they manipulate these features in different ways.
Does someone have experiences mentioned the use of SELinux in embedded systems like Yokto?
My current project got a board support package without any SELinux stuff. The only thing i am able
to use is the default SELinux Kernel feature. So i have no predefined policies nor userspace tools.
I compiled the Linux Kernel with SELinux support enabled and set SELINUXTYPE=targeted in /etc/selinux/config.
The system needs to run only a single policy that controls a little number of services in the targeted way but leaves the other services untouched.
I have no experience using SELinux without predefined policies or build system for policies like Fedora.
So i need to compile the policy, put the binary in the board support package and burn it on a SD-card.
There is no serious information about that out there so i bought the SELinux Cookbook by Sven Vermeulen but it lacks also in terms of using SELinux on embedded systems.
It would rather be lovely if someone have experiences using a similar system or has some websites or books with good information to advise.
Thank you!
have you tried adding the metalayer for the reference policy and then starting from there ?
link to the metalayer:
https://github.com/SELinuxProject/refpolicy
This is in reference to https://docs.docker.com/config/containers/resource_constraints/#limit-a-containers-access-to-memory. I have already created working containers, running Docker version 18.05.0-ce on a Raspberry Pi (64-bit) using Raspbian Jessie Lite (essentially GUI-less Debian Jessie).
The documentation claims that you can just pass memory/cpu flags on the docker run command. But when I try something like docker run -it --name test --memory=512m container_os, it says:
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap
I get a similar message about not having cpuset mounted if I pass a cpu-based flag, such as --cpuset-cpus. This obviously means that I don't have these different cgroups mounted for Docker to manage resources correctly, right?
Now referring to https://docs.docker.com/config/containers/runmetrics/#control-groups, I read the section about cgroups, but it wasn't super helpful to my understanding of the situation. So rather than just trying random kernel commands, does anyone with experience have a step-by-step explanation of how to do this the right way?
After quite a bit of research, I figured this out, in-case anyone else out there has this same problem.
In reference to https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt, which is extremely helpful on understanding cgroups, a kernel with all of the proper support should have most of the cgroups for docker mounted by default. If not, there's a command to do so:
From section 2.1 - Basic Usage
"To mount a cgroup hierarchy with all available subsystems, type:
mount -t cgroup xxx /sys/fs/cgroup
The "xxx" is not interpreted by the cgroup code, but will appear in
/proc/mounts so may be any useful identifying string that you like.
Note: Some subsystems do not work without some user input first. For instance,
if cpusets are enabled the user will have to populate the cpus and mems files
for each new cgroup created before that group can be used."
For this particular case, however, trying to mount an individual cgroup, such as cpuset, results in an error saying that the "cpuset special device does not exist". This is because the devs of Raspbian Jessie 8 didn't configure the kernel to support the cgroups that Docker uses for resource management by default. This can easily be determined by typing the docker info command, and seeing this at the bottom of the output:
WARNING: No swap limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support
WARNING: No cpuset support
These are all of the cgroups that are needed for Docker to manage memory and CPU resources for containers. Testing to see if your kernel supports something like cpuset is easy. If the file /proc/filesystems has an entry that says nodev cpuset, then that means your kernel has cpuset support, but if you're reading this then it probably means it's just not configured in your kernel. That would call for a kernel reconfiguration and rebuild however, which is not so easy.
With the right kernel configurations, it just works automatically like it seems from the Docker Docs.
I have a Linux network driver that was originally written for 2.4 kernel. It works perfect.
I want to port it to kernel 2.6.31 and then to ARM Linux with same kernel i.e. 2.6.31. I have actually done some minor changes to the driver so that it is able to compile under kernel 2.6.31 and it also loads and unloads without crashing. It also cross compiles for the ARM Linux. But I am unable to test it on ARM so far.
How do I check that the driver is fully compatible with the target kernel, and what considerations shall be made to make it compatible with ARM.
The driver is a virtual network device driver.
Thanks in advance.
Maybe you could use Qemu ( http://wiki.qemu.org/Main_Page) to emulate an ARM platform to be able to test your driver.
You cannot check the driver like that - you have to consider the API changes within 2.6.x series kernel. The changes are quite significant and the overall of the API's from the 2.4 series which is not currently in use.
I would suggest you to go here to the Amazon book store for this book in particular. The book is called 'Essential Linux Device Drivers', by Sreekrishnan Venkateswaran. A very well detailed explanation that will be your guidance in ensuring it works properly.
Since you mentioned the device driver is a network, presumably char device (You're not accessing it in blocks), well, the good news is that the 2.6.x series kernel APIs for the character devices are significantly easier and more centralized to focus on - in fact a lot of the framework is already in place in which the author of said book explains very clearly.
By the way, the book focusses on the latter 2.6.x series after 2.6.19, so this will help you clue in on what needs to be done to ensure your driver works.
You did not specify the ARM chipset you're targetting?
As for testing... well.. perhaps the best way to do this, this is dependant on how you answer the above question to you regarding ARM chipset - if its ARMv6, then perhaps, a cheap android handset that you can easily unlock and root, and pop the kernel in there and see what happens - sorry for sounding contrived but that's the best thing I can think of and that's what pops into my head, to enable you to test it out for ease of testing :)
PS: A lot of cheap ARMv6 handsets would have kernel 2.6.32 running Froyo if that's of any help!