Re: Contributing via kernel-janitors
On Wed, Jan 14, 2015 at 10:07 AM, Dr. George E. Moore wrote: > I'm certainly willing to lend my support to this work; hwever, I could > use some guidance. I watched this a few times to learn how to submit my first patch: https://www.youtube.com/watch?v=LLBrBBImJt4 -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Tue, Oct 28, 2014 at 2:52 PM, nick wrote: > I am trying to improve my code as much as possible now, I really am finally > understanding > how terrible my code was before and I hope never again to make patches that > shitty. I don't think your recent progress has gone unnoticed. Any word on your latest patch getting picked up? It looked good to me. You remind me of John Locke from Lost. "Don't tell me what I can't do!" :) -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Tue, Oct 28, 2014 at 1:20 PM, Mandeep Sandhu wrote: > Just > increase your font size so that it fits nicely in your editor from end to > end! :P I see :) Sounds good but no. Increasing the font size just causes a loss of screen real estate vertically. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Tue, Oct 28, 2014 at 2:04 PM, John de la Garza wrote: > It seems like you assuming the limit is based on terminal size? Hmm, I thought it was because of 80 column punch cards and ancient printers that didn't wrap. > There is some research in typography that suggests that it is easier > to read text that is not on long lines. Developers don't actually read most of the code seen, over time our eyes become trained to rapidly scan for patterns. We've invented lots of tools like cscope, ctags, lxr, and grep to further keep us from having to actually read much code at all. Your editor doesn't have soft wrap? > Newspapers have a large > sheet of paper but they use short columns. Yeah, short columns with chaotic white-space. The text fills the column width and is both left and right justified. I doubt anyone does "text-align: justify;" to their code editor. Who still reads newspapers? The 2 people still using punch cards? > My display is frequently greater than 80 col. I see this as an > opertunity to have two xterms next to each other, not to have lines > that are longer. Do you hear yourself? "Oh, my eyes, my eyes, I can't be bothered to read code so far out to the right, it burns, it burns!" Or "I can read two lines of code in two different files from two different contexts, but I cannot be bothered to read one longer line from a single file from a single context. I can multitask all day, but I cannot ever single-task, forget that drama!". All I'm saying is since no one adheres to it religiously, and the fact that I've seen many times maintainers telling people to just ignore it, the 80 character checkpatch warning is pointless. Given that it really comes down to a per-case best effort attempt, just set an 80 column indicator in your editor and try to stay within it, if you can. Keeping the checkpatch 80 character warning around is just academic masturbation. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Tue, Oct 28, 2014 at 12:53 PM, Nick Krause wrote: > I actually fixed this to improve code readability not for the kernel > rules for your information. I know, good job.. and here's to hoping a maintainer picks up your patch and applies it to their tree :) But I would argue "kernel rules" and "improving code readability" are one and the same. Otherwise checkpatch and it's optional -f needn't exist. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Tue, Oct 28, 2014 at 11:50 AM, Greg Freemyer wrote: > Lots of violations > checkpatch finds are intentionally left in place because correcting > them makes the code less readable, not more readable. Yeah, but there are still hundreds of thousands of checkpatch violations throughout the kernel that if fixed would actually improve readability. PathErrors Warnings drivers 200979 361350 arch98791 142300 sound 25938 31028 include 13651 25598 fs 96353 22483 net 318519216 lib 80556578 tools 11263972 kernel 656 3203 security47 1247 mm 203 1186 scripts 824 1168 crypto 11441095 block 196 656 Documentation 97 259 init29 173 virt18 152 samples 27 118 ipc 2 77 usr 17 20 firmware11 19 The WARNING "line over 80 characters" currently accounts for 216K of the total violations. IMHO checkpatch should just stop complaining about the 80 char limit since that's the main offender causing new kernel developers to inadvertently lessen readability with their first patch. If the 80 char warning should be mostly ignored why have it.. it's pointless. Increase it to a 21st century value or kill it. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Tue, Sep 16, 2014 at 7:25 PM, Valdis Kletnieks wrote: > In general, stand-alone patches to "fix" checkpatch whining are a Bad > Idea(TM). That's just YOUR opinion. GregKH actually made a presentation to help us n00bs do exactly that: https://www.youtube.com/watch?v=LLBrBBImJt4 And he has been applying my cleanup patches for nearly a month now: http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?h=staging-next&qt=author&q=gdonald > First off, the type of programmer who is tempted to do checkpatch cleanup > as "My First Kernel Patch" are, by and large, novices. OMG, I'm a novice.. cat's out of the bag! Your point? > There's parts of the kernel that have been around for *years* and are beat on > constantly - the VFS, the driver core code, large parts of the network stack > for example. Stand-alone checkpatch fixes here aren't a good idea, because > they're potentially destabilizing if somebody gets the fix wrong. And yes, > this > has happened, and checkpatch "fixes" have actually introduced bugs - it's part > of why there's a "one thing, one patch" rule, to make it easier to audit > a patch and ensure it doesn't introduce regressions. Oh, and most of this > sort of > code is already *really* clean, because professionals have cleaned it up. fs/* currently contains 96,375 errors and 22,555 warnings. net/* currently contains 3,366 errors and 19,536 warnings. *really* clean? LOL. > So that leaves us code that's under active development. And here, checkpatch > fixes are actually a *detriment*, and they tick the subsystem maintainer off. > That's because they have a high probability of causing merge conflicts with > somebody else's patches that are doing *actual code improvement*. So? Either you suck it up and re-spin your patch or you go home and cry. > The end result? Unless you *are* that "somebody else" who's doing other > work on the code, you shouldn't submit checkpatch cleanups. I do Kernel janitor work for the *fun* of it. I program in Python, Java, and ObjC and manage a bunch of Linux servers at my day job.. so changing up and doing Kernel cleanups in my spare time is *fun*. I may or may not ever actually become a full-fledged Kernel hacker and I don't really care either way. Meanwhile drivers/staging/* contains 19,004 errors and 35,292 warnings and until the man stops taking my patches I'm going to continue sending them. As for you I'm just gonna ignore you and your discouraging posts from here on. It's not like you're in MAINTAINERS or anything. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Package Installation Error
On Mon, Sep 8, 2014 at 11:22 PM, Niamathullah sharief wrote: > when try to install "libncurses5-devel" i am getting these messages > > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: Unable to locate package libncurses5-dev You need to find the actual package name for your system: apt-cache search curses | grep dev -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: v3.15 kernel panic, bisecting didn't help
On Tue, Jun 10, 2014 at 9:02 AM, wrote: > On Tue, 10 Jun 2014 08:26:12 -0500, Greg Donald said: > >> the end. All 7 of the bisected kernels I built yesterday boot just >> fine. > > Just to clarify - did 'git bisect' report a 'first bad commit is '? My last "git bisect good" reported this: 1860e379875dfe7271c649058aeddffe5afd9d0d is the first bad commit commit 1860e379875dfe7271c649058aeddffe5afd9d0d Author: Linus Torvalds Date: Sun Jun 8 11:19:54 2014 -0700 Linux 3.15 :100644 100644 cdaa5b6a1c4d6e43e4c0c784831e1e3cb0d9fae5 6d1e304943a379c126c40e2aa1eb3bf4e872ecb1 M Makefile But that doesn't appear to be a bad commit, it's just the version bump from v3.15-rc8 to v3.15. I can only guess it's (wrongly) saying that's a bad commit because there's nothing left to bisect. > Just wondering if the bisect in fact finished, or if you had an 8th bisect > still to do It appears I have completed the full bisection at 7 bisections. Running "git bisect good" again reports the same commit above. I was following this guide: https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html Thanks, -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: v3.15 kernel panic, bisecting didn't help
On Tue, Jun 10, 2014 at 7:49 AM, Bjørn Mork wrote: > Just a tip: You can also create Debian kernel packages directly from a > mainline kernel with "make deb-pkg" (optionally with -jx etc as usual). Is there something wrong with my current kernel packaging method? make-kpkg clean; CONCURRENCY_LEVEL=17 screen fakeroot make-kpkg --append-to-version=-1 --revision=1 --initrd kernel_image The issue I'm trying to resolve is that v3.15.0 from http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ doesn't boot for me, but 3.15.0-rc8 does. Something changed between those two versions that is now causing a kernel panic on two identical systems, and doing a git bisect doesn't turn up a meaningful answer at the end. All 7 of the bisected kernels I built yesterday boot just fine. Thanks, -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: v3.15 kernel panic, bisecting didn't help
On Tue, Jun 10, 2014 at 4:29 AM, Bjørn Mork wrote: > Greg Donald writes: > >> [0.00] Linux version 3.15.0-1+ (root@mars) (gcc version 4.7.2 > > What's with the '+'? Do you have some commit on top of v3.15? If so, > did you include that in your bisect? The + is something Debian's make-kpkg adds. It always appears after my --append-to-version value. I have no commits on this tree. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: v3.15 kernel panic, bisecting didn't help
On Mon, Jun 9, 2014 at 3:47 PM, wrote: > On Mon, 09 Jun 2014 15:35:20 -0500, Greg Donald said: >> I can boot v3.15.0-rc8 but not v3.15.0 (full kernel panic below). >> >> I tried bisecting, I did >> >> git bisect v3.15 v.3.15-rc8 >> >> After 7 compile and reboot cycles I don't think I was able to find the >> bad commit. Every bisection booted with no problems. I ran "git >> bisect good" each time until I finally got to this: > > Can you tell us the output of 'git bisect log'? git bisect start # bad: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15 git bisect bad 1860e379875dfe7271c649058aeddffe5afd9d0d # good: [fad01e866afdbe01a1f3ec06a39c3a8b9e197014] Linux 3.15-rc8 git bisect good fad01e866afdbe01a1f3ec06a39c3a8b9e197014 # good: [cae61ba37b4c2672704cbd8a626fbd85be7e67d9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net git bisect good cae61ba37b4c2672704cbd8a626fbd85be7e67d9 # good: [951e273060d15b233a7f7ccaf76ba682b5b05a03] Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 951e273060d15b233a7f7ccaf76ba682b5b05a03 # good: [813895f8dcb31bc6b0e9f5fc35e8c687a467f3dd] Merge branch 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 813895f8dcb31bc6b0e9f5fc35e8c687a467f3dd # good: [f1453773514bb8b0bba0716301e8c8f17f8d39c7] target: Fix alua_access_state attribute OOPs for un-configured devices git bisect good f1453773514bb8b0bba0716301e8c8f17f8d39c7 # good: [c593e8978722f7f4a12932733cfeed6c0c74fbaa] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs git bisect good c593e8978722f7f4a12932733cfeed6c0c74fbaa # good: [bb077d600689dbf9305758efed1e16775db1c84c] Revert "x86/smpboot: Initialize secondary CPU only if master CPU will wait for it" git bisect good bb077d600689dbf9305758efed1e16775db1c84c Thanks, -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
v3.15 kernel panic, bisecting didn't help
7 [0.492000] [] rebalance_domains+0x135/0x1ed [0.492000] [] run_rebalance_domains+0x2e/0x10c [0.492000] [] __do_softirq+0x91/0x174 [0.492000] [] ? __hrtimer_tasklet_trampoline+0x1a/0x1a [0.492000] [] do_softirq_own_stack+0x1d/0x23 [0.492000] [0.492000] [] irq_exit+0x34/0x75 [0.492000] [] smp_apic_timer_interrupt+0x33/0x3d [0.492000] [] apic_timer_interrupt+0x2d/0x34 [0.492000] [] ? param_array_set+0x23/0xc0 [0.492000] [] ? default_idle+0x5/0x7 [0.492000] [] arch_cpu_idle+0x9/0xb [0.492000] [] cpu_startup_entry+0xe6/0x1c9 [0.492000] [] start_secondary+0x1a6/0x1ab [0.492000] Code: 72 0e 00 3b 05 a0 d9 3a c1 89 c6 0f 8c 7b ff ff ff 8b 95 58 ff ff ff 8b 7b 14 8b 42 0c 31 d2 8b 48 04 8b 43 04 89 4b 10 c1 e0 0a f1 85 ff 89 85 38 ff ff ff 89 03 7 [0.492000] EIP: [] find_busiest_group+0x18a/0x583 SS:ESP 0068:f64bde08 [0.492000] divide error: [#6] [0.492000] ---[ end trace 242397e5073f294d ]--- [0.492000] SMP [0.492000] Kernel panic - not syncing: Fatal exception in interrupt [0.492000] Modules linked in: [0.492000] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 3.15.0-1+ #1 [0.492000] Hardware name: IBM eserver xSeries 335 -[867642X]-/, BIOS -[T2E114AUS-1.03]- 11/14/2002 [0.492000] task: f646abe0 ti: f648c000 task.ti: f648c000 [0.492000] EIP: 0060:[] EFLAGS: 00210246 CPU: 1 [0.492000] EIP is at find_busiest_group+0x18a/0x583 [0.492000] EAX: EBX: f649de38 ECX: EDX: [0.492000] ESI: 0004 EDI: EBP: f649dedc ESP: f649de08 [0.492000] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [0.492000] CR0: 8005003b CR2: CR3: 0141b000 CR4: 07d0 [0.492000] Stack: [0.492000] 0001 0001 c1413280 0001 [0.492000] f6c0f280 f649df28 f6403460 [0.492000] [0.492000] Call Trace: [0.492000] [] load_balance+0xef/0x5cb [0.492000] [] ? update_blocked_averages+0x53f/0x547 [0.492000] [] rebalance_domains+0x135/0x1ed [0.492000] [] run_rebalance_domains+0x2e/0x10c [0.492000] [] __do_softirq+0x91/0x174 [0.492000] [] ? __hrtimer_tasklet_trampoline+0x1a/0x1a [0.492000] [] do_softirq_own_stack+0x1d/0x23 [0.492000] [0.492000] [] irq_exit+0x34/0x75 [0.492000] [] smp_apic_timer_interrupt+0x33/0x3d [0.492000] [] apic_timer_interrupt+0x2d/0x34 [0.492000] [] ? param_array_set+0x23/0xc0 [0.492000] [] ? default_idle+0x5/0x7 [0.492000] [] arch_cpu_idle+0x9/0xb [0.492000] [] cpu_startup_entry+0xe6/0x1c9 [0.492000] [] start_secondary+0x1a6/0x1ab [0.492000] Code: 72 0e 00 3b 05 a0 d9 3a c1 89 c6 0f 8c 7b ff ff ff 8b 95 58 ff ff ff 8b 7b 14 8b 42 0c 31 d2 8b 48 04 8b 43 04 89 4b 10 c1 e0 0a f1 85 ff 89 85 38 ff ff ff 89 03 7 [0.492000] EIP: [] find_busiest_group+0x18a/0x583 SS:ESP 0068:f649de08 [0.492000] Shutting down cpus with NMI [0.492000] ---[ end Kernel panic - not syncing: Fatal exception in interrupt -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Eudyptula Challenge
On Fri, May 23, 2014 at 8:57 AM, Yann Droneaud wrote: > Sometimes it takes weeks, months, before someone pick up your patch on > LKML. So please wait. I know, I saw a patch from two years ago get picked up just yesterday. > In the mean time, check that you use git format-patch and that git > send-email, *especially* git send-email, is able to send an email > with the proper format (check From:, To:, Subject: etc.). Yup, I did all that.. used mutt, my response was Signed-off, everything. But at the same time I was wondering if I did the Subject: correctly since I was trying to make a valid [PATCH] subject line while also including my Eudyptula id too. > And you could have a look to http://lwn.net/Articles/599231/ "Taking > the Eudyptula Challenge" for entertainment (wait, what, you're not yet > a LWN.net subscriber ?). I am a LWN subscriber actually.. but I'm sure that has nothing to do with my brain's lack of delayed gratification software :) -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Eudyptula Challenge
Anyone know what's happening with the Eudyptula Challenge? I sent in my Task 03 solution a few days ago and have got no response. I resent it, and still nothing. Apologies in advance if this is the wrong place to ask about it. Thanks. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: checkpatch.pl comment style warnings
On Sun, Apr 13, 2014 at 4:46 PM, Greg Freemyer wrote: > In general use checkpatch.pl on code you are submitting or around code > you are already patching. But I see patches that do more than one thing get turned down every day. > Sending in standalone coding style patches 9 times in 10 will result > in a rejected patch. Why would 9/10 coding style patches be rejected simply for being standalone? I thought standalone patches were preferred. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
checkpatch.pl comment style warnings
When I run checkpatch.pl -f, it complains about comment blocks like /* * foo * bar */ with "networking block comments don't use an empty /* line, use /* Comment..." But I found this: http://fr.it-usenet.org/thread/18772/41342/, which makes me think that particular checkpatch.pl warning should possibly be ignored for code not in net or drivers/net. 1) Are there different preferred commenting styles for networking code versus everything else? 2) Assuming the comment code above does need fixing, would an example fix be as simple as this? /* foo * bar */ 3) What about the very similar comment blocks checkpatch.pl doesn't currently complain about, do these need fixing too? /** * foo * bar */ Thanks. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
