linux-kernel - Re: [PATCH] Add kerneldoc for flush_scheduled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090813100353.GC28446@elte.hu>
Date:	Thu, 13 Aug 2009 12:03:53 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Andy Whitcroft <apw@...onical.com>,
	Alan Stern <stern@...land.harvard.edu>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	Randy Dunlap <randy.dunlap@...cle.com>
Subject: Re: [PATCH] Add kerneldoc for flush_scheduled_work()


* Johannes Weiner <hannes@...xchg.org> wrote:

> On Thu, Aug 13, 2009 at 09:25:14AM +0200, Ingo Molnar wrote:
> > 
> > * James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > 
> > > On Wed, 2009-08-12 at 10:13 -0400, Alan Stern wrote:
> > > > On Wed, 12 Aug 2009, Ingo Molnar wrote:
> > > > 
> > > > > > And here I was thinking kerneldoc doesn't actually work 
> > > > > > like that, but perhaps Randy fixed it so the initial 
> > > > > > description can line-wrap?
> > > > 
> > > > Yes, that's what I thought too.  If kerneldoc has been fixed 
> > > > then the description line certainly should get wrapped.
> > > 
> > > I really don't think it needs to be fixed: it's a feature not a 
> > > bug.  It requires people writing kernel doc actually to think of 
> > > one line summaries.
> > 
> > As long as the argument is that it's good to have limitations just 
> > because it has good effects as well (which the gist of your argument 
> > seems to be), i disagree.
> > 
> > That's a very basic argument of freedom. Just consider the Gestapo 
> > which was also a 'feature' to keep criminals in check. Did you know 
> > that there were record low levels of petty criminality both in nazi 
> > Germany and during communism (and under just about any totalitarian 
> > regime)? Still nobody in their right mind is arguing that just due 
> > to that they are the right social model ...
> 
> Although I really like how you Godwin'd kerneldoc comments ;-), 
> [...]

Yeah, i'm quite proud of that angle too! It helps keep things 
technical ;-)

> [...] we do have other features that are features because of their 
> limiting effect all over the place, don't we?  The 80-columns code 
> rule e.g. or our limited set of allowed indenting characters.

The difference is that KernelDoc violations break the KernelDoc 
build (and the KernelDoc end result) and get reported (and fixed) as 
regressions.

While 80-columns code rule is a flexible rule that can be ignored if 
it causes a worse end result.

I'd even proffer that the majority of overlong lines in KernelDoc 
are real problems. (just like the majority of line-80 problems are 
real problems on some level)

> > I think this DocBook limitation needs to be fixed, because there 
> > are legitimate cases where a function name got too long (for no 
> > fault of its own, but for properties of the name-space it is 
> > operating in), and we do not want a nanny state beat it into a 
> > single line.
> 
> Agreed, just as in the other rules, one should be able to bend 
> this one once in a while without technical consequences, i.e. 
> without kerneldoc breaking.

Yeah, exactly. Which is why i suggested KernelDoc to be fixed. In 
terms of non-intrusive warnings, scripts/checkpatch.pl is a pretty 
good place.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/