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 - Date: Tue, 7 Apr 2015 18:46:46 +0200 From: Milton Krutt To: Malte Vesper 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
Re: Delaying an interrupt handler
> On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt 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
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