From owner-freebsd-current Mon Apr 24 8:36:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 20B7237BB63 for ; Mon, 24 Apr 2000 08:36:23 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA33905; Mon, 24 Apr 2000 11:36:11 -0400 (EDT) (envelope-from wollman) Date: Mon, 24 Apr 2000 11:36:11 -0400 (EDT) From: Garrett Wollman Message-Id: <200004241536.LAA33905@khavrinen.lcs.mit.edu> To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: asm_pci.h,v Holy cow! In-Reply-To: References: <39041698.15FB7483@elischer.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > This seems to be inherent in the file format. Binary data is expanded > by a factor of 4 due to encoding it as a C array. Even tiny changes > in the data ripple through the array and give huge diffs. Uuencoding > the data would only expand it by a factor of 1.4 although it would > have the same problem with the diffs. I've been thinking about this recently myself. We want to maintain the ability to examine historical versions of the code, but actual diffs from one version to another are, in this context, meaningless. I'd like to suggest a new hierarchy /usr/firmware, which sits along-side /usr/src and /usr/ports in our distribution mechanism, but which does not use RCS files to store version information. Rather, the version information is encoded in the pathname, and files are stored and transferred as binary objects. It might look something like this: /usr/firmware/ gronk/ (this is the gronk driver) 3.57.OA.bin (where 3.57.OA is vendor's version) plugh/ 42.69/ model1.bin model2.bin model3.bin -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message