From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72273ECAAD2 for ; Sat, 27 Aug 2022 07:19:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231222AbiH0HT6 (ORCPT ); Sat, 27 Aug 2022 03:19:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230085AbiH0HT5 (ORCPT ); Sat, 27 Aug 2022 03:19:57 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08A10220D9; Sat, 27 Aug 2022 00:19:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7A40260B3F; Sat, 27 Aug 2022 07:19:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BA56C433C1; Sat, 27 Aug 2022 07:19:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1661584793; bh=YgbBYTSHjSokRb2qHtjrG0P3cBnZxmrktBYWXk9PcSY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=T5W9lm89KHu34/aeb/BIifUQ7e1v8enARGT5+iFLAf3MNpFB58efC53Cbr81jGwtE HiOgRY/+U+PPLN12wRCe/S7GeLIOlFuZHYGP5Ah7ovKEbVYtUcDQWd4JAWulnKlb1y m6beUzU+SjNY/WrGMadPSmnHa0wBxMNUQMXZ1ChU= Date: Sat, 27 Aug 2022 09:20:07 +0200 From: Greg KH To: "G. Branden Robinson" Cc: Alexei Starovoitov , Alejandro Colomar , Quentin Monnet , bpf , linux-man , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Jesper Dangaard Brouer Subject: Re: [PATCH] Fit line in 80 columns Message-ID: References: <20220825175653.131125-1-alx.manpages@gmail.com> <20220825225425.hp2ylp5rxq453ewl@illithid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220825225425.hp2ylp5rxq453ewl@illithid> Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On Thu, Aug 25, 2022 at 05:54:25PM -0500, G. Branden Robinson wrote: > [sorry for the big CC] > > At 2022-08-25T11:06:55-0700, Alexei Starovoitov wrote: > > Nack. > > > > We don't follow 80 char limit and are not going to because of man > > pages. > > If someone got a contract with O'Reilly or No Starch Press to write a > book on BPF and how revolutionarily awesome it is, it's conceivable they > would be faced with exposing some BPF-related function declarations in > the text. In cases like the following, what would you have them do? > > int bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags) > > Be aware that the author may not have infinite flexibility; publishers > generally impose a "house style" which restricts selection of typeface > (so they can't necessarily print at a smaller type size or with the > kerning reduced beyond a certain point to squeeze the text onto the > line). As someone who has written a book for one of those publishers you mention above, this is totally not an issue at all. Authors and typesetters know how to properly wrap and handle stuff like this automatically, it's what they do and has nothing to do with how kernel header files are layed out. But even then, if it was an issue, we don't write kernel code for "some potential commercial entity that can't handle long lines", you know better than this :) greg k-h