Re: What can I do if I sent a wrong patch?
On Sun, 19 Jul 2015, Navy wrote: Hello, A mistake was found after I sent the patch to mentors. What Can I do to make up the fault? first, if they're truly mentors, they should check the patch themselves and catch the error. otherwise, they're not really doing their job as mentors. second, you need to self-examine what you failed to do properly to have sent in a bad patch. i doubt you've done any real harm; the linux kernel has lots of checking up the hierarchy so that a truly damaging patch is rarely going to get into the source tree. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
What can I do if I sent a wrong patch?
Hello, A mistake was found after I sent the patch to mentors. What Can I do to make up the fault? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Fuzzing scheduler CFS
Hello everyone! I decided to take fuzzing task Scheduler CFS http://lxr.free-electrons.com/source/kernel/sched/fair.c Question: I just recently learning fuzzing and it is at all possible fuzzy scheduler? If so then why will advise you start? Excuse me for my english. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: When to resend a patchset?
On Sun, 19 Jul 2015, Greg KH wrote: On Sat, Jul 18, 2015 at 04:11:30PM +0200, Ricardo Ribalda Delgado wrote: Hello Usually I was taking the approach of pinging a patch after 21 days of inactivity. This has worked ok in the past, but the last time I have done it I was told that the merge window was open and that nothing could be done at that time. Is there a written guideline to know when to resend/ping a patch? How can I figure out the current development status of the kernel? Look at the release that is happening this week, that will tell you the status. Take a look at Documentation/development_process/ for more details than you ever wanted to know :) it's just eerie how any discussion involving greg KH typically ends with the phrase, more details than you ever wanted to know. :-) rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: When to resend a patchset?
On Sat, Jul 18, 2015 at 04:11:30PM +0200, Ricardo Ribalda Delgado wrote: Hello Usually I was taking the approach of pinging a patch after 21 days of inactivity. This has worked ok in the past, but the last time I have done it I was told that the merge window was open and that nothing could be done at that time. Is there a written guideline to know when to resend/ping a patch? How can I figure out the current development status of the kernel? Look at the release that is happening this week, that will tell you the status. Take a look at Documentation/development_process/ for more details than you ever wanted to know :) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Delegating printk work to UART interrupt
Hello Alexander, On Sat, Jul 18, 2015 at 11:23 AM, Alexander alexhoppus...@gmail.com wrote: Hi! When i checked how kernel printing works, i mentioned that it takes messages from log_buffer in console_unlock and gives it to call_console_drivers - ... - some uart bsp function. Basically, as i see this BSP realization tries to flush all message chars in busyloop ... so it waits until FIFO_NOT_FULL bit will be dropped by UART and it will be able to push the next byte. Basically, as i see userspace printing do something different. It puts N_FIFO_BYTES and exits, next, when FIFO will be freed - interrupt will be generated, and other characters will be put into UART FIFO. Can we do something similar for kernel printing? i.e. do not busyloop sending char after char, but put N_FIFO chars and flush other in interrupt. When panic will occur we can do busyloop printing again. Is it reliable? Suppose we have several cores. Thank you. What about trying this patch, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/kernel/printk/printk.c?id=5874af2003b1053128d655710140e3187226 Its not changing console printing through UART to interrupt mode. But minimizes the time interrupts being disabled on printk(). Thanks, Arun -- Alexander alexhoppus...@gmail.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to understand processor in SMP and UP?
Hi all, Per my understanding, the processor in SMP and UP should be a logic CPU, not a physical CPU. If the physical CPU contains 2 cores, and every core contains 2 hardware threads, then the processor should stands for hardware thread. Is my understanding right? Thanks very much in advance! Best Regards Nan Xiao ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
