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: <19630.1227314928@redhat.com>
Date:	Sat, 22 Nov 2008 00:48:48 +0000
From:	David Howells <dhowells@...hat.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	dhowells@...hat.com, Andrew Morton <akpm@...ux-foundation.org>,
	trond.myklebust@....uio.no, viro@...iv.linux.org.uk,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 24/45] CacheFiles: Add a hook to write a single page of data to an inode [ver #41]

Randy Dunlap <randy.dunlap@...cle.com> wrote:

> I would have said that the prevailing comment style in struct
> address_space_operations is sketchy or limited or lacking.

Well, there's that too.

> I want useful comments.  I don't give a hoot whether they are in kernel-doc
> format or /* or //.  I'll even take them in a separate file if they are
> more about theory of operation (overview) instead of directly related
> to a struct or a function's operations, although some people want comments
> only in source files because that is more likely to be updated when
> needed.

I want to see proper interface documentation in Documentation.  Where an
interface is treated as a process, and where it's viewed from both sides where
others are expected both to implement it and to use it.

My opinion is that you should document any interface you propose on the theory
that if you can't explain your interface, why should you expect anyone to
understand what it does?

If I get some spare time, I intend to start writing it for interfaces that
already exist but don't have it yet.  It would then have to be up to those
that accept patches, from Linus on down, to force people to update
documentation when they submit a patch to alter, extend, add or remove an
interface.  Unfortunately, I don't see that as being likely to happen:-(

Sorry, but this is one of my favourite rants.

> If you don't document your own code, who will do it?  Probably nobody.

I do document my own code.  It's my responsibility to do so.

> Well, documentation can have consistent look and feel too, and it should.

Indeed.

David
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ