I am trying to setup a build environment where I can run the kernel and see
how the changes I have made to the kernel source work.
My understanding, based on googling, is that it is common practice in the
kernel community to use a virtualised environment for that purpose.
What I have done so far is
The way I do it is by compiling the kernel as I would normaly do for a
real system.
Then, after copying vmlinuz and generating my initramfs, I run Qemu:
$ qemu-system-x86_64 -kernel vmlinuz -initrd initramfs.img -append
param1=value1
For me, as I am mostly testing, there is no need for a full-fea
Hi.
We are trying to build realtime(-ish) system based on rhel6(kernel
2.6.32-642.1.1.el6.x86_64).
We used isolcpus to remove some cpus from process
scheduling(isolcpus=2-19 nohz_full=2-19 rcu_nocbs=2-19).
We spin off a program thread that set's its cpu affinity to one of those
isolated cpus,
On Wed, 28 Jun 2017 08:39:07 -0500, Andrei Hurynovich said:
> We set sysctl kernel.sched_rt_runtime_us = -1 so realtime threads are
> NEVER interrupted.
> According to /proc/sched_debug, it seems that kernel still schedules
> some SCHED_OTHER(e.g. non-realtime) kernel tasks to isolated cpus - for
On Wed, Jun 28, 2017 at 08:39:07AM -0500, Andrei Hurynovich wrote:
> Hi.
>
> We are trying to build realtime(-ish) system based on rhel6(kernel
> 2.6.32-642.1.1.el6.x86_64).
Wow, you do realize that is a _very_ old and obsolete kernel, supported
by no one except Red Hat. If you stick with it, y
Thank you Valdis.
Yes, I'm basically getting what I want - the RT proc never ever gives up
to the system. There are a plenty of cores left to run non-rt tasks on
the machine.
The question is why this old 2.6 kernel decide that it needs per-cpu
events and kblockd tasks.
Maybe someone can give
Hi Alexander,
On Wed, Jun 28, 2017 at 1:46 PM, Alexander Kapshuk <
alexander.kaps...@gmail.com> wrote:
> I am trying to setup a build environment where I can run the kernel and
> see how the changes I have made to the kernel source work.
> My understanding, based on googling, is that it is common
Can the kernel keep track of all the system calls that were called by an
application/module in real-time?
I know I can statically use strace, or even gdb, but I am looking for a
solution in real time when the application/module is already running and
the user has no control over it.
I am not sure
On Wed, 28 Jun 2017 14:02:37 -0500, Andrei Hurynovich said:
> The question is why this old 2.6 kernel decide that it needs per-cpu
> events and kblockd tasks.
You have per-cpu events ecause your real-time process issues syscalls, and
syscalls do things inside the kernel that require per-CPU infras
On Wed, 2017-06-28 at 08:39 -0500, Andrei Hurynovich wrote:
> Hi.
>
> We are trying to build realtime(-ish) system based on rhel6(kernelĀ
> 2.6.32-642.1.1.el6.x86_64).
>
> We used isolcpus to remove some cpus from processĀ
> scheduling(isolcpus=2-19 nohz_full=2-19 rcu_nocbs=2-19).
>
> We spin of
On Wed, 28 Jun 2017 17:48:15 -0300, Ben Mezger said:
> Can the kernel keep track of all the system calls that were called by an
> application/module in real-time?
> I know I can statically use strace, or even gdb, but I am looking for a
> solution in real time when the application/module is already
I'm actually formulating my thesis project. I am looking for a way to
intercept system calls (those chosen by the users), where I can keep
track of what syscall has been called and by who.
A big picture of the _main_ idea of interception would be: Application
called a syscall -> Intercept and dela
On Wed, 28 Jun 2017 19:06:56 -0300, Ben Mezger said:
> I'm actually formulating my thesis project. I am looking for a way to
> intercept system calls (those chosen by the users), where I can keep
> track of what syscall has been called and by who.
As I said before - knowing this, what do you *do*
Let me clear things out.
> As I said before - knowing this, what do you *do* with it? Statistics
> after the fact? Apply security rules before the fact? Something else?
> The answer depends *a lot* on what you're planning to *do* with the info.
There is no statistics involved. I am trying to in
> Whenever fopen("/etc/shadow", "r") is called, the tool would intercept
> it, run the verify() procedure, and return back to the syscall, allowing
> it to do it's job.
This sounds like an LSM, possibly with a component which communicates
with userspace, depending on how sophisticated "verify" nee
On Wed, 28 Jun 2017 20:16:33 -0300, Ben Mezger said:
(By the way - fopen() is a glibc construct, not a syscall)
> I understand seccomp and LSM allows __some__ type of syscall
> interposition (where afaik seccomp blocks mostly all of them), but what
> I am willing to do here is not *reinvent* the
16 matches
Mail list logo