Re: looking for tutorials

2016-06-21 Thread Henrik Austad
On Tue, Jun 21, 2016 at 10:43 AM, Robert P. J. Day
 wrote:
> On Mon, 13 Jun 2016, ty armour wrote:
>
>> I need tutorials on kernel development. And on complete operating
>> system development. I would prefer them to be in assembly because it
>> is faster, but it seriously needs to get done.
>>
>> If you are interested, simply post all of the tutorials and other
>> relevant information to coding kernels that you can
>>
>> and show the references, like actually say okay so in order to do
>> this we need to look for this in the assembler manual.
>
>   perhaps you'd like a hot oil massage and a nice chablis while you
> wait.

Oh, that sounds nice. Should I supply my credit-card details as well?

-H

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Real-time audio over local network with good quality

2016-03-28 Thread Henrik Austad
On Sun, Mar 27, 2016 at 9:18 PM, Ricardo Biehl  wrote:
> Hello guys!

Hi Ricardo,

> Sorry if this question is not part of the scope of this list.
>
> I'm developing a real-time microphone system that will work over local
> network using ALSA library and sockets API with IP (UDP/TCP support)
> <https://github.com/ricardobiehl/ipmic>.

This looks like pure userspace, and going up to the level above, this
list is probably not the best place for it.

> The purpose is to make a good replacement to traditional microphone
> systems (wired or wireless).
> The problem is that I found difficulties in network control and in
> ALSA library too :-) .

Yes, I know :)

> Basically I need help to select the best network scheduler algorithm,
> set the right parameters, and (in audio) create a PCM plug which
> supports (1 channel * 16 bit sample * 22050 Hz) and BLOCKING opening
> mode. All this without quality loss and real-time.

Theres a lot of details you gloss over here, that will eventually have
to be solved

1) how do you handle signalling (mic goes way, new one appears)
2) what kind of equipment do you support? (one computer for each mic
gives you expensive mics)
3) signal (time)correlation, you need some timestamping to the samples
to if you are going to combine local feedback
4) Consistent alsa config across all endpoints

What you need is network hardware, both in the NIC and in the network
infrastructure that can properly prioritize your streams and provide
accurate timestamps.

Have you looked at similar projects, like AES67 and TSN/AVB?

AES67 is a best-effort approach, TSN requires support in the network
to prioritize the streams. Go and have a gander at OpenAVB  [1]

> Any contribution with the project is welcome!

There may be something in the works that will be shipped out for RFC
soon (see [2])


1) https://github.com/AVnu/Open-AVB
2) http://mailman.alsa-project.org/pipermail/alsa-devel/2014-May/077087.html

-- 
Henrik Austad

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Distributed Process Scheduling Algorithm

2016-02-15 Thread Henrik Austad
On Mon, Feb 15, 2016 at 09:35:28PM +0530, Nitin Varyani wrote:
>  Hi,

Hi Nitin,

> I am given a task to design a distributed process scheduling algorithm.
> Current distributed OS are patch work over the linux kernels, that is, they
> are responsible for load balancing through process migration but the
> scheduling is taken care by the single machine linux kernels.

Hmm, are you talking about HPC clusters or other large machines here? I'm 
not familiar with this, so a few references to existing designs would be 
appreciated.

> My task is to make the scheduling algorithm itself as distributed. 

Apart from my comment below, it sounds like a really interesting project. 
Is this a research-project or something commercial?

> That is a scheduler itself makes a decision whether to migrate a task or 
> to keep the task in the current system.  I need some design aspects of 
> how to achieve it. Another thing which I want to know is that whether 
> this job is possible for a kernel newbie like me. Need urgent help. Nitin

Uhm, ok. I think this is _way_ outside the scope of Kernelnewbies, and it 
is definitely not a newbie project.

If you are really serious about this, I'd start with listing all the 
different elements you need to share and then an initial idea as to how to 
share those between individual systems. I have an inkling that you'll find 
out quite fast as to why the current kernel does not support this out of 
the box.

-- 
Henrik Austad


signature.asc
Description: Digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Locking while executing bottom-halves and process context code

2016-02-14 Thread Henrik Austad
On Sun, Feb 14, 2016 at 11:00:40AM +0530, Pratyush Patel wrote:
> Hello,
> 
> While reading a section in Linux Kernel Development, I came across the
> following:
> 
> "If process context code and a bottom half share data, you need to
> disable bottom-half processing and obtain a lock before accessing the
> data."
> 
> Why is this the case? Can one not disable/lock the process context
> code instead of the bottom-half and access data?

You need to do it in both.

You need to grab the lock in BH in case other threads also calls the same 
syscall. You need to lock in from user process context to avoid being 
interrupted and having a BH walk in and update the data.

 A Thread
   |
   do_something()
  do_a_syscall()
 // update a var in kernel, but on behalf of thread
 read shared var A
 * Interrupt *
   irq_entry
 // ack interrupt, do critical stuff
 // trigger softirq do the rest
   irq_exit
   softirq_entry
 Update shared var A
   softirq_exit

   (now back in thread A, inside kernel)
  write old value of A back // updated A from softirq now lost!


> Similarly, for the statement,
> 
> "If interrupt context code and a bottom half share data, you need to
> disable interrupts and obtain a lock before accessing the data."
> 
> Any help in clarifying this would be much appreciated.

Same as for userprocess vs. BH, an ISR can interrupt a BH and update data 
unless you have disabled interrupt. 

HTH,

-- 
Henrik Austad


signature.asc
Description: Digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Process scheduling

2016-02-13 Thread Henrik Austad
On Sat, Feb 13, 2016 at 11:42:57AM +0530, Nitin Varyani wrote:
> Hello,

Hi Nitin,

>  I want to understand the flow of code of process scheduler of
> linux kernel. What I have understood is that
> The task marks itself as sleeping,
> puts itself on a wait queue,
> removes itself from the red-black tree of runnable, and
> calls schedule() to select a new process to execute.
> 
> for Waking back up
> The task is set as runnable,
> removed from the wait queue,
> and added back to the red-black tree.
> 
> Can I get the details of which function does what? in sched/core.c and in
> sched/fair.c
> I am concerned only with fair scheduler. There are so many functions in
> these two files that I am totally confused.

Then core.c and fair.c is the best bet.

You could also pick up a copy of Linux kernel development (By Love), it 
gives a nice introduction to the overall flow of .. well mostly everything. 
:)

In kernel/sched/sched.h you have a struct called 'struct sched_class" which 
is a set of function-points. This is used by the core machinery to call 
into scheduling-class specific code. At the bottom of fair.c, you see said 
struct being populated.

Also, if you want to see what really happens, try enabling 
function-tracing, but limit it to sched-functions only (and sched-events, 
those are also useful to see what triggers things)

mount -t debugfs nodev /sys/kernel/debug
cd /sys/kernel/debug/tracing
echo 0 > tracing_on 
echo function > current_tracer
echo "sched*" > set_ftrace_filter
echo 1 > events/sched/enable
echo 1 > tracing_on
... wait for a few secs
echo 0 > tracing_on

cat trace > /tmp/trace.txt

Now, look at trace.txt and correlate it to the scheduler code :)

Good luck!

-- 
Henrik Austad


signature.asc
Description: Digital signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Help needed to implement parameter in SCHED_DEADLINE policy

2015-01-09 Thread Henrik Austad
On Fri, Dec 26, 2014 at 09:14:22PM +0530, Chanchal Paul wrote:
> Hi all,

Hi Paul,

> I am trying to implement my custom scheduling policy in rt patched
> linux kernel. I am working with version 3.14.25-rt22. I have
> successfully installed the kernel after patching with rt patch of same
> version.
> 
> Now the installed kernel also has SCHED_DEADLINE i.e. the EDF scheduling 
> policy.
> 
> The problem in my hand is to introduce a parameter in the
> SCHED_DEADLINE policy which will further dynamically change the
> priority according to the supplied value while the task is submitted.

You do know that SCHED_DEADLINE does not use priorities but _deadlines_, 
right?

care to elaborate a bit?

> I have already simulated and tested my requirement. I am having
> problem with understanding the hierarchy of scheduler code.

You mean the order of the scheduling policies? If you look at the 
sched_class in the different classes, you'll find the following hierarchy:

stop_sched_class
dl_sched_class
rt_sched_class
fair_sched_class
idle_sched_class

So, first the scheduler sees if there's any deadline tasks, then -rt and so 
on.

I (we) need a bit more info about what exactly it is you're struggling with

> 
> Thanks in advance
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Henrik Austad

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies