Re: How do _you_ read the linux source?
On Sun, Apr 19, 2015 at 06:57:49PM -0700, r0...@simplecpu.com wrote: The problem a lot of newbies are having is in 'separating the trunk from the leaves.' So my question is this: Experienced kernel developers, how do _you_ read source code? How do you separate the trunk from the leaves? What do you do when you read code you're not familiar with? How do you learn? What's your algorithm? Maybe it could help to firstly focus on data structures/types rather than functions; and I would discourage to read code like a book, I mean from left to right and from top to bottom. And, take a subsystem/part (even if it's very small) of interest and just focus on it. For instance, I guess there is plenty of documentation on how linux boots up: read it, and search through the source where what you have read is done. compile your own kernel, if you haven't done it yet! HTH ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: percolating ERESTARTSYS beyond PCI subsystem
On Sat, Apr 18, 2015 at 01:40:57PM +0200, Milton Krutt wrote:
Hi. The scenario is a PCI driver on a kernel 3.19.2:
is it possible, in case pending_signal(current) is true, to return
-ERESTARTSYS
to insmod process, in order to get it restart (as expectable)?
After some attempts (with pending_signal(current) being true), it seems
that -ERESTARTSYS
is caught by the pci layer that complains saying something like probing
failed ..
unexpectedly returns -512 and nothing is restarted as expected.
What is the exact error message?
probe of :01:0a:0 failed with error code -512
insmod should never return ERESTARTSYS unless some driver is doing
something really odd/broken. What driver are you trying to load that
does this?
It's an experimental driver. For debugging purposes, it has a loop, inside
which the
process is put asleep by the mean of a wait queue, and the desired behaviour is
to manually
wake up the process by pressing CTRL^C at any iteration. It's something like:
while(cond){
prepare_to_wait(queue_head, queue_entry, TASK_INTERRUPTIBLE);
if(condition_to_sleep)
schedule();
if(signal_pending(current))
return -ERESTARTSYS; /* up to the user level */
finish_wait(queue_head, queue_entry);
}
In previous versions of this driver, there was no signal management inside the
loop and the
resulting behaviour was that the loop slept at its first iteration, then it got
woken up by CTRL^C,
and then it never got put asleep again. (Or, to be precise, it was
automatically woken up as soon as
it was put asleep).
So it seems that for having it sleeping through every iteration, the pending
signal has to be cleared
at any iteration. (It seems that the in-tree documentation does not mention any
way of doing this apart
of the one used here).
Thanks to you,
Mk
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
percolating ERESTARTSYS beyond PCI subsystem
Hi. The scenario is a PCI driver on a kernel 3.19.2: is it possible, in case pending_signal(current) is true, to return -ERESTARTSYS to insmod process, in order to get it restart (as expectable)? After some attempts (with pending_signal(current) being true), it seems that -ERESTARTSYS is caught by the pci layer that complains saying something like probing failed .. unexpectedly returns -512 and nothing is restarted as expected. Does insmod disables it explicitly? If so, how to get a similar restart-behaviour? Thanks ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[mil...@krutt.org: Re: Delaying an interrupt handler]
- Forwarded message from Milton Krutt mil...@krutt.org - Date: Tue, 7 Apr 2015 18:46:46 +0200 From: Milton Krutt mil...@krutt.org To: Malte Vesper malte.ves...@postgrad.manchester.ac.uk Subject: Re: Delaying an interrupt handler Not that late! I take your advice, and I inform all the folks who suggested me to jump on a new kernel that now I am on a 3.19! So their hints are still welcome. Bye Despite beeing fairly late, take a look at threaded interrupt handlers, they might help you. You will handle the interrupt fast but you can delay doing the actual work. In the threaded part of the interrupt handler you can sleep and thus use semaphores. hope it is still useful - End forwarded message - ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Delaying an interrupt handler
Hi.
It is known that no semaphore synchronization should be
used inside an interrupt handler.
Anyway, I am looking at a freeBSD device driver (written by
a profesionist) and there are semaphores inside an interrupt
handler's subroutine.
Since I should port to linux that driver, I ask you how can I
reach such synchronization under linux; I tried to use semaphores
inside my handler but I got complains, and I don't want to break
the law, so no semaphores for me.
The scenario is the following:
firmware downloader {
while(fw_blocks--){
/* the call below will cause an interrupt */
load_block();
/* sleep unitl the int handler ackn's the previous
operation, and prevent ANY int. handler operations
until the process goes actually to sleep through the
following call */
sleep(); }
}
int handler {
if(the process is NOT asleep)
wait();
wake up the process.
}
NOTE: I am on a 2.6.10 in order to be closely tutored by LDD3.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
apparent sleep
Hi.
Following LDD3, I am dealing with wait queues, on a 2.6.10.
My loop is like:
while(enough()){
prepare_to_wait(queue_head, queue_entry, TASK_INTERRUPTIBLE);
atomic_set(flag, 0);
if (!atomic_read(flag, 0))
schedule();
finish_wait(queue_head, queue_entry);
}
My intention is to wake up the process at each loop by issuing CTRL^D.
Here is what happens:
the first time the process yields the processor, it actually sleeps and
I have to give it a CTRL^D in order to put it again in running state;
unfortunately, in the following loops, although it calls the schedule()
function, it magically regains the processor putting hisself in a running
state (since it runs, I guess the state is a running one).
In a few words, the while loop has thousands of iterations, but CTRL^D is
needed only during the first one.
Thank you all
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Delaying an interrupt handler
On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt mil...@krutt.org wrote:
Hi.
It is known that no semaphore synchronization should be
used inside an interrupt handler.
Anyway, I am looking at a freeBSD device driver (written by
a profesionist) and there are semaphores inside an interrupt
handler's subroutine.
Since I should port to linux that driver, I ask you how can I
reach such synchronization under linux; I tried to use semaphores
inside my handler but I got complains, and I don't want to break
the law, so no semaphores for me.
Perhaps spinlocks could be the solution :).
2.6.10 please no - :), Linux kernel is now at 4.0.
Daniel.
Yes and no. The routine the int. handler's delay depends on has to
make some non atomic work. So if I lock a spinlock and then I do some
lengthy (i.e. non atomic) job, then I get a warning message like
spinlock held while being preempted (or similar). In symbols, you suggest
something like
process P{
spin_lock(lock);
non_atomic_function();
spin_unlock(lock);
}
int. handler {
spin_lock(lock);
do_things(); /* preferably atomically */
spin_unlock(lock);
}
My first attempt is still to avoid both semaphores and the above remedy,
in order to delay the int. handler up to a desired point.
Thanks!
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
