From owner-freebsd-current@FreeBSD.ORG Tue Apr 29 15:02:46 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC53C37B401; Tue, 29 Apr 2003 15:02:45 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1B7543F3F; Tue, 29 Apr 2003 15:02:44 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0394.cvx22-bradley.dialup.earthlink.net ([209.179.199.139] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19AdBS-0001g9-00; Tue, 29 Apr 2003 15:02:43 -0700 Message-ID: <3EAEF5EC.8833ABB8@mindspring.com> Date: Tue, 29 Apr 2003 15:00:12 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030428075916.GA53857@myhakas.internal> <20030428190209.A21656@dilbert.robbins.dropbear.id.au> <20030428075916.GA53857@myhakas.internal> <20030428080505.GA1474@chihiro.leafy.idv.tw> <20030428075916.GA53857@myhakas.internal> <20030428105521.GB2676@madman.celabo.org> <20030428111859.GA2923@madman.celabo.org> <3EAECECB.ECB37B03@mindspring.com> <20030429210217.GB18309@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a41eb5063cb4cfc48e8a3ed213a8c4c063350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: freebsd-current@freebsd.org cc: Vallo Kallaste cc: Tim Robbins cc: Dag-Erling Smorgrav Subject: Re: Somethings still up with new NSS? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 22:02:46 -0000 "Jacques A. Vidrine" wrote: > On Tue, Apr 29, 2003 at 12:13:15PM -0700, Terry Lambert wrote: > > It probably would have been better to just put a per record byte > > order maker in there, instead of using a version number, but you > > would still have the same problem for the records without the > > marker, so you'd have to ignore them as "suspect". > > There _is_ a per-record marker. See my posting to -arch yesterday if > interested. It's a version marker, not something like 0xffeefeef, which would let you adaptively use the file byte order, or convert it to host byte order, automagically, as the file is referenced. I understand why you did it the way you did; I'm not complaining (except for history not supporting a byte order marker, and no way to reverse engineer one into there). You probably need both a version marker for the file, and a byte order marker per record; it works as it does not because you didn't change the record size between versions (kind of makes you worry about that happening, now...). A byte order marker per record would "just work", albeit more slowly, on a different architecture. I hope someone is thinking about this INRE moving UFS/UFS2's between SPARC and x86; I know that the last consensus was to punt on binary FS compatability, and not support it, but it should be possible to support it, even if it's not likely to be written in the near future. -- Terry