From owner-freebsd-arch@freebsd.org Thu Apr 8 13:15:51 2021 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5BBCF5DC3F3 for ; Thu, 8 Apr 2021 13:15:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FGMFy4CCmz3DHF for ; Thu, 8 Apr 2021 13:15:49 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2465B8D4A178; Thu, 8 Apr 2021 13:15:41 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 20B9BE707C4; Thu, 8 Apr 2021 13:15:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id GXynoMP1wLjm; Thu, 8 Apr 2021 13:15:39 +0000 (UTC) Received: from [169.254.73.94] (unknown [IPv6:fde9:577b:c1a9:4902:e98d:57f7:87e4:1796]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D7099E707BB; Thu, 8 Apr 2021 13:15:39 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Warner Losh" Cc: freebsd-arch@freebsd.org Subject: Re: Moving from .uu.o -> .o in the kernel Date: Thu, 08 Apr 2021 13:15:38 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4FGMFy4CCmz3DHF X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[195.201.62.131:from]; SPAMHAUS_ZRD(0.00)[195.201.62.131:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2021 13:15:51 -0000 On 8 Apr 2021, at 5:26, Warner Losh wrote: Hi, > In preparations for bringing a new vendor driver in, I realized that > one of > the promises of svn was that one could store .o files in the repo. We > never > did that, preferring to stick with the old CVS trick of storing the .o > files as .o.uu files and converting them as part of the build process. > .. > > My proposal is to simplify. I propose that we remove the .uu files and > just > commit the .o files and adjust the build to simplify it. It turns out > that > our config(8) knows that when there's a .o in the kernel files* file, > just > to copy that .o file over when the driver is in the tree. and we’ve done similar things for, e.g., firmware files storing the binary rather than the uuencoded versions in the tree. I am all for the simplification! I am a bit concerned with .o files in random places in the source tree though as they may show up and various tooling people have might clean them up. I’d suggested to keep it in mind and go ahead and do a few and see if it becomes a practical issue rather than just a theoretical one before taking any actions .. /bz