Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753147AbcLMLXb (ORCPT ); Tue, 13 Dec 2016 06:23:31 -0500 Received: from mail-wj0-f193.google.com ([209.85.210.193]:34427 "EHLO mail-wj0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932814AbcLMLX1 (ORCPT ); Tue, 13 Dec 2016 06:23:27 -0500 Subject: Re: Revised add_key(2) man page for review To: David Howells References: <9a5cc2a7-a505-9d0d-5b78-4bc5ab100ff1@gmail.com> <24646.1481626688@warthog.procyon.org.uk> Cc: mtk.manpages@gmail.com, Eugene Syromyatnikov , linux-man , keyrings@vger.kernel.org, lkml From: "Michael Kerrisk (man-pages)" Message-ID: <2ed8ebca-e971-f9f5-a791-28f2604344c4@gmail.com> Date: Tue, 13 Dec 2016 12:23:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <24646.1481626688@warthog.procyon.org.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2251 Lines: 71 Hello David Thanks for the review! On 12/13/2016 11:58 AM, David Howells wrote: > Michael Kerrisk (man-pages) wrote: > >> The destination keyring serial number may be that of a valid >> keyring for which the caller has write permission, or it may be >> one of the following special keyring IDs: > > No comma before "or". Actually, I think its okay with the comma. But I decided anyway to reword this into two sentences. >> "user" This is a general purpose key type whose payload may be >> ... >> "keyring" > > It probably makes sense to put keyring either first or last. Done. > >> "keyring" >> Keyrings are special key types that may contain links to >> sequences of other keys of any type. If this interface >> is used to create a keyring, then a NULL payload should >> be specified, and plen should be zero. > > I think "then payload should be NULL and plen should be zero." sounds better. Agreed. Fixed. >> "logon" (since Linux 3.3) >> This key type is essentially the same as "user", but it >> does not provide reading. > > "permit the key to be read" rather than "provide reading", I think. Fixed. >> "big_key" (since Linux 3.13) >> This key type is similar to "user", but may hold a pay‐ >> load of up to 1 MiB. If the key payload is large, then >> it may be stored in swap space rather than kernel mem‐ >> ory. > > "stored encrypted in swap space". Fixed. >> printf("Key ID is %lx\n", (long) key); > > key_serial_t is an int. It doesn't really need casting to long. Well, this is a common way of dealing with opaque integer system data types, so that one does not encode a representational dependency into printf(). (Relies on the assumption that the underlying type is no bigger than long. The alternative these days is a cast to (intmax_t) plus %jd.) [So, for the moment, I'll leave the text as is.] Cheers, Micael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/