From owner-freebsd-arch Sun Jun 3 1:16:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 8D0D237B403 for ; Sun, 3 Jun 2001 01:16:46 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@[206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f538Gdl86097; Sun, 3 Jun 2001 01:16:39 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f538GdR88992; Sun, 3 Jun 2001 01:16:39 -0700 (PDT) (envelope-from obrien) Date: Sun, 3 Jun 2001 01:16:21 -0700 From: "David O'Brien" To: John Polstra Cc: arch@freebsd.org, drosih@rpi.edu Subject: Re: time_t definition is wrong Message-ID: <20010603011621.A88949@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <200106022043.f52KhFh35078@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106022043.f52KhFh35078@vashon.polstra.com>; from jdp@polstra.com on Sat, Jun 02, 2001 at 01:43:15PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jun 02, 2001 at 01:43:15PM -0700, John Polstra wrote: > I'd prefer to keep it as "long" at least on the i386, because that's > what the type was for years before ANSI renamed it to "time_t". We will have to special case all of our code that uses time_t and printf() since our 64-bit types will be "%d", not "%ld", and we'll have to hope all the i386 users remember that when they change things in /usr/src/. I still think it is better to use a consistent time_t definition (and printf format specifier) across all FreeBSD platforms. But if the wind is really swaying that way... I'll concede. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 1:22: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 3DC4937B401 for ; Sun, 3 Jun 2001 01:21:54 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f538LsM37338 for ; Sun, 3 Jun 2001 01:21:54 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E17C3380C; Sun, 3 Jun 2001 01:21:53 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <44610.991550564@critter> Date: Sun, 03 Jun 2001 01:21:53 -0700 From: Peter Wemm Message-Id: <20010603082153.E17C3380C@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <200106022043.f52KhFh35078@vashon.polstra.com>, John Polstra write s: > > >I'd prefer to keep it as "long" at least on the i386, because that's > >what the type was for years before ANSI renamed it to "time_t". > > That, in my mind, is actually a good argument for making it "int" so > that we can flush out those places which don't use time_t well in > advance of the unaviodable change to >32 bits... Incidently, it is possible to configure gcc with 'long' = 64 bits on i386 and cross compile. This makes time_t a variable sized thing on i386, and contributes to the breakage. Also consider x86-64 which will have long = 64 bit but will have to compile and run both ia32 and x86-64 binaries.. This is the same situation as on ia64 which has ia32 execution support. One other thing.. ufs/* should probably have int32_t in the on-disk records (eg: struct dquot) rather than time_t. On things like Tru64 and *BSD/alpha, one has to printf a time_t like this: time_t t; printf("%ld\n", (long)t); Otherwise you get stack misalignment. Alpha has suffered from this for quite a while. I suspect this is the real issue that David is trying to get addressed. For portability, we cannot *assume* that time_t == long. It may be int48_t or goodness knows what on some future arch. We can safely assume that "long" is suffient to represent a time_t though. However, the reference ABI for alpha has time_t = 32 bit. While I understand David's concerns, and agree that something needs to be done, I wonder if staying with a 32 bit time_t on a 64 bit platform is really the right thing to do... Consider: [1:16am]/raid/Linux/dists/v2.4/linux/include-120> grep time_t asm-*/posix_types.h asm-alpha/posix_types.h:typedef long __kernel_time_t; asm-arm/posix_types.h:typedef long __kernel_time_t; asm-i386/posix_types.h:typedef long __kernel_time_t; asm-ia64/posix_types.h:typedef long __kernel_time_t; asm-m68k/posix_types.h:typedef long __kernel_time_t; asm-mips/posix_types.h:typedef long __kernel_time_t; asm-mips64/posix_types.h:typedef long __kernel_time_t; asm-mips64/posix_types.h:typedef int __kernel_time_t32; asm-ppc/posix_types.h:typedef long __kernel_time_t; asm-s390/posix_types.h:typedef long __kernel_time_t; asm-sh/posix_types.h:typedef long __kernel_time_t; asm-sparc/posix_types.h:typedef long __kernel_time_t; asm-sparc64/posix_types.h:typedef long __kernel_time_t; asm-sparc64/posix_types.h:typedef int __kernel_time_t32; and linux/types.h: #ifndef _TIME_T #define _TIME_T typedef __kernel_time_t time_t; #endif If linux can get away with a 64 bit time_t, then we should be able to figure out a way to do so as well. They deal with running 32 bit binaries on 64 bit kernels on mips64, sparc64 and ia64 as well. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 1:33:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 2D24837B401 for ; Sun, 3 Jun 2001 01:33:25 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f538Wt145915; Sun, 3 Jun 2001 10:32:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: Your message of "Sun, 03 Jun 2001 01:21:53 PDT." <20010603082153.E17C3380C@overcee.netplex.com.au> Date: Sun, 03 Jun 2001 10:32:55 +0200 Message-ID: <45913.991557175@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010603082153.E17C3380C@overcee.netplex.com.au>, Peter Wemm writes : >One other thing.. ufs/* should probably have int32_t in the on-disk records >(eg: struct dquot) rather than time_t. Somebody beat you to it, by a fair margin even: 1.5 (dyson 10-Feb-97): int32_t di_atime; /* 16: Last access time. */ 1.5 (dyson 10-Feb-97): int32_t di_atimensec; /* 20: Last access time. */ 1.5 (dyson 10-Feb-97): int32_t di_mtime; /* 24: Last modified time. */ 1.5 (dyson 10-Feb-97): int32_t di_mtimensec; /* 28: Last modified time. */ 1.5 (dyson 10-Feb-97): int32_t di_ctime; /* 32: Last inode change time. */ 1.5 (dyson 10-Feb-97): int32_t di_ctimensec; /* 36: Last inode change time. */ Most of the trouble here is printf. What we need is to be able to say something like printf"time= %{time_t}\n", time_second); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 1:53:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by hub.freebsd.org (Postfix) with ESMTP id 5EEE237B403 for ; Sun, 3 Jun 2001 01:53:30 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.11.2/8.11.0) with ESMTP id f538rTq07830 for ; Sun, 3 Jun 2001 10:53:29 +0200 (CEST) Received: from ertr1013.student.uu.se (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id KAA25114 for ; Sun, 3 Jun 2001 10:53:28 +0200 (CEST) Received: (qmail 34820 invoked by uid 1001); 3 Jun 2001 08:53:11 -0000 Date: Sun, 3 Jun 2001 10:53:11 +0200 From: Erik Trulsson To: arch@FreeBSD.ORG Subject: Re: time_t definition is wrong Message-ID: <20010603105311.A34715@student.uu.se> Mail-Followup-To: arch@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <200106022043.f52KhFh35078@vashon.polstra.com> <20010603011621.A88949@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010603011621.A88949@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sun, Jun 03, 2001 at 01:16:21AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jun 03, 2001 at 01:16:21AM -0700, David O'Brien wrote: > On Sat, Jun 02, 2001 at 01:43:15PM -0700, John Polstra wrote: > > I'd prefer to keep it as "long" at least on the i386, because that's > > what the type was for years before ANSI renamed it to "time_t". > > We will have to special case all of our code that uses time_t and > printf() since our 64-bit types will be "%d", not "%ld", and we'll have > to hope all the i386 users remember that when they change things in > /usr/src/. I still think it is better to use a consistent time_t > definition (and printf format specifier) across all FreeBSD platforms. > > But if the wind is really swaying that way... I'll concede. Code that uses time_t should be written to work regardless of if time_t is defined as 'long', 'int' or 'short' (the last last one is a bit unlikely though :-) ) So if one has time_t t; then both printf("%d",t) and printf("%ld",t) are wrong and should be fixed. Programmers making unwarranted assumptions about the size of time_t and the corresponding printf format specifier should get a clue or two and stop doing that. The correct thing to do is printf("%ld",(long)t) which will work just fine with both ints and longs. If one has C99-aware headers/libraries then the correct thing to do is printf("%jd",(intmax_t)t) which will work for all signed integer types. Although the C standard allows time_t to be any arithmetic type I think one can safely assume that it will be a (signed) integer type on Unix systems (including FreeBSD). On i386 everything should work fine regardless of whether time_t is defined as 'int' or 'long' as long as they are both 32-bit. The worst that can happen is some (well-deserved) compiler warnings. Eventually time_t will have to be changed to a 64-bit type but then it will probably be spelled 'long long' (or, preferably, int64_t assuming FreeBSD has C99-compatible header files by then.) (Changing the size of time_t, especially if time_t no longer could fit n a 'long', will almost certainly break lots of programs and require quite a bit of work to fix.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 2:43:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id D8DF137B401 for ; Sun, 3 Jun 2001 02:43:10 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f539hAM37817 for ; Sun, 3 Jun 2001 02:43:10 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 8CF75380C; Sun, 3 Jun 2001 02:43:10 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <45913.991557175@critter> Date: Sun, 03 Jun 2001 02:43:10 -0700 From: Peter Wemm Message-Id: <20010603094310.8CF75380C@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <20010603082153.E17C3380C@overcee.netplex.com.au>, Peter Wemm writ es > : > > >One other thing.. ufs/* should probably have int32_t in the on-disk records > >(eg: struct dquot) rather than time_t. > > Somebody beat you to it, by a fair margin even: > > 1.5 (dyson 10-Feb-97): int32_t di_atime; /* 16: Last access time. */ > 1.5 (dyson 10-Feb-97): int32_t di_atimensec; /* 20: Last access time. */ > 1.5 (dyson 10-Feb-97): int32_t di_mtime; /* 24: Last modified time. */ > 1.5 (dyson 10-Feb-97): int32_t di_mtimensec; /* 28: Last modified time. */ > 1.5 (dyson 10-Feb-97): int32_t di_ctime; /* 32: Last inode change time. */ > 1.5 (dyson 10-Feb-97): int32_t di_ctimensec; /* 36: Last inode change time. */ No, there are more than this. Dyson's change was to switch from timeval/ timespec to seperate fields. /* on-disk superblock */ struct fs { time_t fs_time; /* last time written */ }; /* on disk cylinder group */ struct cg { time_t cg_time; /* time last written */ }; /* old fs on-disk cylinder group */ struct ocg { time_t cg_time; /* time last written */ }; /* on-disk quota record */ struct dqblk { time_t dqb_btime; /* time limit for excessive disk use */ time_t dqb_itime; /* time limit for excessive files */ }; There is no padding here. Any change to the size of time_t will change the on-disk format. These should be fixed. I was thinking of creating ufs_time_t or something for this purpose (along the lines of ufs_daddr_t). There is one other obvious place that is affected: /* in memory array copies of on-disk data */ struct ufsmount { ... time_t um_btime[MAXQUOTAS]; /* block quota time limit */ time_t um_itime[MAXQUOTAS]; /* inode quota time limit */ }; This is a cached copy of the on-disk records. It would be unfortunate to lose precision doing copies. > Most of the trouble here is printf. What we need is to be able to > say something like > > printf"time= %{time_t}\n", time_second); Heh. Wouldn't that be nice. :-) IMHO, RELENG_4 should not have changed time_t. -current is the place to experiment with this and to thrash out a workable solution. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 6:58:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6D16E37B401 for ; Sun, 3 Jun 2001 06:58:07 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f53DvEf08468; Sun, 3 Jun 2001 09:57:19 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 3 Jun 2001 09:57:14 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: "Jacques A. Vidrine" , Sheldon Hearn , Mark Murray , arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. In-Reply-To: <3B17CA2C.D68B9583@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 1 Jun 2001, Terry Lambert wrote: > "Jacques A. Vidrine" wrote: > > On Wed, May 30, 2001 at 01:36:25AM -0700, Terry Lambert wrote: > > > We talked to the Sun guy who came up with PAM at the last > > > FreeBSD user's group meeting, in Foster City, CA, last > > > month. > > > > > > The PAM API, as it currently sits, is incapable of correctly > > > supporting Kerberos, and several other authentication schemes. > > > > > > Apparently, the only way to fix this is to change the PAM API. > > > > Hey, I'm glad that has sunk in. We debated about this back in February > > (thread in this forum containing Message-ID > > <20010217190800.A38833@spawn.nectar.com>). > > Knowing about the problem, and actually revising the API to deal with > it, are two very different things, unfortuantely. In working on a number of components of the TrustedBSD project, we've repeatedly made the decision to go with the decisions of a slightly inadequate API and slightly worse semantics rather than break portability: FreeBSD is, I'm afraid, a minority player when it comes to portable interfaces, and by not using portable APIs, we generally shoot ourselves in the feet rather than provide added benefit to our users. This doesn't mean there isn't room to innovate, especially in the area of creating new APIs for new and novel services (such as kqueue), it just means you have to carefully weigh the costs of introducing incompatibility for applications. Using PAM allows us to leverage work on other platforms, and as our PAM implementation improves, so does our ability to make use of third party PAM modules. PAM is recognizably not perfect, but as Terry points out, creating the "perfect modular authentication, authorization, accounting, and credential-management API" is not a trivial task. In general, I'd strongly oppose efforts to simply hack up a replacement unless they were seriously thought through, and experimented with over an extended period of time in extremely diverse environments. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 9:25: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 0229B37B401; Sun, 3 Jun 2001 09:25:04 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA08877; Mon, 4 Jun 2001 02:24:50 +1000 Date: Mon, 4 Jun 2001 02:23:13 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Cc: obrien@FreeBSD.ORG, Matt Dillon , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: <39981.991511499@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 2 Jun 2001, Poul-Henning Kamp wrote: > In message <20010602124732.F31257@dragon.nuxi.com>, "David O'Brien" writes: > >On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote: > >> Consistency is best, but breaking IA32 to match the already broken > >> Alpha port is the wrong solution. For consistency we should match > > > >Why is the Alpha port broken? time_t is 32-bits without question. Thus > >it must be an `int' on Alpha, IA-64, and sparc64. > > Uhm, time_t must be signed and at least 32 bits. No. In practice, it must be precisely 32 bits (but possibly unsigned) since it is used in ffs's super block and cylinder groups (but not directly in ffs's inodes - they use int32_t and it is assumed that time_t's fit in int32_t). In theory, it can be any signed arithmetic type from signed char to long double (in C90, more in C99). Some types can't be used in practice because they are too small or too unsuitable. > It would be neat > if all platforms had it longer than 32 bits in the next decade > some time. This would mainly be a small pessimization. > >> Certain core types like time_t > >> have serious limitations when declared as a fixed width type (int > >> nowadays). long is the perfect solution and you just blew that all to > >> hell with this commit. > > > >I am more than willing to define time_t as `long long' so it is 64-bits > >across the board. > > We'll have to do this before 2038 anyway... You mean "before 2106". uint32_t can represent times between 1970 and 2106. If you want to represent times much before 1970, then time_t is already inadequate. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 9:35: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BFF0A37B401; Sun, 3 Jun 2001 09:35:03 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA09374; Mon, 4 Jun 2001 02:34:58 +1000 Date: Mon, 4 Jun 2001 02:33:21 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Cc: obrien@FreeBSD.ORG, Matt Dillon , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Jun 2001, I wrote: > On Sat, 2 Jun 2001, Poul-Henning Kamp wrote: > > > In message <20010602124732.F31257@dragon.nuxi.com>, "David O'Brien" writes: > > Uhm, time_t must be signed and at least 32 bits. > ... > In theory, it can be any signed arithmetic type from signed char to XXXXXX Oops. I should have said that it can be _any_ arithmetic type. (It can also have any representation in C90 although not in POSIX (POSIX requires it to have a particular broken representation that can't handle leap seconds). > > >I am more than willing to define time_t as `long long' so it is 64-bits > > >across the board. > > > > We'll have to do this before 2038 anyway... > > You mean "before 2106". uint32_t can represent times between 1970 > and 2106. If you want to represent times much before 1970, then time_t > is already inadequate. Here I use the fact that it can be unsigned. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 9:46: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D7D9437B403 for ; Sun, 3 Jun 2001 09:46:05 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA09886; Mon, 4 Jun 2001 02:44:39 +1000 Date: Mon, 4 Jun 2001 02:43:02 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Erik Trulsson Cc: arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: <20010602222626.A26556@student.uu.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 2 Jun 2001, Erik Trulsson wrote: > On Sat, Jun 02, 2001 at 12:47:32PM -0700, David O'Brien wrote: > > On Sat, Jun 02, 2001 at 10:39:09AM -0700, Matt Dillon wrote: > > When using a time_t in printf(3) or similar situations the 'correct' > thing is to cast the time_t value to a long and treat it is a long. This is only correct in current versions of POSIX. In C90, time_t can be any arithmetic type. It might be "unsigned long", in which case casting it to long might change its value. OTOH, casting it to "unsigned long" would be wrong if it were "long". It might be "long double", in which case casting it to long might cause an overflow trap. In any case, the representation of time_t's in implementation- defined so printing them directly is only portably useful for debugging. Things are a little more complicated in C99, since there may be more arithmetic types. Things are a little less complicated in POSIX, since the representation of time_t is defined. > I.e. > > time_t t; > ... > printf("%ld",(long)t); > > Then the code will work regardless of whether time_t is defined as an > int or as a long. (And regardless of wether sizeof(int) == sizeof(long) > or not.) I always use this in practice :-). > (If time_t is defined as a long long then the above code won't work > unless sizeof(long) == sizeof(long long). Code like the above that > assumes that a time_t can fit in a long probably exists in *many* > programs. Changing time_t to a 'long long' might therefore break quite > a lot of things.) In POSIX, the representation is known, so we know that casting to long gives the correct result on all machines for times between 1970 and 2038. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 9:57:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7939037B403 for ; Sun, 3 Jun 2001 09:57:39 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA10444; Mon, 4 Jun 2001 02:57:29 +1000 Date: Mon, 4 Jun 2001 02:55:52 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Cc: John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <44610.991550564@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 3 Jun 2001, Poul-Henning Kamp wrote: > In message <200106022043.f52KhFh35078@vashon.polstra.com>, John Polstra writes: > > >I'd prefer to keep it as "long" at least on the i386, because that's > >what the type was for years before ANSI renamed it to "time_t". > > That, in my mind, is actually a good argument for making it "int" so > that we can flush out those places which don't use time_t well in > advance of the unaviodable change to >32 bits... This is the main reason that I changed it. However, I didn't intend the change to be committed anywhere except in -current. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 9:58:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 9480837B405 for ; Sun, 3 Jun 2001 09:58:21 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f53Gw0S34968; Sun, 3 Jun 2001 12:58:00 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <45913.991557175@critter> References: <45913.991557175@critter> Date: Sun, 3 Jun 2001 12:57:58 -0400 To: Poul-Henning Kamp , Peter Wemm From: Garance A Drosihn Subject: Re: time_t definition is wrong Cc: John Polstra , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:32 AM +0200 6/3/01, Poul-Henning Kamp wrote: >Most of the trouble here is printf. What we need is to be able >to say something like > > printf("time= %{time_t}\n", time_second); The following is what Garrett noted in this thread in -stable. I'm not sure where this leaves us, other than it shows that no matter what type we pick for type_t, there will still be some portability problems, at least when it comes to printing. It looks like the best way to solve the printing-issue is to always use strftime(). - Garance - - - - At 8:33 PM -0400 6/2/01, Garrett Wollman wrote: > The pw->pw_chage and pw->pw_passwd are of time_t. But, > in the above, %ld is used for them. This is a general problem; there is no portable way to print a time_t that does not include the following steps: 1) Determine whether time_t is integral, floating-point, or (new in C99) complex. 2) If time_t is integral, determine whether it is signed or unsigned. 3) If the compilation environment is not C99, and time_t is integral, cast to (appropriately signed) long and print with %ld or %lu as appropriate. If the compilation environment is (close enough to) C99, cast to (appropriately signed) intmax_t and print with %jd or %ju as appropriate. If time_t is floating-point, cast to long double and print with %Lf. If time_t is complex, you have a lot more serious problems to deal with. There is a simple way around this, for POSIX systems only: use strftime() with the %s format. -GAWollman - - - - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 10:26: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 64EB137B401; Sun, 3 Jun 2001 10:26:06 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA11684; Mon, 4 Jun 2001 03:26:02 +1000 Date: Mon, 4 Jun 2001 03:24:25 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: "David O'Brien" Cc: John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <20010603011621.A88949@dragon.nuxi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 3 Jun 2001, David O'Brien wrote: > On Sat, Jun 02, 2001 at 01:43:15PM -0700, John Polstra wrote: > > I'd prefer to keep it as "long" at least on the i386, because that's > > what the type was for years before ANSI renamed it to "time_t". > > We will have to special case all of our code that uses time_t and > printf() since our 64-bit types will be "%d", not "%ld", and we'll have > to hope all the i386 users remember that when they change things in > /usr/src/. I still think it is better to use a consistent time_t > definition (and printf format specifier) across all FreeBSD platforms. Both would be broken. > But if the wind is really swaying that way... I'll concede. Just back out the change in released versions. BTW, no one complained when similar changes were made to daddr_t, dev_t, gid_t, ino_t, pid_t and uid_t. These had type long or "unsigned long" in 4.4BSD-Lite and FreeBSD-2.x. They were changed to fixed-width types in 4.4BSD-Lite2 and FreeBSD-3.0 (and earlier in NetBSD?). They all have width 32 bits, so they all changed on i386's, because int32_t and uint32_t are declared as int and "unsigned int", respectively. Bug for bug compatibility with Lite1 would have required int32_t to have the unnatural type "long" on i386's. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 10:49:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8B7DC37B405 for ; Sun, 3 Jun 2001 10:49:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id DAA12589; Mon, 4 Jun 2001 03:49:31 +1000 Date: Mon, 4 Jun 2001 03:47:54 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: Poul-Henning Kamp , John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: <20010603082153.E17C3380C@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 3 Jun 2001, Peter Wemm wrote: > Poul-Henning Kamp wrote: > > In message <200106022043.f52KhFh35078@vashon.polstra.com>, John Polstra write > s: > Incidently, it is possible to configure gcc with 'long' = 64 bits on i386 > and cross compile. This makes time_t a variable sized thing on i386, and > contributes to the breakage. Also consider x86-64 which will have i386's-with-64-bit longs aren't really i386's. People who configure gcc like this should have a separate directory for it :-). But that would be more work. > One other thing.. ufs/* should probably have int32_t in the on-disk records > (eg: struct dquot) rather than time_t. Yes, that would be no worse than using int32_t in the inodes. Both are stictly broken, because time_t's might not be representable as int32_t's, and if time_t's actually needed more than 32 bits then ffs would have a difficult task compressing their values into 32 bits. > On things like Tru64 and *BSD/alpha, one has to printf a time_t like this: > time_t t; > printf("%ld\n", (long)t); > Otherwise you get stack misalignment. Alpha has suffered from this for quite > a while. I think the alpha at least doesn't actually suffer from this, because it pads all args on the stack to 32 bits, so printf("%ld", (int)t) leaves the stack aligned for the next argument. Also, the padding seems to be by sign extension or zero extension, and the machine is little-endian, so va_arg() sees the correct value when it accesses the int on the stack as a long. I've never checked this or received a reply for questions/assertions about this. On i386's-with-64-bit-longs, subsequent args on the stack are messed up and va_arg() sees a garbage value (with the top bits from the next arg), but there is no alignment exception by default. > I suspect this is the real issue that David is trying to get addressed. > For portability, we cannot *assume* that time_t == long. It may be int48_t > or goodness knows what on some future arch. We can safely assume that > "long" is suffient to represent a time_t though. However, the reference > ABI for alpha has time_t = 32 bit. Yes. This is the same issue as for off_t. Not much should be assumed. > While I understand David's concerns, and agree that something needs to be > done, I wonder if staying with a 32 bit time_t on a 64 bit platform is > really the right thing to do... Consider: It's not "right", just pragmatic. If programs didn't make assumptions, then 32-bit time_t's would work fine until 2106. This is much further away than Y2K was before computer hardware existed. > [1:16am]/raid/Linux/dists/v2.4/linux/include-120> grep time_t asm-*/posix_types.h > asm-alpha/posix_types.h:typedef long __kernel_time_t; > asm-arm/posix_types.h:typedef long __kernel_time_t; > asm-i386/posix_types.h:typedef long __kernel_time_t; > ... > and linux/types.h: > #ifndef _TIME_T > #define _TIME_T > typedef __kernel_time_t time_t; > #endif > > If linux can get away with a 64 bit time_t, then we should be able to > figure out a way to do so as well. They deal with running 32 bit binaries > on 64 bit kernels on mips64, sparc64 and ia64 as well. Another thing that Linux does better is having a potentially different type for time_t in the kernel. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 13:47:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 5EB1737B403 for ; Sun, 3 Jun 2001 13:47:48 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f53KlmM39379 for ; Sun, 3 Jun 2001 13:47:48 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 1D1DC380E; Sun, 3 Jun 2001 13:47:48 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: Poul-Henning Kamp , John Polstra , arch@FreeBSD.ORG, drosih@rpi.edu Subject: Re: time_t definition is wrong In-Reply-To: Date: Sun, 03 Jun 2001 13:47:48 -0700 From: Peter Wemm Message-Id: <20010603204748.1D1DC380E@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > On Sun, 3 Jun 2001, Peter Wemm wrote: > > One other thing.. ufs/* should probably have int32_t in the on-disk records > > (eg: struct dquot) rather than time_t. > > Yes, that would be no worse than using int32_t in the inodes. Both are > stictly broken, because time_t's might not be representable as int32_t's, > and if time_t's actually needed more than 32 bits then ffs would have a > difficult task compressing their values into 32 bits. In the superblocks etc it is less of an issue since those can be transparently changed to u_int32_t which will get us to 2106 or whatever. We dont (intentionally) boot machines before 1970 any more, unless somebody has invented time travel without telling me. :-) I was under the impression that the Tru64 folks started out with a 64 bit time_t but ended up backing out to 32 bit since so much application software broke due to on-the-wire and on-disk formats changing and not being interchangeable with their other OS's (including Ultrix). However, since linux is using 64 bit time_t, I suspect we can get away with it too now. I dont think Linus wants to repeat the 32 bit off_t nightmare. > > On things like Tru64 and *BSD/alpha, one has to printf a time_t like this: > > time_t t; > > printf("%ld\n", (long)t); > > Otherwise you get stack misalignment. Alpha has suffered from this for qui te > > a while. > > I think the alpha at least doesn't actually suffer from this, because > it pads all args on the stack to 32 bits, so printf("%ld", (int)t) > leaves the stack aligned for the next argument. Also, the padding > seems to be by sign extension or zero extension, and the machine is > little-endian, so va_arg() sees the correct value when it accesses > the int on the stack as a long. I've never checked this or received > a reply for questions/assertions about this. Actually, I think I'm going to have to contradict myself on this.. On the Alpha, the first 5 arguments are passed through in 5 64 bit registers. It only hits the stack for > 64 bit args or for more than 5 args. I dont know how it does alignment on the stack for < 64 bit sizes. Logically it would either be round-everything-to-64-bit-multiple or use natural algnment since the Alpha cannot read/write unaligned values without going to a LOT of trouble. > > While I understand David's concerns, and agree that something needs to be > > done, I wonder if staying with a 32 bit time_t on a 64 bit platform is > > really the right thing to do... Consider: > > It's not "right", just pragmatic. If programs didn't make assumptions, > then 32-bit time_t's would work fine until 2106. This is much further > away than Y2K was before computer hardware existed. People [ab]used negative time_t's to represent time before 1970 and get a little upset when it gets made unsigned. :-) > > [1:16am]/raid/Linux/dists/v2.4/linux/include-120> grep time_t asm-*/posix_t ypes.h > > asm-alpha/posix_types.h:typedef long __kernel_time_t; > > asm-arm/posix_types.h:typedef long __kernel_time_t; > > asm-i386/posix_types.h:typedef long __kernel_time_t; > > ... > > and linux/types.h: > > #ifndef _TIME_T > > #define _TIME_T > > typedef __kernel_time_t time_t; > > #endif > > > > If linux can get away with a 64 bit time_t, then we should be able to > > figure out a way to do so as well. They deal with running 32 bit binaries > > on 64 bit kernels on mips64, sparc64 and ia64 as well. > > Another thing that Linux does better is having a potentially different type > for time_t in the kernel. It seems to do that for a lot of things. But, in the Linux case, there is no real unified userland/libc/etc. Our libc has a somewhat incestuous relationship with the kernel source and kernel includes.. There is no telling whether a file is going to be private to the kernel or something that is intended for userland, or shared. Linux at least has the kernel stuff in and is solely for userland (which pulls in bits of as appropriate. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 17:54:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from coffee.q9media.com (coffee.q9media.com [216.94.229.19]) by hub.freebsd.org (Postfix) with ESMTP id 0248637B405 for ; Sun, 3 Jun 2001 17:54:46 -0700 (PDT) (envelope-from mike@q9media.com) Received: from [192.168.1.10] (vega.tct.net [216.94.230.13]) by coffee.q9media.com (8.11.2/8.11.2) with ESMTP id f5413uL94683; Sun, 3 Jun 2001 21:03:56 -0400 (EDT) (envelope-from mike@q9media.com) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Sun, 03 Jun 2001 20:54:32 -0400 Subject: Re: Removing __P() (was Re: whois(1) patch) From: Mike Barcroft To: Bruce Evans Cc: , Mike Heffner Message-ID: In-Reply-To: Mime-version: 1.0 Organization: q9 media Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 6/2/01 9:23 AM, Bruce Evans at bde@zeta.org.au wrote: > On Fri, 1 Jun 2001, Mike Barcroft wrote: > >> Does anyone have any objections to removing __P() and converting prototypes >> to ANSI C, as part of binary cleaning up/auditing? > > Yes. It subtracts value and gives more changes to audit. Sorry, I didn't state that question very clearly. I want to silence warnings with WARNS=2 enabled by converting some variables to const char *. Since I'm converting variables to ANSI C types, it makes no sense to care along the __P() support shims because it won't compile on K&R anyway. Am I correct in my assertion? Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 19:18:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 7E17037B406 for ; Sun, 3 Jun 2001 19:18:26 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f542IKS65804; Sun, 3 Jun 2001 22:18:20 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sun, 3 Jun 2001 22:18:18 -0400 To: Mike Barcroft , Bruce Evans From: Garance A Drosihn Subject: Re: Removing __P() (was Re: whois(1) patch) Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:54 PM -0400 6/3/01, Mike Barcroft wrote: >Sorry, I didn't state that question very clearly. I want >to silence warnings with WARNS=2 enabled by converting >some variables to const char *. Since I'm converting >variables to ANSI C types, it makes no sense to carry along >the __P() support shims because it won't compile on K&R anyway. >Am I correct in my assertion? This topic has come up before on the developers list, and the consensus has been that it's alright to do ANSI-fication at a individual program level, as long as you have some other reason to be making "declaration changes" in that same program. That consensus has not been unanimous, but it has been the consensus whenever I've seen it discussed. ANSI-fication of any system include libraries (anything in /usr/include) is pretty much universally discouraged, and might possibly result in some hostility... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 20: 0:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7C3E437B405 for ; Sun, 3 Jun 2001 20:00:47 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA27924; Mon, 4 Jun 2001 13:00:40 +1000 Date: Mon, 4 Jun 2001 12:59:02 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Mike Barcroft Cc: freebsd-arch@freebsd.org, Mike Heffner Subject: Re: Removing __P() (was Re: whois(1) patch) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 3 Jun 2001, Mike Barcroft wrote: > On 6/2/01 9:23 AM, Bruce Evans at bde@zeta.org.au wrote: > > > On Fri, 1 Jun 2001, Mike Barcroft wrote: > > > >> Does anyone have any objections to removing __P() and converting prototypes > >> to ANSI C, as part of binary cleaning up/auditing? > > > > Yes. It subtracts value and gives more changes to audit. > > Sorry, I didn't state that question very clearly. I want to silence > warnings with WARNS=2 enabled by converting some variables to const char *. > Since I'm converting variables to ANSI C types, it makes no sense to care > along the __P() support shims because it won't compile on K&R anyway. Am I > correct in my assertion? Not completely. "const" can usually be defined away by compiling with -Dconst=. has some support for sort of the reverse of this -- it defines away "const" and some other keywords by default if the compiler is "gcc -traditional", but compiling with -DNO_ANSI_KEYWORDS prevents this. Very old programs may have variables named "const" and defining away "const" would just break them, but defining away "const" usually works for K&R programs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jun 3 22:45:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.chem.msu.ru (mail.chem.msu.ru [195.208.208.19]) by hub.freebsd.org (Postfix) with ESMTP id AABF537B401; Sun, 3 Jun 2001 22:45:06 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su ([158.250.32.97]) by mail.chem.msu.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LR567XRR; Mon, 4 Jun 2001 09:42:00 +0400 Received: (from yar@localhost) by comp.chem.msu.su (8.11.1/8.11.1) id f545j4048540; Mon, 4 Jun 2001 09:45:04 +0400 (MSD) (envelope-from yar) Date: Mon, 4 Jun 2001 09:45:03 +0400 From: Yar Tikhiy To: Greg Lehey Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_gif.c Message-ID: <20010604094503.A43248@comp.chem.msu.su> References: <200106031731.f53HVBA42280@freefall.freebsd.org> <20010604094827.N85812@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010604094827.N85812@wantadilla.lemis.com>; from grog@FreeBSD.org on Mon, Jun 04, 2001 at 09:48:27AM +0930 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Added freebsd-arch to the Cc: list] On Mon, Jun 04, 2001 at 09:48:27AM +0930, Greg Lehey wrote: > On Sunday, 3 June 2001 at 10:31:11 -0700, Yar Tikhiy wrote: > > yar 2001/06/03 10:31:11 PDT > > > > Modified files: > > sys/net if_gif.c > > Log: > > First, wrap the if_up() call into splimp()/splx() because > > if_up() must be called at splnet or higher. > > Second, set the IFF_RUNNING flag on an interface after its > > resources (i.e. tunnel source and destination addresses) > > have been set. Note that we don't set IFF_UP because it is > > if_up()'s job to do that. > > Presumably this is in preparation for an MFC? splimp() and splx() are > nops in -CURRENT. Thank you for pointing me out that. Indeed, I've missed the change. BTW, could anyone tell me what is the modern state of affairs as to locks in the networking code? The comments and man pages are still talking about splnet in -current, so they need to be fixed, but what should one write there instead? The IF_ENQUEUE case is obvious: Forget about splnet() and the manual modification of counters, just use IF_HANDOFF instead of IF_ENQUEUE. But what about other places where splnet/splimp is used? There are quite a few of them there... -- Yar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 8:47:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id B064237B403; Mon, 4 Jun 2001 08:47:19 -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 LAA76688; Mon, 4 Jun 2001 11:47:18 -0400 (EDT) (envelope-from wollman) Date: Mon, 4 Jun 2001 11:47:18 -0400 (EDT) From: Garrett Wollman Message-Id: <200106041547.LAA76688@khavrinen.lcs.mit.edu> To: obrien@FreeBSD.org Cc: arch@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong In-Reply-To: <20010602142011.N31257@dragon.nuxi.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > time_t needs to be consistent across all FreeBSD platforms. No, it doesn't. > Otherwise we get in consistent behavior across our platforms. Which will always be the case given that some platforms are ILP32 and some are LP64. s/time_t/size_t/g and see where that argument gets you. > This includes both the size of it, and the spelling of the printf() > format specifier. Nonsense. Any program which attempts to print a time_t without casting appropriately is simply, flat-out, wrong, and has been wrong for more than ten years now. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 11:10:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D064837B419; Mon, 4 Jun 2001 11:10:03 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f54I9xG17035; Mon, 4 Jun 2001 11:09:59 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010604094503.A43248@comp.chem.msu.su> Date: Mon, 04 Jun 2001 11:10:03 -0700 (PDT) From: John Baldwin To: Yar Tikhiy Subject: Re: cvs commit: src/sys/net if_gif.c Cc: freebsd-arch@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Greg Lehey Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 04-Jun-01 Yar Tikhiy wrote: > [Added freebsd-arch to the Cc: list] > > On Mon, Jun 04, 2001 at 09:48:27AM +0930, Greg Lehey wrote: >> On Sunday, 3 June 2001 at 10:31:11 -0700, Yar Tikhiy wrote: >> > yar 2001/06/03 10:31:11 PDT >> > >> > Modified files: >> > sys/net if_gif.c >> > Log: >> > First, wrap the if_up() call into splimp()/splx() because >> > if_up() must be called at splnet or higher. >> > Second, set the IFF_RUNNING flag on an interface after its >> > resources (i.e. tunnel source and destination addresses) >> > have been set. Note that we don't set IFF_UP because it is >> > if_up()'s job to do that. >> >> Presumably this is in preparation for an MFC? splimp() and splx() are >> nops in -CURRENT. > > Thank you for pointing me out that. Indeed, I've missed the change. > > BTW, could anyone tell me what is the modern state of affairs as > to locks in the networking code? The comments and man pages are > still talking about splnet in -current, so they need to be fixed, > but what should one write there instead? The IF_ENQUEUE case is > obvious: Forget about splnet() and the manual modification of > counters, just use IF_HANDOFF instead of IF_ENQUEUE. But what about > other places where splnet/splimp is used? There are quite a few of > them there... The networking stack is not locked with locks yet, so just use spl's for now. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 11:51:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 6B67C37B401; Mon, 4 Jun 2001 11:51:28 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.2/8.11.2) with ESMTP id f54IpR533116; Mon, 4 Jun 2001 12:51:27 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <200106041851.f54IpR533116@orthanc.ab.ca> From: Lyndon Nerenberg Organization: The Frobozz Magic Homing Pigeon Company To: obrien@FreeBSD.ORG Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-reply-to: Your message of "Sat, 02 Jun 2001 12:47:32 PDT." <20010602124732.F31257@dragon.nuxi.com> Date: Mon, 04 Jun 2001 12:51:27 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> "David" == David O'Brien writes: David> time_t is 32-bits without David> question. Upon what do you base that assertion? The return value from time() is long because returning an int on a 16 bit machine wouldn't make sense. I don't think you can extend that out to say that making it long meant making it exactly 32 bits. The intent was to use a type at least as big as an int, but preferably larger, which is the exact definition of a long. Maximizing the size of time()'s return value gave the greatest useful range of times, and I see no reason to change that now. (I don't see anything in the Seventh Edition manual to indicate that time() should return exactly-32-bit values.) --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 12:24:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id DAB2437B401 for ; Mon, 4 Jun 2001 12:24:43 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f54JO4A07497 for ; Mon, 4 Jun 2001 12:24:04 -0700 (PDT) Received: from [172.30.50.1] by pain.corp.disney.com with ESMTP for freebsd-arch@freebsd.org; Mon, 4 Jun 2001 12:25:18 -0700 Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id MAA25466 for ; Mon, 4 Jun 2001 12:24:27 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from snoopy.fan.fa.disney.com by mercury.fan.fa.disney.com for freebsd-arch@freebsd.org; Mon, 4 Jun 2001 12:24:27 -0700 Content-Type: text/plain; charset="us-ascii" From: Jim Pirzyk Organization: Walt Disney Feature Animation To: freebsd-arch@freebsd.org Subject: sysctl interger type max Date: Mon, 4 Jun 2001 12:24:27 -0700 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01060412242703.00744@snoopy> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In sysctl(8), you can set an integer type, but the max value an int can be is 2 * N-1 where N is the size of int. This leads to a problem when trying to set kern.hostid and the number is greater that 2GB on an IA32 system. So my question is should CTLTYPE_INT be treated as a long or some other larger numeric number? Or should we declare some CLTYPE_UINT type? If there is going to be overflow, should it not be because of the sysctl being set and not because of the sysctl(8) causing it? See PR kern/21132 for an instance. - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 12:26:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id E302F37B406 for ; Mon, 4 Jun 2001 12:26:51 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f54JQZ161125; Mon, 4 Jun 2001 21:26:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jim Pirzyk Cc: freebsd-arch@FreeBSD.ORG Subject: Re: sysctl interger type max In-Reply-To: Your message of "Mon, 04 Jun 2001 12:24:27 PDT." <01060412242703.00744@snoopy> Date: Mon, 04 Jun 2001 21:26:35 +0200 Message-ID: <61123.991682795@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <01060412242703.00744@snoopy>, Jim Pirzyk writes: >In sysctl(8), you can set an integer type, but the max value >an int can be is 2 * N-1 where N is the size of int. This leads >to a problem when trying to set kern.hostid and the number is >greater that 2GB on an IA32 system. So my question is should >CTLTYPE_INT be treated as a long or some other larger numeric >number? Or should we declare some CLTYPE_UINT type? We do have an SYSCTL_UINT these days. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 12:36:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id BAB9737B401 for ; Mon, 4 Jun 2001 12:36:19 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f54JZeA16547 for ; Mon, 4 Jun 2001 12:35:40 -0700 (PDT) Received: from [172.30.50.1] by pain.corp.disney.com with ESMTP for freebsd-arch@FreeBSD.ORG; Mon, 4 Jun 2001 12:37:09 -0700 Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id MAA27215 for ; Mon, 4 Jun 2001 12:36:18 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from snoopy.fan.fa.disney.com by mercury.fan.fa.disney.com; Mon, 4 Jun 2001 12:36:18 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Jim Pirzyk Organization: Walt Disney Feature Animation To: Poul-Henning Kamp Subject: Re: sysctl interger type max Date: Mon, 4 Jun 2001 12:36:18 -0700 X-Mailer: KMail [version 1.2] Cc: freebsd-arch@FreeBSD.ORG References: <61123.991682795@critter> In-Reply-To: <61123.991682795@critter> MIME-Version: 1.0 Message-Id: <01060412361804.00744@snoopy> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 04 June 2001 12:26 pm, Poul-Henning Kamp wrote: > In message <01060412242703.00744@snoopy>, Jim Pirzyk writes: > >In sysctl(8), you can set an integer type, but the max value > >an int can be is 2 * N-1 where N is the size of int. This leads > >to a problem when trying to set kern.hostid and the number is > >greater that 2GB on an IA32 system. So my question is should > >CTLTYPE_INT be treated as a long or some other larger numeric > >number? Or should we declare some CLTYPE_UINT type? > > We do have an SYSCTL_UINT these days. Yes for establishing the oid in the kernel, but sysctl command line is limited to 2 * 31 bits even if the variable is set to CLTYPE_{UINT|LONG|ULONG}. This means you cannot set the variables to a possible range of values. - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 12:44: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0874E37B403 for ; Mon, 4 Jun 2001 12:44:06 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f54Jht161284; Mon, 4 Jun 2001 21:43:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jim Pirzyk Cc: freebsd-arch@FreeBSD.ORG Subject: Re: sysctl interger type max In-Reply-To: Your message of "Mon, 04 Jun 2001 12:36:18 PDT." <01060412361804.00744@snoopy> Date: Mon, 04 Jun 2001 21:43:55 +0200 Message-ID: <61282.991683835@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <01060412361804.00744@snoopy>, Jim Pirzyk writes: >On Monday 04 June 2001 12:26 pm, Poul-Henning Kamp wrote: >> In message <01060412242703.00744@snoopy>, Jim Pirzyk writes: >> >In sysctl(8), you can set an integer type, but the max value >> >an int can be is 2 * N-1 where N is the size of int. This leads >> >to a problem when trying to set kern.hostid and the number is >> >greater that 2GB on an IA32 system. So my question is should >> >CTLTYPE_INT be treated as a long or some other larger numeric >> >number? Or should we declare some CLTYPE_UINT type? >> >> We do have an SYSCTL_UINT these days. > >Yes for establishing the oid in the kernel, but sysctl command >line is limited to 2 * 31 bits even if the variable is set to >CLTYPE_{UINT|LONG|ULONG}. This means you cannot set the variables >to a possible range of values. Then sysctl(8) is obviously broken... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 12:49:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.disney.com (mail.disney.com [204.128.192.15]) by hub.freebsd.org (Postfix) with ESMTP id A7BD337B401 for ; Mon, 4 Jun 2001 12:49:26 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100]) by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f54JmlA26857 for ; Mon, 4 Jun 2001 12:48:47 -0700 (PDT) Received: from [172.30.50.1] by pain.corp.disney.com with ESMTP for freebsd-arch@FreeBSD.ORG; Mon, 4 Jun 2001 12:50:14 -0700 Received: from mercury.fan.fa.disney.com (mercury.fan.fa.disney.com [153.7.119.1]) by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id MAA29405 for ; Mon, 4 Jun 2001 12:49:14 -0700 (PDT) (envelope-from Jim.Pirzyk@disney.com) Received: from snoopy.fan.fa.disney.com by mercury.fan.fa.disney.com; Mon, 4 Jun 2001 12:49:14 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Jim Pirzyk Organization: Walt Disney Feature Animation To: Poul-Henning Kamp Subject: Re: sysctl interger type max Date: Mon, 4 Jun 2001 12:49:14 -0700 X-Mailer: KMail [version 1.2] Cc: freebsd-arch@FreeBSD.ORG References: <61282.991683835@critter> In-Reply-To: <61282.991683835@critter> MIME-Version: 1.0 Message-Id: <01060412491406.00744@snoopy> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 04 June 2001 12:43 pm, Poul-Henning Kamp wrote: > In message <01060412361804.00744@snoopy>, Jim Pirzyk writes: > >On Monday 04 June 2001 12:26 pm, Poul-Henning Kamp wrote: > >> In message <01060412242703.00744@snoopy>, Jim Pirzyk writes: > >> >In sysctl(8), you can set an integer type, but the max value > >> >an int can be is 2 * N-1 where N is the size of int. This leads > >> >to a problem when trying to set kern.hostid and the number is > >> >greater that 2GB on an IA32 system. So my question is should > >> >CTLTYPE_INT be treated as a long or some other larger numeric > >> >number? Or should we declare some CLTYPE_UINT type? > >> > >> We do have an SYSCTL_UINT these days. > > > >Yes for establishing the oid in the kernel, but sysctl command > >line is limited to 2 * 31 bits even if the variable is set to > >CLTYPE_{UINT|LONG|ULONG}. This means you cannot set the variables > >to a possible range of values. > > Then sysctl(8) is obviously broken... Yes, so how should it be fixed? Add another CTLTYPE_* or make CTLTYPE_INT handle say up to 'long long'? - JimP -- --- @(#) $Id: dot.signature,v 1.10 2001/05/17 23:38:49 Jim.Pirzyk Exp $ __o Jim.Pirzyk@disney.com ------------- pirzyk@freebsd.org _'\<,_ Senior Systems Engineer, Walt Disney Feature Animation (*)/ (*) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 15:19:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 12B6A37B401; Mon, 4 Jun 2001 15:19:32 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 04C996ACC0; Tue, 5 Jun 2001 07:49:30 +0930 (CST) Date: Tue, 5 Jun 2001 07:49:29 +0930 From: Greg Lehey To: John Baldwin Cc: Yar Tikhiy , freebsd-arch@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_gif.c Message-ID: <20010605074929.V99950@wantadilla.lemis.com> References: <20010604094503.A43248@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Mon, Jun 04, 2001 at 11:10:03AM -0700 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 4 June 2001 at 11:10:03 -0700, John Baldwin wrote: > > On 04-Jun-01 Yar Tikhiy wrote: >> [Added freebsd-arch to the Cc: list] >> >> On Mon, Jun 04, 2001 at 09:48:27AM +0930, Greg Lehey wrote: >>> On Sunday, 3 June 2001 at 10:31:11 -0700, Yar Tikhiy wrote: >>>> yar 2001/06/03 10:31:11 PDT >>>> >>>> Modified files: >>>> sys/net if_gif.c >>>> Log: >>>> First, wrap the if_up() call into splimp()/splx() because >>>> if_up() must be called at splnet or higher. >>>> Second, set the IFF_RUNNING flag on an interface after its >>>> resources (i.e. tunnel source and destination addresses) >>>> have been set. Note that we don't set IFF_UP because it is >>>> if_up()'s job to do that. >>> >>> Presumably this is in preparation for an MFC? splimp() and splx() are >>> nops in -CURRENT. >> >> Thank you for pointing me out that. Indeed, I've missed the change. >> >> BTW, could anyone tell me what is the modern state of affairs as >> to locks in the networking code? The comments and man pages are >> still talking about splnet in -current, so they need to be fixed, >> but what should one write there instead? The IF_ENQUEUE case is >> obvious: Forget about splnet() and the manual modification of >> counters, just use IF_HANDOFF instead of IF_ENQUEUE. But what about >> other places where splnet/splimp is used? There are quite a few of >> them there... > > The networking stack is not locked with locks yet, so just use spl's > for now. Why? They still don't do anything. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 16:25:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 2211237B403 for ; Mon, 4 Jun 2001 16:25:51 -0700 (PDT) (envelope-from huntting@hunkular.glarp.com) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.3/8.11.3) with ESMTP id f54NPoL77213 for ; Mon, 4 Jun 2001 17:25:50 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200106042325.f54NPoL77213@hunkular.glarp.com> To: freebsd-arch@freebsd.org Subject: changing timezones From: huntting@glarp.com Date: Mon, 04 Jun 2001 17:25:50 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG When /etc/localtime changes (because the machine moves to a different timezone), how is one supposed keep up on current temporal events? I get the feeling tzset() and tzsetwall() should be checking to see if the timezone has changed since they were last called (they dont currently). Any thoughts? brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19: 0:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 5E27037B401 for ; Mon, 4 Jun 2001 19:00:42 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f5520el97752; Mon, 4 Jun 2001 19:00:41 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f5520W845918; Mon, 4 Jun 2001 19:00:32 -0700 (PDT) (envelope-from obrien) Date: Mon, 4 Jun 2001 19:00:32 -0700 From: "David O'Brien" To: Lyndon Nerenberg Cc: Matt Dillon , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <20010604190032.A45775@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010602124732.F31257@dragon.nuxi.com> <200106041851.f54IpR533116@orthanc.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106041851.f54IpR533116@orthanc.ab.ca>; from lyndon@orthanc.ab.ca on Mon, Jun 04, 2001 at 12:51:27PM -0600 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 04, 2001 at 12:51:27PM -0600, Lyndon Nerenberg wrote: > > David> time_t is 32-bits without > David> question. > > Upon what do you base that assertion? Virtually every other Unix in existance uses a 32-bit time_t. > The return value from time() is long because returning an int on a 16 > bit machine wouldn't make sense. You are now arguing the *spelling* of the 32-bit type. What does that have to do with it being a 32-bit type? > Maximizing the size of time()'s return value gave the greatest useful > range of times, and I see no reason to change that now. I value consistenacy across our platforms. > (I don't see anything in the Seventh Edition manual to indicate that > time() should return exactly-32-bit values.) There are a *LOT* of things not explicity documented in Seventh Edition yet are followed to this day. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19: 2:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A41F437B406 for ; Mon, 4 Jun 2001 19:02:39 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5522Z434463; Mon, 4 Jun 2001 19:02:35 -0700 (PDT) (envelope-from dillon) Date: Mon, 4 Jun 2001 19:02:35 -0700 (PDT) From: Matt Dillon Message-Id: <200106050202.f5522Z434463@earth.backplane.com> To: huntting@glarp.com Cc: freebsd-arch@FreeBSD.ORG Subject: Re: changing timezones References: <200106042325.f54NPoL77213@hunkular.glarp.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :When /etc/localtime changes (because the machine moves to a different :timezone), how is one supposed keep up on current temporal events? : :I get the feeling tzset() and tzsetwall() should be checking to :see if the timezone has changed since they were last called (they :dont currently). : :Any thoughts? : :brad Well, you definitely don't want to rip the current timezone out from under a running program. That could lead to a mess. I do occassionally notice timezone issues from long running programs such as sendmail and syslogd when I've forgotten to set the timezone in a new install, but I usually just reboot to ensure that everything has started from a clean slate. It is also fairly easily to simply restart the effected servers. I'm not sure an automated solution is really desireable. Timezones generally never change except maybe on a laptop and laptops get powered up and down all the time anyway. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19: 5:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 72C2637B401 for ; Mon, 4 Jun 2001 19:04:58 -0700 (PDT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (root@spare0.gsoft.com.au [203.38.152.114]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id LAA01774; Tue, 5 Jun 2001 11:34:30 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.7 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200106050202.f5522Z434463@earth.backplane.com> Date: Tue, 05 Jun 2001 11:34:29 +0930 (CST) From: "Daniel O'Connor" To: Matt Dillon Subject: Re: changing timezones Cc: freebsd-arch@FreeBSD.ORG, huntting@glarp.com Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 05-Jun-2001 Matt Dillon wrote: > slate. It is also fairly easily to simply restart the > effected servers. I'm not sure an automated solution is really > desireable. Timezones generally never change except maybe > on a laptop and laptops get powered up and down all the time > anyway. Unless your suspend to disk works in which case you basically never power off for real :) (At least I don't). --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19: 6:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 089F037B401; Mon, 4 Jun 2001 19:06:55 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5526so34511; Mon, 4 Jun 2001 19:06:54 -0700 (PDT) (envelope-from dillon) Date: Mon, 4 Jun 2001 19:06:54 -0700 (PDT) From: Matt Dillon Message-Id: <200106050206.f5526so34511@earth.backplane.com> To: "David O'Brien" Cc: Lyndon Nerenberg , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng References: <20010602124732.F31257@dragon.nuxi.com> <200106041851.f54IpR533116@orthanc.ab.ca> <20010604190032.A45775@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Mon, Jun 04, 2001 at 12:51:27PM -0600, Lyndon Nerenberg wrote: :> :> David> time_t is 32-bits without :> David> question. :> :> Upon what do you base that assertion? : :Virtually every other Unix in existance uses a 32-bit time_t. : :> The return value from time() is long because returning an int on a 16 :> bit machine wouldn't make sense. : :You are now arguing the *spelling* of the 32-bit type. :What does that have to do with it being a 32-bit type? :... :-- :-- David (obrien@FreeBSD.org) Having written a C compiler, I can say with authority that there is a big difference between 'int' and 'long' declarations, even if they do wind up being the same size. The machine code may wind up the same but there are serious ramifications involved in regards to porting and maintaining the source code. So it does matter. Quite a lot. But, you know, your argument works both ways. If long vs int aren't different from each other from your point of view, then why the hell did you change the long to an int on IA32 in the first place? I just don't buy it, David. It's obviously important to you so you can hardly refute someone else's argument by reversing yourself. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19: 9: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9F46237B405 for ; Mon, 4 Jun 2001 19:08:58 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5528eR34540; Mon, 4 Jun 2001 19:08:40 -0700 (PDT) (envelope-from dillon) Date: Mon, 4 Jun 2001 19:08:40 -0700 (PDT) From: Matt Dillon Message-Id: <200106050208.f5528eR34540@earth.backplane.com> To: "Daniel O'Connor" Cc: freebsd-arch@FreeBSD.ORG, huntting@glarp.com Subject: Re: changing timezones References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : : :On 05-Jun-2001 Matt Dillon wrote: :> slate. It is also fairly easily to simply restart the :> effected servers. I'm not sure an automated solution is really :> desireable. Timezones generally never change except maybe :> on a laptop and laptops get powered up and down all the time :> anyway. : :Unless your suspend to disk works in which case you basically never power off :for real :) : :(At least I don't). : :--- :Daniel O'Connor software and network engineer Hah. I don't trust laptops that much. Besides, I don't mind waiting the 30 seconds or so it takes to boot. Of course, in time the battery and power savings capabilties will mean that you won't have to suspend to disk at all. Just keep the thing on 24x7 serving up your personal web pages! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19:24:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 3B4EA37B403 for ; Mon, 4 Jun 2001 19:24:52 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id 845DE6ACC0; Tue, 5 Jun 2001 11:54:50 +0930 (CST) Date: Tue, 5 Jun 2001 11:54:50 +0930 From: Greg Lehey To: Matt Dillon Cc: Daniel O'Connor , freebsd-arch@FreeBSD.ORG, huntting@glarp.com Subject: Re: changing timezones Message-ID: <20010605115450.N95379@wantadilla.lemis.com> References: <200106050208.f5528eR34540@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106050208.f5528eR34540@earth.backplane.com>; from dillon@earth.backplane.com on Mon, Jun 04, 2001 at 07:08:40PM -0700 Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, 4 June 2001 at 19:08:40 -0700, Matt Dillon wrote: > Daniel O'Connor wrote at some indeterminate time: >> On 05-Jun-2001 Matt Dillon wrote: >>> slate. It is also fairly easily to simply restart the >>> effected servers. I'm not sure an automated solution is really >>> desireable. Timezones generally never change except maybe >>> on a laptop and laptops get powered up and down all the time >>> anyway. >> >> Unless your suspend to disk works in which case you basically never power off >> for real :) >> >> (At least I don't). > > Hah. I don't trust laptops that much. Besides, I don't mind > waiting the 30 seconds or so it takes to boot. Your choice, of course. I do. > Of course, in time the battery and power savings capabilties > will mean that you won't have to suspend to disk at all. Just > keep the thing on 24x7 serving up your personal web pages! Well, I don't suspend to disk, but indeed in suspend mode my laptop will last for a week or so, far longer than I am ever away from a power point. I still don't understand what you're saying about programs not liking the time zone changing from under them. Typically any program which uses time zones will access /etc/timezone once only. It remains stuck in that time zone. That may be a nuisance (I find it annoying with syslogd, for example, but kill -1 will fix that). I frequently fly transpacific without rebooting, but change through all time zones where I stop over. I've never had any problems. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 19:50:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id F17C737B405; Mon, 4 Jun 2001 19:50:19 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f552oJC34814; Mon, 4 Jun 2001 19:50:19 -0700 (PDT) (envelope-from dillon) Date: Mon, 4 Jun 2001 19:50:19 -0700 (PDT) From: Matt Dillon Message-Id: <200106050250.f552oJC34814@earth.backplane.com> To: Greg Lehey Cc: "Daniel O'Connor" , freebsd-arch@FreeBSD.org, huntting@glarp.com Subject: Re: changing timezones References: <200106050208.f5528eR34540@earth.backplane.com> <20010605115450.N95379@wantadilla.lemis.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :I still don't understand what you're saying about programs not liking :the time zone changing from under them. Typically any program which :uses time zones will access /etc/timezone once only. It remains stuck :in that time zone. That may be a nuisance (I find it annoying with :syslogd, for example, but kill -1 will fix that). I frequently fly :transpacific without rebooting, but change through all time zones :where I stop over. I've never had any problems. : :Greg I think you missed the original article. The idea was to try to have a running programming automatically detect the timezone change and adjust its internal state accordingly. Doing that automatically without the programming knowing isn't a good idea. Adding code to sendmail, syslogd, cron, etc... to detect the change at a safe point, on the otherhand, might be interesting. But, ultimately, I think it would be kind of a waste of programming hours to do. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jun 4 23: 0:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0182237B405 for ; Mon, 4 Jun 2001 23:00:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f555x1165711; Tue, 5 Jun 2001 07:59:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jim Pirzyk Cc: freebsd-arch@FreeBSD.ORG Subject: Re: sysctl interger type max In-Reply-To: Your message of "Mon, 04 Jun 2001 12:49:14 PDT." <01060412491406.00744@snoopy> Date: Tue, 05 Jun 2001 07:59:01 +0200 Message-ID: <65709.991720741@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <01060412491406.00744@snoopy>, Jim Pirzyk writes: >On Monday 04 June 2001 12:43 pm, Poul-Henning Kamp wrote: >> In message <01060412361804.00744@snoopy>, Jim Pirzyk writes: >> >On Monday 04 June 2001 12:26 pm, Poul-Henning Kamp wrote: >> >> In message <01060412242703.00744@snoopy>, Jim Pirzyk writes: >> >> >In sysctl(8), you can set an integer type, but the max value >> >> >an int can be is 2 * N-1 where N is the size of int. This leads >> >> >to a problem when trying to set kern.hostid and the number is >> >> >greater that 2GB on an IA32 system. So my question is should >> >> >CTLTYPE_INT be treated as a long or some other larger numeric >> >> >number? Or should we declare some CLTYPE_UINT type? >> >> >> >> We do have an SYSCTL_UINT these days. >> > >> >Yes for establishing the oid in the kernel, but sysctl command >> >line is limited to 2 * 31 bits even if the variable is set to >> >CLTYPE_{UINT|LONG|ULONG}. This means you cannot set the variables >> >to a possible range of values. >> >> Then sysctl(8) is obviously broken... > >Yes, so how should it be fixed? Add another CTLTYPE_* or make >CTLTYPE_INT handle say up to 'long long'? CTLTYPE_UINT should be fixed in sysctl(8) to handle [0..2^32-1] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jun 5 13: 1:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 0A19037B403; Tue, 5 Jun 2001 13:01:29 -0700 (PDT) (envelope-from huntting@hunkular.glarp.com) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.3/8.11.3) with ESMTP id f55K1IL31726; Tue, 5 Jun 2001 14:01:18 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200106052001.f55K1IL31726@hunkular.glarp.com> To: Matt Dillon Cc: Greg Lehey , "Daniel O'Connor" , freebsd-arch@FreeBSD.ORG, huntting@glarp.com Subject: Re: changing timezones In-Reply-To: Your message of "Mon, 04 Jun 2001 19:50:19 PDT." <200106050250.f552oJC34814@earth.backplane.com> Date: Tue, 05 Jun 2001 14:01:18 -0600 From: Brad Huntting Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I think you missed the original article. The idea was to try to > have a running programming automatically detect the timezone change > and adjust its internal state accordingly. Doing that automatically > without the programming knowing isn't a good idea. I doubt there are many programs that would mind having the timezone change. They already have to cope with daylight saving changes. > Adding code to sendmail, syslogd, cron, etc... to detect the change > at a safe point, on the other hand, might be interesting. But, > ultimately, I think it would be kind of a waste of programming > hours to do. Changing IP addresses or DNS nameserver addresses used to involve a reboot and that was reasonable at the time because machines didnt change addresses very often. Changing usage patterns called for a better solution. Similarly, we need to be able to handle the typical usage patterns of mobile workstations as they will only becoming more popular. And IMHO, changing timezones qualifies as a typical event for a mobile workstation. That said, I dont think it's unreasonable to require a HUP for servers that are sensitive to timezone changes. My main question is: Should calling tzset() or tzsetwall() force /etc/localtime or the TZ environment variable to be rescaned? Should calling localtime() rescan /etc/localtime and/or $TZ? brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 6 11:22:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sdmail0.sd.bmarts.com (sdmail0.sd.bmarts.com [209.247.77.155]) by hub.freebsd.org (Postfix) with ESMTP id 4231D37B401; Wed, 6 Jun 2001 11:22:32 -0700 (PDT) (envelope-from gordont@bluemtn.net) Received: from localhost (gordont@localhost) by sdmail0.sd.bmarts.com (8.11.3/8.11.2/BMA1.1) with ESMTP id f56IJjV64298; Wed, 6 Jun 2001 11:19:45 -0700 (PDT) Date: Wed, 6 Jun 2001 11:19:45 -0700 (PDT) From: Gordon Tetlow X-X-Sender: To: Matt Dillon Cc: Greg Lehey , "Daniel O'Connor" , , Subject: Re: changing timezones In-Reply-To: <200106050250.f552oJC34814@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 4 Jun 2001, Matt Dillon wrote: > I think you missed the original article. The idea was to try to > have a running programming automatically detect the timezone change > and adjust its internal state accordingly. Doing that automatically > without the programming knowing isn't a good idea. > > Adding code to sendmail, syslogd, cron, etc... to detect the change > at a safe point, on the otherhand, might be interesting. But, > ultimately, I think it would be kind of a waste of programming > hours to do. It would be really interesting when it came to processing your logs with a TZ shift in them as well. cron is a special case (and has been discussed ad nauseum before) as it's business is to keep track of time. -gordon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 6 13:13:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 62AA137B406; Wed, 6 Jun 2001 13:13:07 -0700 (PDT) (envelope-from huntting@hunkular.glarp.com) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.3/8.11.3) with ESMTP id f56KCtL07777; Wed, 6 Jun 2001 14:12:56 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200106062012.f56KCtL07777@hunkular.glarp.com> To: Gordon Tetlow Cc: Matt Dillon , Greg Lehey , "Daniel O'Connor" , freebsd-arch@FreeBSD.ORG, huntting@glarp.com Subject: Re: changing timezones In-Reply-To: Your message of "Wed, 06 Jun 2001 11:19:45 PDT." Date: Wed, 06 Jun 2001 14:12:55 -0600 From: Brad Huntting Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > It would be really interesting when it came to processing your logs with a > TZ shift in them as well. cron is a special case (and has been discussed > ad nauseum before) as it's business is to keep track of time. But you have this with daylight savings anyway. If one is truely concerned about usable timestamps in logfiles, the answer is usually to use UTC. brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 6 18:40:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 2939737B405 for ; Wed, 6 Jun 2001 18:40:48 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f571eXR16475; Wed, 6 Jun 2001 18:40:33 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f571eTu45944; Wed, 6 Jun 2001 18:40:29 -0700 (PDT) (envelope-from obrien) Date: Wed, 6 Jun 2001 18:40:29 -0700 From: "David O'Brien" To: Matt Dillon Cc: Lyndon Nerenberg , David Wolfskill , arch@FreeBSD.ORG Subject: Re: time_t definition is worng Message-ID: <20010606184029.B45892@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010602124732.F31257@dragon.nuxi.com> <200106041851.f54IpR533116@orthanc.ab.ca> <20010604190032.A45775@dragon.nuxi.com> <200106050206.f5526so34511@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106050206.f5526so34511@earth.backplane.com>; from dillon@earth.backplane.com on Mon, Jun 04, 2001 at 07:06:54PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 04, 2001 at 07:06:54PM -0700, Matt Dillon wrote: > But, you know, your argument works both ways. If long vs int aren't > different from each other from your point of view, then why the hell > did you change the long to an int on IA32 in the first place? I just > don't buy it, David. It's obviously important to you so you can hardly > refute someone else's argument by reversing yourself. I am not reversing myself. My position is (1) FreeBSD uses 32-bit time_t everywhere, (2) a consistent spelling of that 32-bit object. How is what I said reversing myself? The email I replied to also said time_t should be 32-bits, but should be spelled `long' since that is the only way to get a 32-bit type on a 16-bit machine. Since FreeBSD will never run on a 16-bit machine, this is not something we need to consern ourselves with. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jun 6 18:48: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id E415337B403 for ; Wed, 6 Jun 2001 18:47:58 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.nuxi.com [206.40.252.115]) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f571lsR16499; Wed, 6 Jun 2001 18:47:54 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f571lre46031; Wed, 6 Jun 2001 18:47:53 -0700 (PDT) (envelope-from obrien) Date: Wed, 6 Jun 2001 18:47:53 -0700 From: "David O'Brien" To: Garrett Wollman Cc: arch@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010606184753.C45892@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> <200106041547.LAA76688@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106041547.LAA76688@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Mon, Jun 04, 2001 at 11:47:18AM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jun 04, 2001 at 11:47:18AM -0400, Garrett Wollman wrote: > > time_t needs to be consistent across all FreeBSD platforms. > > No, it doesn't. > > > Otherwise we get in consistent behavior across our platforms. > > Which will always be the case given that some platforms are ILP32 and > some are LP64. s/time_t/size_t/g and see where that argument gets > you. With size_t you want to be able to hold the largest number you can. It is used for lengths, etc.. where you don't want wrap around. In time_t's case we already know we will get a wrap around, and in my mind all our plaforms should do it at the same point. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 8:44:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 86E7537B406; Thu, 7 Jun 2001 08:44:09 -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 LAA24831; Thu, 7 Jun 2001 11:44:08 -0400 (EDT) (envelope-from wollman) Date: Thu, 7 Jun 2001 11:44:08 -0400 (EDT) From: Garrett Wollman Message-Id: <200106071544.LAA24831@khavrinen.lcs.mit.edu> To: obrien@FreeBSD.org Cc: arch@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong In-Reply-To: <20010606184753.C45892@dragon.nuxi.com> References: <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> <200106041547.LAA76688@khavrinen.lcs.mit.edu> <20010606184753.C45892@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > With size_t you want to be able to hold the largest number you can. No. size_t is the *smallest* type which can hold the result of `sizeof' on the largest addressable single object. On an IP32/L64 architecture (e.g., GCC/i386 when configured in that mode), size_t should be `unsigned int'. On I32/P48/L64 (think i386 in segmented protected mode) it would still be `unsigned int'. There are specific requirements for each of these types -- not all of which are spelled out explicitly in the standards. (In the Austin Group we were actually able to pin down a couple of these types with a bit more certainty by deducing properties of the type from what other parts of the standards said one could do with it.) As for time_t, I think `int' is a perfectly good definition, and has the beneficial effect that code which takes erroneous shortcuts will now generate warnings. `long' is appropriate as well, and has some POLA benefits. `long long' would be very much inadvisable at this time, and probably for several years to come, since C99 compilers are just now starting to become available, and we still don't have a C99 Standard Library. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 10: 4:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 1CD8837B401 for ; Thu, 7 Jun 2001 10:04:07 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f57H3wR20882; Thu, 7 Jun 2001 10:03:58 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f57H3sZ93416; Thu, 7 Jun 2001 10:03:54 -0700 (PDT) (envelope-from obrien) Date: Thu, 7 Jun 2001 10:03:39 -0700 From: "David O'Brien" To: Garrett Wollman Cc: arch@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010607100339.A92620@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> <200106041547.LAA76688@khavrinen.lcs.mit.edu> <20010606184753.C45892@dragon.nuxi.com> <200106071544.LAA24831@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106071544.LAA24831@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Thu, Jun 07, 2001 at 11:44:08AM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jun 07, 2001 at 11:44:08AM -0400, Garrett Wollman wrote: > (In the Austin Group we were actually able to pin down a couple of > these types with a bit more certainty by deducing properties of the > type from what other parts of the standards said one could do with it.) Are there documents from this group? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 10:46:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1851537B401; Thu, 7 Jun 2001 10:46:27 -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 NAA25820; Thu, 7 Jun 2001 13:46:20 -0400 (EDT) (envelope-from wollman) Date: Thu, 7 Jun 2001 13:46:20 -0400 (EDT) From: Garrett Wollman Message-Id: <200106071746.NAA25820@khavrinen.lcs.mit.edu> To: obrien@FreeBSD.org Cc: arch@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong In-Reply-To: <20010607100339.A92620@dragon.nuxi.com> References: <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> <200106041547.LAA76688@khavrinen.lcs.mit.edu> <20010606184753.C45892@dragon.nuxi.com> <200106071544.LAA24831@khavrinen.lcs.mit.edu> <20010607100339.A92620@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG < said: > On Thu, Jun 07, 2001 at 11:44:08AM -0400, Garrett Wollman wrote: >> (In the Austin Group we were actually able to pin down a couple of >> these types with a bit more certainty by deducing properties of the >> type from what other parts of the standards said one could do with it.) > Are there documents from this group? Yes: it will be called ANSI/IEEE 1003.1-200x, ISO/IEC 9945:200x, and so on. The drafts are available only to those who register; the bug reports and meeting minutes are available at . -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 14: 3:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id 33CEB37B401; Thu, 7 Jun 2001 14:03:08 -0700 (PDT) (envelope-from pwd@apple.com) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA27219; Thu, 7 Jun 2001 14:03:07 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 7 Jun 2001 14:03:07 -0700 Received: from thunder (thunder.apple.com [17.202.40.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id f57L37l26327; Thu, 7 Jun 2001 14:03:07 -0700 (PDT) Message-Id: <200106072103.f57L37l26327@scv2.apple.com> Date: Thu, 7 Jun 2001 14:03:06 -0700 Content-Type: text/plain; format=flowed; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v388) From: "Patrick W. Penzias Dirks" To: FreeBSD-FS@freebsd.org, FreeBSD-Arch@freebsd.org X-Mailer: Apple Mail (2.388) Content-Transfer-Encoding: 7bit Subject: Support for pivot_root-like system call? Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I'm the filesystems tech lead in Apple's Mac OS X Core OS group. Prompted by the needs of, among others, virus protection software developers who want to be able to mount "on" the root directory to intercept ALL filesystem calls in the system, I'm contemplating implementation of a new system call in Mac OS X to do something like Linux's pivot_root system call: int pivot_root(const char *new_root, const char *put_old); (which basically installs "new_root" as the new "/" [root_vnode] in the system and transfers the current root directory to the pathname specified my "put_old") I'm not up on the latest discussions in the Linux world around this functionality (which I gather is pretty recent) and the Linux man page for pivot_root is deliberately vague about defining details of its semantics. There's no explicit guarantee that existing process's root vnode or current directory will or will not get switched, for instance. I thought some options might be appropriate to specify that kind of detail and I'm currently thinking of implementing a new switch_root(2): int switch_root(const char *new_root, const char *put_old, unsigned long flags); with the same basic functionality as pivot_root, and options to either insist on updating root and/or current directory for existing processes, possibly excluding system processes, for instance. I want to avoid implementing something that might for some reason clash horribly with either present FreeBSD designs or planned future developments. Any comments would be most welcome. Thanks in advance, -Pat Dirks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 16:51: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B90CE37B405 for ; Thu, 7 Jun 2001 16:50:58 -0700 (PDT) (envelope-from scottl@FreeBSD.org) Received: (from scottl@localhost) by freefall.freebsd.org (8.11.3/8.11.3) id f57Now356133 for arch@freebsd.org; Thu, 7 Jun 2001 16:50:58 -0700 (PDT) (envelope-from scottl) Date: Thu, 7 Jun 2001 16:50:58 -0700 (PDT) From: Message-Id: <200106072350.f57Now356133@freefall.freebsd.org> To: arch@freebsd.org Subject: RAIDframe for FreeBSD Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG http://people.freebsd.org/~scottl/rf This is based on the NetBSD port of RAIDframe. It's mostly done except for things like auto-config and root-mounting. Note that it is only for -stable right now. Barring any vm/ffs/etc events I'll have it ported to -current shortly. Have fun! Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 20: 8:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 8F1D637B406 for ; Thu, 7 Jun 2001 20:08:38 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id DC9373E0B; Thu, 7 Jun 2001 20:08:37 -0700 (PDT) To: Poul-Henning Kamp Cc: Jim Pirzyk , freebsd-arch@FreeBSD.ORG Subject: Re: sysctl interger type max In-Reply-To: <65709.991720741@critter>; from phk@critter.freebsd.dk on "Tue, 05 Jun 2001 07:59:01 +0200" Date: Thu, 07 Jun 2001 20:08:37 -0700 From: Dima Dorfman Message-Id: <20010608030837.DC9373E0B@bazooka.unixfreak.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp writes: > In message <01060412491406.00744@snoopy>, Jim Pirzyk writes: > >On Monday 04 June 2001 12:43 pm, Poul-Henning Kamp wrote: > >> In message <01060412361804.00744@snoopy>, Jim Pirzyk writes: > >> >On Monday 04 June 2001 12:26 pm, Poul-Henning Kamp wrote: > >> >> In message <01060412242703.00744@snoopy>, Jim Pirzyk writes: > >> >> >In sysctl(8), you can set an integer type, but the max value > >> >> >an int can be is 2 * N-1 where N is the size of int. This leads > >> >> >to a problem when trying to set kern.hostid and the number is > >> >> >greater that 2GB on an IA32 system. So my question is should The kern.hostid sysctl is defined as a signed integer, and the variable itself is a signed long, so I don't think you're supposed to be able to set it to greater than 2GB. Perhaps this is a bug. > >> >> >CTLTYPE_INT be treated as a long or some other larger numeric > >> >> >number? Or should we declare some CLTYPE_UINT type? > >> >> > >> >> We do have an SYSCTL_UINT these days. > >> > > >> >Yes for establishing the oid in the kernel, but sysctl command > >> >line is limited to 2 * 31 bits even if the variable is set to > >> >CLTYPE_{UINT|LONG|ULONG}. This means you cannot set the variables > >> >to a possible range of values. > >> > >> Then sysctl(8) is obviously broken... > > > >Yes, so how should it be fixed? Add another CTLTYPE_* or make > >CTLTYPE_INT handle say up to 'long long'? > > CTLTYPE_UINT should be fixed in sysctl(8) to handle [0..2^32-1] CTLTYPE_UINT doesn't exist. SYSCTL_(U)(INT|LONG) set the format argument to indicate the type. Currently, sysctl(8) ignores this format and treats everything that's a CTLTYPE_INT as being a signed integer, which is obviously wrong. Attached is a patch which makes it look up the format to determine how to deal with it. This seems a little too simple to me, but it seems to work. Did I miss anything? Thanks, Dima Dorfman dima@unixfreak.org Index: sysctl.c =================================================================== RCS file: /stl/src/FreeBSD/src/sbin/sysctl/sysctl.c,v retrieving revision 1.35 diff -u -r1.35 sysctl.c --- sysctl.c 2001/06/01 02:58:09 1.35 +++ sysctl.c 2001/06/08 03:00:25 @@ -143,10 +143,14 @@ { int len, i, j; void *newval = 0; - int intval, newsize = 0; + int newsize = 0; + int intval; + unsigned int uintval; + long longval; + unsigned long ulongval; quad_t quadval; int mib[CTL_MAXNAME]; - char *cp, *bufp, buf[BUFSIZ]; + char *cp, *bufp, buf[BUFSIZ], ofmt[BUFSIZ]; u_int kind; bufp = buf; @@ -164,7 +168,7 @@ if (len < 0) errx(1, "unknown oid '%s'", bufp); - if (oidfmt(mib, len, 0, &kind)) + if (oidfmt(mib, len, ofmt, &kind)) err(1, "couldn't find format of oid '%s'", bufp); if (newval == NULL) { @@ -184,10 +188,24 @@ switch (kind & CTLTYPE) { case CTLTYPE_INT: - intval = (int) strtol(newval, NULL, 0); - newval = &intval; - newsize = sizeof intval; - break; + if (strcmp(ofmt, "I") == 0) { + intval = (int)strtol(newval, NULL, 0); + newval = &intval; + newsize = sizeof(intval); + } else if (strcmp(ofmt, "IU") == 0) { + uintval = (unsigned int)strtoul(newval, + NULL, 0); + newval = &uintval; + newsize = sizeof(uintval); + } else if (strcmp(ofmt, "L") == 0) { + longval = strtol(newval, NULL, 0); + newval = &longval; + newsize = sizeof(longval); + } else if (strcmp(ofmt, "LU") == 0) { + ulongval = strtoul(newval, NULL, 0); + newval = &ulongval; + newsize = sizeof(ulongval); + } break; case CTLTYPE_STRING: break; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 22:56:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 87D2337B403 for ; Thu, 7 Jun 2001 22:56:17 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 92211 invoked by uid 1000); 8 Jun 2001 05:56:16 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 05:56:16 -0000 Date: Fri, 8 Jun 2001 00:56:16 -0500 (CDT) From: Mike Silbersack To: , Subject: New TCP sequence number generation algorithm; review needed Message-ID: <20010608005234.W92206-200000@achilles.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-228414066-991979776=:92206" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-228414066-991979776=:92206 Content-Type: TEXT/PLAIN; charset=US-ASCII The included patch implements what I believe to be a superior tcp sequence number generation algorithm. I'd appreciate comments on all aspects of the patch. If no objections are raised, I'd like to commit the patch to -current in a week or so, with -stable following two weeks after. I'm providing a quick FAQ to get people up to speed on what the patch does and its alternatives. But, as always, you'll obtain the best understanding of the code by reading it directly. Please do so before commenting. Q: How does this new patch generate sequence numbers? A: In short, the patch provides a seperate sequence number space for each host. These sequence spaces have no relation to the sequence spaces of other hosts, and are re-randomized whenever a host becomes idle. Q: How is this done? A: We are able to store a 16-bit variable which corresponds to the upper 16 bits of a host's sequence number in the cloned route entry for that host, thanks to extra space which exists in the routing metric structure. When we need a new sequence number for a host, we load in that value. If it is zero, as it is when the route is first cloned, we initialize it to a random value. Then, on this connection and every one after, we shift it left by 16 bits and increment it by a random value of up to 2^20. Subsequently, we store the upper 16 bits of the resulting value back in the cloned route entry, waiting for the next sequence number. Checks are present to make sure that the sequence number always increments by more than 2^16-1 and that the sequence number does not go to zero and cause a re-randomization. If a host is idle for a long period of time, the cloned route entry will be flushed and we will start the process over. Q: Doesn't looking up this extra data during every connection attempt take more time? A: No. The routing metric structure is accessed whenever a connection is established already. We are adding no additional searches, and the generation function is less time consuming than the one currently used. Q: How does all of this affect connections in the TIME_WAIT state? A: These changes positively affect the operation of sockets in the TIME_WAIT state. We are always monotonically incrementing the ISN within the context of a given host, which is what is required for proper operation. The re-randomization caused by a cloned route being flushed out and recreated is inconsequential; in the time it takes an entry to timeout and be flushed, any TIME_WAIT sockets would have expired. Q: How does all of this affect someone trying to spoof a connection? A: These changes make it very difficult to spoof connections. Since the ISN returned to the attacker has no relation to the ISN of the host he's trying to impersonate, he has no idea where to start. Even if he knew the starting point of the high 16-bits, he would be unable to guess the current state of the high 16-bits after a few random incrementations of the value. With this system in place, spoofing a connection should become a purely brute-force operation, requiring billions of attempts. Q: You're using arc4random() to get all random values. Is it random enough for this purpose? A: Mark Murray says that it is. So, yes. Q: What sequence number generation scheme is FreeBSD currently using? A: FreeBSD 4.3+ uses a tcp sequence number generation algorithm borrowed from OpenBSD. Roughly, this scheme uses a nonrepeating random number generator to provide the upper 16 bits for each ISN, while the lower 15 bits of data is drawn directly from the entropy pool. (The 16th bit is always 0.) Unless the nonrepeating random number generator is broken, spoofing this algorithm would be nearly as tough as spoofing against the new algorithm in this patch. The problem with the OpenBSD algorithm is that because the upper 16 bits of the sequence number are effectively random, monotonicity is broken. Hence, sockets in the TIME_WAIT state will act funky. Q: Ok, what's this RFC1948 sequence number generation scheme I keep hearing about? A: RFC1948 suggests segementing each hostA/portA/hostB/portB pair into a seperate sequence number space using a hash function of the form: ISN = timecounter + MD5(localhost, localport, remotehost, remoteport, shared secret) While clever, this algorithm has a major weakness. The shared secret is used in generating the ISN for all connections to the host in question. To ensure monotonicity for each connection, this implies that the shared secret must remain constant for the entire uptime of a machine. As a result, attackers may make a few connection attempts, store the IPs/ports used and the sequence number returned. This information can then be fed into a cracking program which will determine the shared secret. Once the shared secret is found, the attacker can perfectly spoof a connection to the machine from any host until the machine is rebooted and the shared secret changed. While not currently a threat, such an attack will most likely become possible if RFC1948 becomes widely used and attackers are sufficiently motivated. If you do not believe that this is possible, please read up on the history of RSA's DES challenges. Q: Do you really hate the RFC1948 algorithm that much? A: Yes. It's less secure than just random positive increments, IMHO. Q: Do you really think anyone read this far into the FAQ? A: I hope so. Q: Do you have anything more to add before I go off and read your code? A: Nope. Enjoy! Mike "Silby" Silbersack --0-228414066-991979776=:92206 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="silby_isn_generation.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20010608005616.L92206@achilles.silby.com> Content-Description: Content-Disposition: attachment; filename="silby_isn_generation.patch" ZGlmZiAtdSAtciBuZXRpbmV0Lm9sZC90Y3BfaW5wdXQuYyBuZXRpbmV0L3Rj cF9pbnB1dC5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX2lucHV0LmMJVGh1IEp1 biAgNyAxNjowMjowMSAyMDAxDQorKysgbmV0aW5ldC90Y3BfaW5wdXQuYwlU aHUgSnVuICA3IDE2OjAyOjEzIDIwMDENCkBAIC0xMDkyLDcgKzEwOTIsNyBA QA0KIAkJaWYgKGlzcykNCiAJCQl0cC0+aXNzID0gaXNzOw0KIAkJZWxzZSB7 DQotCQkJdHAtPmlzcyA9IHRjcF9ybmRpc3NfbmV4dCgpOw0KKwkJCXRwLT5p c3MgPSB0Y3BfbmV4dF9pc24odGFvcCk7DQogIAkJfQ0KIAkJdHAtPmlycyA9 IHRoLT50aF9zZXE7DQogCQl0Y3Bfc2VuZHNlcWluaXQodHApOw0KQEAgLTE2 MjQsNyArMTYyNCw3IEBADQogCQkJaWYgKHRoZmxhZ3MgJiBUSF9TWU4gJiYN CiAJCQkgICAgdHAtPnRfc3RhdGUgPT0gVENQU19USU1FX1dBSVQgJiYNCiAJ CQkgICAgU0VRX0dUKHRoLT50aF9zZXEsIHRwLT5yY3Zfbnh0KSkgew0KLQkJ CQlpc3MgPSB0Y3Bfcm5kaXNzX25leHQoKTsNCisJCQkJaXNzID0gdGNwX25l eHRfaXNuKHRhb3ApOw0KIAkJCQl0cCA9IHRjcF9jbG9zZSh0cCk7DQogCQkJ CWdvdG8gZmluZHBjYjsNCiAJCQl9DQpPbmx5IGluIG5ldGluZXQvOiB0Y3Bf aW5wdXQuYy5vcmlnDQpkaWZmIC11IC1yIG5ldGluZXQub2xkL3RjcF9zdWJy LmMgbmV0aW5ldC90Y3Bfc3Vici5jDQotLS0gbmV0aW5ldC5vbGQvdGNwX3N1 YnIuYwlUaHUgSnVuICA3IDE2OjAyOjAxIDIwMDENCisrKyBuZXRpbmV0L3Rj cF9zdWJyLmMJVGh1IEp1biAgNyAxNzozOTo1MyAyMDAxDQpAQCAtMTA5Niw2 MyArMTA5Niw2IEBADQogfQ0KICNlbmRpZiAvKiBJTkVUNiAqLw0KIA0KLSNk ZWZpbmUgVENQX1JORElTU19ST1VORFMJMTYNCi0jZGVmaW5lIFRDUF9STkRJ U1NfT1VUCTcyMDANCi0jZGVmaW5lIFRDUF9STkRJU1NfTUFYCTMwMDAwDQot DQotdV9pbnQ4X3QgdGNwX3JuZGlzc19zYm94WzEyOF07DQotdV9pbnQxNl90 IHRjcF9ybmRpc3NfbXNiOw0KLXVfaW50MTZfdCB0Y3Bfcm5kaXNzX2NudDsN Ci1sb25nIHRjcF9ybmRpc3NfcmVzZWVkOw0KLQ0KLXVfaW50MTZfdA0KLXRj cF9ybmRpc3NfZW5jcnlwdCh2YWwpDQotCXVfaW50MTZfdCB2YWw7DQotew0K LQl1X2ludDE2X3Qgc3VtID0gMCwgaTsNCi0gIA0KLQlmb3IgKGkgPSAwOyBp IDwgVENQX1JORElTU19ST1VORFM7IGkrKykgew0KLQkJc3VtICs9IDB4Nzli OTsNCi0JCXZhbCBePSAoKHVfaW50MTZfdCl0Y3Bfcm5kaXNzX3Nib3hbKHZh bF5zdW0pICYgMHg3Zl0pIDw8IDc7DQotCQl2YWwgPSAoKHZhbCAmIDB4ZmYp IDw8IDcpIHwgKHZhbCA+PiA4KTsNCi0JfQ0KLQ0KLQlyZXR1cm4gdmFsOw0K LX0NCi0NCi12b2lkDQotdGNwX3JuZGlzc19pbml0KCkNCi17DQotCXN0cnVj dCB0aW1ldmFsIHRpbWU7DQotDQotCWdldG1pY3JvdGltZSgmdGltZSk7DQot CXJlYWRfcmFuZG9tKHRjcF9ybmRpc3Nfc2JveCwgc2l6ZW9mKHRjcF9ybmRp c3Nfc2JveCkpOw0KLQ0KLQl0Y3Bfcm5kaXNzX3Jlc2VlZCA9IHRpbWUudHZf c2VjICsgVENQX1JORElTU19PVVQ7DQotCXRjcF9ybmRpc3NfbXNiID0gdGNw X3JuZGlzc19tc2IgPT0gMHg4MDAwID8gMCA6IDB4ODAwMDsgDQotCXRjcF9y bmRpc3NfY250ID0gMDsNCi19DQotDQotdGNwX3NlcQ0KLXRjcF9ybmRpc3Nf bmV4dCgpDQotew0KLQl1X2ludDE2X3QgdG1wOw0KLQlzdHJ1Y3QgdGltZXZh bCB0aW1lOw0KLQ0KLQlnZXRtaWNyb3RpbWUoJnRpbWUpOw0KLQ0KLSAgICAg ICAgaWYgKHRjcF9ybmRpc3NfY250ID49IFRDUF9STkRJU1NfTUFYIHx8DQot CSAgICB0aW1lLnR2X3NlYyA+IHRjcF9ybmRpc3NfcmVzZWVkKQ0KLSAgICAg ICAgICAgICAgICB0Y3Bfcm5kaXNzX2luaXQoKTsNCi0JDQotCXJlYWRfcmFu ZG9tKCZ0bXAsIHNpemVvZih0bXApKTsNCi0NCi0JLyogKHRtcCAmIDB4N2Zm ZikgZW5zdXJlcyBhIDMyNzY4IGJ5dGUgZ2FwIGJldHdlZW4gSVNTICovDQot CXJldHVybiAoKHRjcF9ybmRpc3NfZW5jcnlwdCh0Y3Bfcm5kaXNzX2NudCsr KSB8IHRjcF9ybmRpc3NfbXNiKSA8PDE2KSB8DQotCQkodG1wICYgMHg3ZmZm KTsNCi19DQotDQotDQogLyoNCiAgKiBXaGVuIGEgc291cmNlIHF1ZW5jaCBp cyByZWNlaXZlZCwgY2xvc2UgY29uZ2VzdGlvbiB3aW5kb3cNCiAgKiB0byBv bmUgc2VnbWVudC4gIFdlIHdpbGwgZ3JhZHVhbGx5IG9wZW4gaXQgYWdhaW4g YXMgd2UgcHJvY2VlZC4NCkBAIC0xNDIxLDQgKzEzNjQsNDIgQEANCiBzdGF0 aWMgdm9pZA0KIHRjcF9jbGVhcnRhb2NhY2hlKCkNCiB7DQorfQ0KKw0KK3Rj cF9zZXEgdGNwX25leHRfaXNuKHRhb3ApDQorCXN0cnVjdCBybXhwX3RhbyAq dGFvcDsNCit7DQorCXRjcF9zZXEgaXNuOw0KKw0KKwkvKg0KKwkgKiBJZiB0 YW9faXNuIGVxdWFscyB6ZXJvLCBhcyBpdCBkb2VzIHdoZW4gYSByb3V0ZSBp cyBjcmVhdGVkLA0KKwkgKiB3ZSBtdXN0IGluaXRpYWxpemUgaXQgdG8gYSBy YW5kb20gdmFsdWUuICANCisJICovDQorCWlmICh0YW9wLT50YW9faXNuID09 IDApIHsNCisJCXRhb3AtPnRhb19pc24gPSAodV9zaG9ydCkgYXJjNHJhbmRv bSgpOw0KKwl9DQorDQorCS8qDQorCSAqIEluY3JlbWVudCBieSB1cCB0byAy XjIwLiAgQWx0aG91Z2ggd2UgaGF2ZSBubyB0aW1lIGRlcGVuZGVuY2UsDQor CSAqIHRoaXMgc2hvdWxkIGJlIGEgbGFyZ2UgZW5vdWdoIGp1bXAgdG8gaW5z dXJlIHRoYXQgdGhlcmUgYXJlDQorCSAqIG5vIFRJTUVfV0FJVCBwcm9ibGVt cy4NCisJICovDQorCWlzbiA9ICh0YW9wLT50YW9faXNuIDw8IDE2KSArIChh cmM0cmFuZG9tKCkgJiAweGZmZmZmKTsNCisNCisJLyoNCisJICogU2luY2Ug d2Ugb25seSBzdG9yZSB0aGUgdXBwZXIgMTYgYml0cywgd2UgbXVzdCBhbHdh eXMNCisJICogYWRkIG9uZSB0byBlbnN1cmUgdGhhdCBhIHJhbmRvbSBwb3Np dGl2ZSBpbmNyZW1lbnQNCisJICogbGVzcyB0aGFuIDJeMTYgZG9lcyBub3Qg Y2F1c2UgYSBzZXF1ZW5jZSBudW1iZXINCisJICogcmVncmVzc2lvbi4NCisJ ICovDQorCXRhb3AtPnRhb19pc24gPSAoaXNuID4+IDE2KSArIDE7DQorDQor CS8qDQorCSAqIFdlIG11c3QgY2hlY2sgdG8gbWFrZSBzdXJlIHRoYXQgdGFv X2lzbiBkb2VzIG5vdCBlcXVhbCB6ZXJvOw0KKwkgKiBpZiBpdCBkb2VzLCBh IGZhbHNlIHJlaW5pdGlhbGl6YXRpb24gb2YgaXRzIHZhbHVlIHdvdWxkIG9j Y3VyLg0KKwkgKi8NCisJaWYgKHRhb3AtPnRhb19pc24gPT0gMCkgDQorCQl0 YW9wLT50YW9faXNuID0gMTsNCisNCisJcmV0dXJuIGlzbjsNCiB9DQpPbmx5 IGluIG5ldGluZXQvOiB0Y3Bfc3Vici5jLm9yaWcNCmRpZmYgLXUgLXIgbmV0 aW5ldC5vbGQvdGNwX3VzcnJlcS5jIG5ldGluZXQvdGNwX3VzcnJlcS5jDQot LS0gbmV0aW5ldC5vbGQvdGNwX3VzcnJlcS5jCVRodSBKdW4gIDcgMTY6MDI6 MDEgMjAwMQ0KKysrIG5ldGluZXQvdGNwX3VzcnJlcS5jCVRodSBKdW4gIDcg MTY6MDI6MTMgMjAwMQ0KQEAgLTc2MSw4ICs3NjEsNiBAQA0KIAl0Y3BzdGF0 LnRjcHNfY29ubmF0dGVtcHQrKzsNCiAJdHAtPnRfc3RhdGUgPSBUQ1BTX1NZ Tl9TRU5UOw0KIAljYWxsb3V0X3Jlc2V0KHRwLT50dF9rZWVwLCB0Y3Bfa2Vl cGluaXQsIHRjcF90aW1lcl9rZWVwLCB0cCk7DQotCXRwLT5pc3MgPSB0Y3Bf cm5kaXNzX25leHQoKTsNCi0JdGNwX3NlbmRzZXFpbml0KHRwKTsNCiANCiAJ LyoNCiAJICogR2VuZXJhdGUgYSBDQyB2YWx1ZSBmb3IgdGhpcyBjb25uZWN0 aW9uIGFuZA0KQEAgLTc4Miw2ICs3ODAsOSBAQA0KIAkJdHAtPnRfZmxhZ3Mg fD0gVEZfU0VORENDTkVXOw0KIAl9DQogDQorCXRwLT5pc3MgPSB0Y3BfbmV4 dF9pc24odGFvcCk7DQorCXRjcF9zZW5kc2VxaW5pdCh0cCk7DQorDQogCXJl dHVybiAwOw0KIH0NCiANCkBAIC04NTMsOCArODU0LDYgQEANCiAJdGNwc3Rh dC50Y3BzX2Nvbm5hdHRlbXB0Kys7DQogCXRwLT50X3N0YXRlID0gVENQU19T WU5fU0VOVDsNCiAJY2FsbG91dF9yZXNldCh0cC0+dHRfa2VlcCwgdGNwX2tl ZXBpbml0LCB0Y3BfdGltZXJfa2VlcCwgdHApOw0KLQl0cC0+aXNzID0gdGNw X3JuZGlzc19uZXh0KCk7DQotCXRjcF9zZW5kc2VxaW5pdCh0cCk7DQogDQog CS8qDQogCSAqIEdlbmVyYXRlIGEgQ0MgdmFsdWUgZm9yIHRoaXMgY29ubmVj dGlvbiBhbmQNCkBAIC04NzMsNiArODcyLDkgQEANCiAJCXRhb3AtPnRhb19j Y3NlbnQgPSAwOw0KIAkJdHAtPnRfZmxhZ3MgfD0gVEZfU0VORENDTkVXOw0K IAl9DQorDQorCXRwLT5pc3MgPSB0Y3BfbmV4dF9pc24odGFvcCk7DQorCXRj cF9zZW5kc2VxaW5pdCh0cCk7DQogDQogCXJldHVybiAwOw0KIH0NCk9ubHkg aW4gbmV0aW5ldC86IHRjcF91c3JyZXEuYy5vcmlnDQpkaWZmIC11IC1yIG5l dGluZXQub2xkL3RjcF92YXIuaCBuZXRpbmV0L3RjcF92YXIuaA0KLS0tIG5l dGluZXQub2xkL3RjcF92YXIuaAlUaHUgSnVuICA3IDE2OjAyOjAxIDIwMDEN CisrKyBuZXRpbmV0L3RjcF92YXIuaAlUaHUgSnVuICA3IDE3OjQwOjE1IDIw MDENCkBAIC0xODksNiArMTg5LDcgQEANCiAJdGNwX2NjCXRhb19jYzsJCQkv KiBsYXRlc3QgQ0MgaW4gdmFsaWQgU1lOICovDQogCXRjcF9jYwl0YW9fY2Nz ZW50OwkJLyogbGF0ZXN0IENDIHNlbnQgdG8gcGVlciAqLw0KIAl1X3Nob3J0 CXRhb19tc3NvcHQ7CQkvKiBwZWVyJ3MgY2FjaGVkIE1TUyAqLw0KKwl1X3No b3J0IHRhb19pc247CQkvKiBpbml0aWFsIHNlZ21lbnQgbnVtYmVyIHRvIHNl bmQgdG8gcGVlciAqLw0KICNpZmRlZiBub3R5ZXQNCiAJdV9zaG9ydAl0YW9f ZmxhZ3M7CQkvKiBjYWNoZSBzdGF0dXMgZmxhZ3MgKi8NCiAjZGVmaW5lCVRB T0ZfRE9OVAkweDAwMDEJCS8qIHBlZXIgZG9lc24ndCB1bmRlcnN0YW5kIHJm YzE2NDQgKi8NCkBAIC00MDksMTAgKzQxMCw3IEBADQogZXh0ZXJuCXN0cnVj dCBwcl91c3JyZXFzIHRjcF91c3JyZXFzOw0KIGV4dGVybgl1X2xvbmcgdGNw X3NlbmRzcGFjZTsNCiBleHRlcm4JdV9sb25nIHRjcF9yZWN2c3BhY2U7DQot dm9pZAl0Y3Bfcm5kaXNzX2luaXQgX19QKCh2b2lkKSk7DQotdGNwX3NlcQl0 Y3Bfcm5kaXNzX25leHQgX19QKCh2b2lkKSk7DQotdV9pbnQxNl90DQotCXRj cF9ybmRpc3NfZW5jcnlwdCBfX1AoKHVfaW50MTZfdCkpOw0KK3RjcF9zZXEJ dGNwX25leHRfaXNuIF9fUCgoc3RydWN0IHJteHBfdGFvICopKTsNCiANCiAj ZW5kaWYgLyogX0tFUk5FTCAqLw0KIA0KT25seSBpbiBuZXRpbmV0LzogdGNw X3Zhci5oLm9yaWcNCg== --0-228414066-991979776=:92206-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jun 7 23:29:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 9FA5B37B408 for ; Thu, 7 Jun 2001 23:29:40 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 92272 invoked by uid 1000); 8 Jun 2001 06:29:39 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 06:29:39 -0000 Date: Fri, 8 Jun 2001 01:29:39 -0500 (CDT) From: Mike Silbersack To: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> Message-ID: <20010608012844.T92270-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Those who were unable to use the attached patch for whatever reason may also access it at: http://www.silby.com/patches/silby_isn_generation.patch Thanks, Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 0:33:30 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 01CFB37B401 for ; Fri, 8 Jun 2001 00:33:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA00895; Fri, 8 Jun 2001 00:33:16 -0700 (PDT) Message-ID: <3B207ACB.70A84C54@mindspring.com> Date: Fri, 08 Jun 2001 00:12:11 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Erik Trulsson , arch@FreeBSD.ORG Subject: Re: time_t definition is worng References: <44559.991550408@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > Instead lets set a deadline: The longest commonly used time interval > is 30 years for mortgages, so lets be safe and say that on january > 1st 2005 00:00 UTC we will transition time_t to be at least 33 > bits. Until then it is 32 bits. > > In practice this will probably be 64 bits on most arch's but let > us use the 33 bit goal rather than mandate 64bits which might be > prohibitively expensive on some architecturs. > > Any objections ? Yeah; Are you going to write the FS conversion tool? Ask Kirk why there were 32 bit reserved fields immediately adjacent to the existing 32 bit time fields, before someone decided that all times (and not just the modification time, used by "make") needed to have nanoseconds, and that was more important than having the transition in 2038 go without a hitch. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 0:41:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id ACE5337B401; Fri, 8 Jun 2001 00:41:15 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA13884; Fri, 8 Jun 2001 00:41:12 -0700 (PDT) Message-ID: <3B2081B5.579A9888@mindspring.com> Date: Fri, 08 Jun 2001 00:41:41 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson Cc: "Jacques A. Vidrine" , Sheldon Hearn , Mark Murray , arch@FreeBSD.ORG Subject: Re: PAM, S/Key and authentication schemes. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Robert Watson wrote: [ ... PAM API ... ] > PAM is recognizably not perfect, but as Terry points out, > creating the "perfect modular authentication, authorization, > accounting, and credential-management API" is not a trivial > task. In general, I'd strongly oppose efforts to simply > hack up a replacement unless they were seriously thought > through, and experimented with over an extended period of > time in extremely diverse environments. My main fear was that they were going to go to PAM, and since PAM is completely inadequate for anything Kerberos, break Kerberous and similar systems completely and irrevokably. The point is that you can't just "go to PAM for everything" and "simplify the world". If they wanted to hack up a superset of PAM that could embrace both PAM and Kerberos, I wouldn't object, but it looks like Sun is ducking that issue for now, themselves, and that it's probably a pretty hard target. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 0:56:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0B68237B403 for ; Fri, 8 Jun 2001 00:56:17 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f587u4104348; Fri, 8 Jun 2001 09:56:04 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: tlambert2@mindspring.com Cc: Erik Trulsson , arch@FreeBSD.ORG Subject: Re: time_t definition is worng In-Reply-To: Your message of "Fri, 08 Jun 2001 00:12:11 PDT." <3B207ACB.70A84C54@mindspring.com> Date: Fri, 08 Jun 2001 09:56:04 +0200 Message-ID: <4346.991986964@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3B207ACB.70A84C54@mindspring.com>, Terry Lambert writes: >Poul-Henning Kamp wrote: >> Instead lets set a deadline: The longest commonly used time interval >> is 30 years for mortgages, so lets be safe and say that on january >> 1st 2005 00:00 UTC we will transition time_t to be at least 33 >> bits. Until then it is 32 bits. >> >> In practice this will probably be 64 bits on most arch's but let >> us use the 33 bit goal rather than mandate 64bits which might be >> prohibitively expensive on some architecturs. >> >> Any objections ? > >Yeah; > >Are you going to write the FS conversion tool? > >Ask Kirk why there were 32 bit reserved fields immediately >adjacent to the existing 32 bit time fields, before someone >decided that all times (and not just the modification time, >used by "make") needed to have nanoseconds, and that was >more important than having the transition in 2038 go without >a hitch. Actually a 64 bit timeformat could be constructed like this: 1 bit sign 33 bit seconds 30 bits fraction of seconds This would give us a range of +/- 272 years and a resolution of .93 nanoseconds. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 0:58:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 6F93537B401 for ; Fri, 8 Jun 2001 00:58:32 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAB23260; Fri, 8 Jun 2001 17:58:12 +1000 Date: Fri, 8 Jun 2001 17:56:19 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Dima Dorfman Cc: Poul-Henning Kamp , Jim Pirzyk , freebsd-arch@FreeBSD.ORG Subject: Re: sysctl interger type max In-Reply-To: <20010608030837.DC9373E0B@bazooka.unixfreak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Jun 2001, Dima Dorfman wrote: > Poul-Henning Kamp writes: > > In message <01060412491406.00744@snoopy>, Jim Pirzyk writes: > > >Yes, so how should it be fixed? Add another CTLTYPE_* or make > > >CTLTYPE_INT handle say up to 'long long'? > > > > CTLTYPE_UINT should be fixed in sysctl(8) to handle [0..2^32-1] > > CTLTYPE_UINT doesn't exist. SYSCTL_(U)(INT|LONG) set the format > argument to indicate the type. Currently, sysctl(8) ignores this > format and treats everything that's a CTLTYPE_INT as being a signed > integer, which is obviously wrong. Attached is a patch which makes it > look up the format to determine how to deal with it. This seems a > little too simple to me, but it seems to work. Did I miss anything? I think you only missed fixing the (nonexistent) error handling and range checking for the results of strto*() :-). I think it would be better to have CTLTYPE_UINT, etc., and not have oid_fmt. The format string isn't any more general than a fixed set of CTLTYPE's, at least in the current implementation, since sysctl(8) needs to decode the format string to turn it into a fixed set of cases. Keeping part of the type info in oid_fmt mainly wastes space. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 0:58:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 0EDCD37B406; Fri, 8 Jun 2001 00:58:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA23850; Fri, 8 Jun 2001 00:58:31 -0700 (PDT) Message-ID: <3B2085C3.F54A9C9A@mindspring.com> Date: Fri, 08 Jun 2001 00:58:59 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: obrien@FreeBSD.ORG, arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> <200106041547.LAA76688@khavrinen.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman wrote: > > < said: > > > time_t needs to be consistent across all FreeBSD platforms. > > No, it doesn't. Binary FS compatability. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 2:10:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id A4ADB37B401; Fri, 8 Jun 2001 02:10:40 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id CAA29987; Fri, 8 Jun 2001 02:10:38 -0700 (PDT) Message-ID: <3B2096AB.309B2D14@mindspring.com> Date: Fri, 08 Jun 2001 02:11:07 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Patrick W. Penzias Dirks" Cc: FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <200106072103.f57L37l26327@scv2.apple.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Patrick W. Penzias Dirks" wrote: > > Hi, > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > Prompted by the needs of, among others, virus protection software > developers who want to be able to mount "on" the root directory to > intercept ALL filesystem calls in the system, I'm contemplating > implementation of a new system call in Mac OS X to do something like > Linux's pivot_root system call: > > int pivot_root(const char *new_root, const char *put_old); > > (which basically installs "new_root" as the new "/" [root_vnode] in > the system and transfers the current root directory to the pathname > specified my "put_old") It doesn't work in FreeBSD proper because of cache coherency bugs that have been around since 1995, but: mount -t nullfs / /put_old # or wherever mount -t / Would do what you want, I think. Really, the BSD way of doing this is to stack an FS with the feature you want on top of the one without the feature in it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 2:51:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by hub.freebsd.org (Postfix) with ESMTP id 83E0B37B401; Fri, 8 Jun 2001 02:51:21 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.138.245.Dial1.SanJose1.Level3.net [209.245.138.245]) by mclean.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id FAA18005; Fri, 8 Jun 2001 05:51:14 -0400 (EDT) Message-ID: <3B20A02E.B1507A80@mindspring.com> Date: Fri, 08 Jun 2001 02:51:42 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed References: <20010608005234.W92206-200000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Silbersack wrote: > Q: How does this new patch generate sequence numbers? > > A: In short, the patch provides a seperate sequence number > space for each host. These sequence spaces have no > relation to the sequence spaces of other hosts, and > are re-randomized whenever a host becomes idle. > > Q: How is this done? > > A: We are able to store a 16-bit variable which corresponds > to the upper 16 bits of a host's sequence number in the > cloned route entry for that host, thanks to extra space > which exists in the routing metric structure. OK, I read the code. Not to poop the party, but off the top of my head, I have several major objections: 1) You stole the space reserved for the cache status flags; calling it 'tao_flags' would have been more honest. 2) This doesn't work right for cloned routes. 3) This blows up if you delete and re-add the default route, and the route in question is a clone of the default. 4) Your claim of "extra space" comes because you are allocating these things with a cruddy allocator; some of us aren't wasting the same space in our kernel that the rest of you are, and don't intend for that practice to continue for the rest of you very much longer. 5) This blows up for keepalive packet sends, which use preallocated tcptemplate structures, which get a copy of the first header in when setting up a connection; check the keepalive sequence numbers using your new scheme... 6) This adds per-connection state, which is evil when you want a lot of connections: the way to get a lot of connections is to remove as much per-connection state as possible, which in turn reduces your per-connection resource costs, and that in turn increases the number of connections you are capable of sustaining with a constant set of resources. 7) The "monotonicity in TIME_WAIT" problem you mention is not really a problem. It is the 2*MSL value of 30 seconds and a tcp_timer that controls that; the sequence number is irrelevent (if you can prove your claim of "funky" in a bit more detail than simply calling it that, I would be willing to withdraw this objection; but I think the other six stand on ther own, still). I'm sure anyone with an "IP failover" or "IP takeover" product could probably come up with several other major objections; I don't know if anyone has implemented NECP sevices on FreeBSD, or "Direct Server Return" switch hacking of packets with Apache on FreeBSD cooperation, but I would be surprised if people who have would not also have objections. Is there any way you could do this using the ip/port pair as the means of preterbation instead? That might not be as aggregious, though I suspect it would still cause problems in two of the cases... even if it did get rid of the per-connection state information. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 5:11:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id CB03137B405 for ; Fri, 8 Jun 2001 05:11:15 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA62994; Fri, 8 Jun 2001 14:11:19 +0200 (CEST) (envelope-from assar) From: assar@stacken.kth.se To: freebsd-arch@FreeBSD.org Subject: Re: kern/17613: impossible to build FS KLD without kernel source References: <5512.991994609@critter> Date: 08 Jun 2001 14:11:17 +0200 In-Reply-To: Poul-Henning Kamp's message of "Fri, 08 Jun 2001 12:03:29 +0200" Message-ID: <5l3d9buq6y.fsf@assaris.sics.se> Lines: 59 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ Poul-Henning said I should bring this to arch ] This is a continuation of my PR kern/17613 where I noted that it's not possible to build a FS KLD with having kernel source (needed to generate vnode_if.h). My proposed way of solving this is by having include/Makefile generate this file so that it can be installed, along the lines of the patch below. Comments? /assar Index: Makefile =================================================================== RCS file: /home/ncvs/src/include/Makefile,v retrieving revision 1.125 diff -u -w -u -w -r1.125 Makefile --- Makefile 2000/10/16 07:00:18 1.125 +++ Makefile 2001/06/08 09:23:40 @@ -6,7 +6,7 @@ # The ``rm -rf''s used below are safe because rm doesn't follow symbolic # links. -CLEANFILES= osreldate.h version vers.c +CLEANFILES= osreldate.h version vers.c vnode_if.h SUBDIR= rpcsvc FILES= a.out.h ar.h assert.h bitstring.h ctype.h db.h dirent.h disktab.h \ dlfcn.h elf.h err.h fnmatch.h fstab.h \ @@ -59,7 +59,7 @@ #SHARED= symlinks SHARED?= copies -all: osreldate.h +all: osreldate.h vnode_if.h osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh \ ${.CURDIR}/../sys/sys/param.h @@ -70,6 +70,11 @@ echo \#'undef __FreeBSD_version' >> osreldate.h; \ echo \#'define __FreeBSD_version' $$RELDATE >> osreldate.h +vnode_if.h: ${.CURDIR}/../sys/kern/vnode_if.pl \ + ${.CURDIR}/../sys/kern/vnode_if.src + @${ECHO} creating vnode_if.h + perl ${.CURDIR}/../sys/kern/vnode_if.pl -h ${.CURDIR}/../sys/kern/vnode_if.src + beforeinstall: ${SHARED} @rm -f ${DESTDIR}/usr/include/timepps.h cd ${.CURDIR}; \ @@ -87,6 +92,9 @@ ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ ${.OBJDIR}/osreldate.h \ ${DESTDIR}/usr/include + ${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m 444 \ + ${.OBJDIR}/vnode_if.h \ + ${DESTDIR}/usr/include/sys .for i in ${LFILES} ln -sf sys/$i ${DESTDIR}/usr/include/$i .endfor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 5:27: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (assaris.sics.se [193.10.66.234]) by hub.freebsd.org (Postfix) with ESMTP id 5A88237B406; Fri, 8 Jun 2001 05:26:56 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id OAA63023; Fri, 8 Jun 2001 14:26:53 +0200 (CEST) (envelope-from assar) To: "Patrick W. Penzias Dirks" Cc: FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <200106072103.f57L37l26327@scv2.apple.com> From: Assar Westerlund Date: 08 Jun 2001 14:26:53 +0200 In-Reply-To: "Patrick W. Penzias Dirks"'s message of "Thu, 7 Jun 2001 14:03:06 -0700" Message-ID: <5lelsvtawi.fsf@assaris.sics.se> Lines: 16 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Patrick W. Penzias Dirks" writes: > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > Prompted by the needs of, among others, virus protection software > developers who want to be able to mount "on" the root directory to > intercept ALL filesystem calls in the system, I'm contemplating > implementation of a new system call in Mac OS X to do something like > Linux's pivot_root system call: > > int pivot_root(const char *new_root, const char *put_old); Could you explain to me/us how you would implement virus protection software (or something similiar), based on pivot_root? Is there any such stuff for linux that uses pivot_root? /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 6: 9:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 4D53D37B407; Fri, 8 Jun 2001 06:09:27 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 158M1s-000Jde-0W; Fri, 8 Jun 2001 14:10:20 +0100 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f58D8A724309; Fri, 8 Jun 2001 14:08:10 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 8 Jun 2001 14:08:10 +0100 (BST) From: Doug Rabson To: Assar Westerlund Cc: "Patrick W. Penzias Dirks" , , Subject: Re: Support for pivot_root-like system call? In-Reply-To: <5lelsvtawi.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 8 Jun 2001, Assar Westerlund wrote: > "Patrick W. Penzias Dirks" writes: > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > > Prompted by the needs of, among others, virus protection software > > developers who want to be able to mount "on" the root directory to > > intercept ALL filesystem calls in the system, I'm contemplating > > implementation of a new system call in Mac OS X to do something like > > Linux's pivot_root system call: > > > > int pivot_root(const char *new_root, const char *put_old); > > Could you explain to me/us how you would implement virus protection > software (or something similiar), based on pivot_root? > > Is there any such stuff for linux that uses pivot_root? Musing about virus protection (not particularly about pivot_root), I guess the best way to intercept all attempts to manipulate files on a given fs would be to make the virus checker a stackable VFS layer. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 7:37:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id EFBD837B405 for ; Fri, 8 Jun 2001 07:37:16 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 93348 invoked by uid 1000); 8 Jun 2001 14:37:15 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 14:37:15 -0000 Date: Fri, 8 Jun 2001 09:37:15 -0500 (CDT) From: Mike Silbersack To: Terry Lambert Cc: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <3B20A02E.B1507A80@mindspring.com> Message-ID: <20010608080013.F93237-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Jun 2001, Terry Lambert wrote: > OK, I read the code. Not to poop the party, but off the top > of my head, I have several major objections: > > 1) You stole the space reserved for the cache status > flags; calling it 'tao_flags' would have been more > honest. rmx_filler still has extra space in it, there's no problem fitting in tao_flags when and if it becomes used. > 2) This doesn't work right for cloned routes. On the contrary, it only works for cloned routes. > 3) This blows up if you delete and re-add the default > route, and the route in question is a clone of the > default. Yes, this will cause the cloned route to get blown away, and the ISN reset. This is only a minor issue, and can be ignored unless a host sees frequent route changes. Even if the cloned route is blown away frequently, this will simply cause the algorithm to revert to totally random ISNs, which isn't the end of the world. Can anyone who's familiar with FreeBSD boxes which serve as routers confirm how route changes affect their cloned routes? > 4) Your claim of "extra space" comes because you > are allocating these things with a cruddy > allocator; some of us aren't wasting the same > space in our kernel that the rest of you are, > and don't intend for that practice to continue > for the rest of you very much longer. I fail to see how basing a patch for FreeBSD on FreeBSD is a strike against it. If you have a new route table, please post information about it so that we can all see how it wll affect this patch and others. > 5) This blows up for keepalive packet sends, which > use preallocated tcptemplate structures, which > get a copy of the first header in when setting > up a connection; check the keepalive sequence > numbers using your new scheme... Why would changing ISN generation affect keepalive packets? I haven't changed how connection setup works whatsoever. > 6) This adds per-connection state, which is evil > when you want a lot of connections: the way to > get a lot of connections is to remove as much > per-connection state as possible, which in turn > reduces your per-connection resource costs, and > that in turn increases the number of connections > you are capable of sustaining with a constant > set of resources. This patch doesn't add per-connection state. The additional 16 bits added to the route structure were already present as unused space. > 7) The "monotonicity in TIME_WAIT" problem you mention > is not really a problem. It is the 2*MSL value of > 30 seconds and a tcp_timer that controls that; the > sequence number is irrelevent (if you can prove > your claim of "funky" in a bit more detail than > simply calling it that, I would be willing to > withdraw this objection; but I think the other six > stand on ther own, still). Go read RFC 793, or this chunk of code from tcp_input.c: /* * If a new connection request is received * while in TIME_WAIT, drop the old connection * and start over if the sequence numbers * are above the previous ones. */ if (thflags & TH_SYN && tp->t_state == TCPS_TIME_WAIT && SEQ_GT(th->th_seq, tp->rcv_nxt)) { iss = tcp_next_isn(taop); tp = tcp_close(tp); goto findpcb; } I didn't create this behavior; it's been part of *BSD for a very long time. We must respect it, as we cannot change it now. > I'm sure anyone with an "IP failover" or "IP takeover" > product could probably come up with several other major > objections; I don't know if anyone has implemented NECP > sevices on FreeBSD, or "Direct Server Return" switch > hacking of packets with Apache on FreeBSD cooperation, > but I would be surprised if people who have would not > also have objections. Any package that depended on predictable sequence numbers would've broken twice in the last 9 months already. If there were any complaints at those times, they didn't appear on the lists, and didn't lead to the ISN generation being changed then. If you're in one of the above classes of people, I'd like to hear from you to better understand the issue; the NECP RFC draft didn't appear to have any information on this topic, as far as I could tell. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 7:46: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 06DB537B405 for ; Fri, 8 Jun 2001 07:45:58 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 93366 invoked by uid 1000); 8 Jun 2001 14:45:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Jun 2001 14:45:57 -0000 Date: Fri, 8 Jun 2001 09:45:57 -0500 (CDT) From: Mike Silbersack To: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> Message-ID: <20010608094440.Q93237-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG For those interested, I've put up a patch which will show you the ISNs used for outgoing connections with the new generation method at: http://www.silby.com/patches/silby_isn_generation_debug.patch Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 8:30:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 4EE7F37B40C; Fri, 8 Jun 2001 08:30:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f58FUBM58954; Fri, 8 Jun 2001 08:30:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D7AF1380C; Fri, 8 Jun 2001 08:30:11 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? In-Reply-To: <3B2096AB.309B2D14@mindspring.com> Date: Fri, 08 Jun 2001 08:30:11 -0700 From: Peter Wemm Message-Id: <20010608153011.D7AF1380C@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > "Patrick W. Penzias Dirks" wrote: > > > > Hi, > > > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > > Prompted by the needs of, among others, virus protection software > > developers who want to be able to mount "on" the root directory to > > intercept ALL filesystem calls in the system, I'm contemplating > > implementation of a new system call in Mac OS X to do something like > > Linux's pivot_root system call: > > > > int pivot_root(const char *new_root, const char *put_old); > > > > (which basically installs "new_root" as the new "/" [root_vnode] in > > the system and transfers the current root directory to the pathname > > specified my "put_old") > > It doesn't work in FreeBSD proper because of cache coherency > bugs that have been around since 1995, but: > > mount -t nullfs / /put_old # or wherever > mount -t / > > Would do what you want, I think. Terry, the 'cache coherency' bugs have been fixed in -current for ~8 months now (September 2000). The infrastructure changes for this are subject to a call-for-review right now for a merge to 4.x. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 9:44: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 2C3E637B403; Fri, 8 Jun 2001 09:44:02 -0700 (PDT) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 158PMf-00040I-00; Fri, 8 Jun 2001 09:44:01 -0700 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id JAA10571; Fri, 8 Jun 2001 09:43:56 -0700 (PDT) From: patl@Phoenix.Volant.ORG Date: Fri, 8 Jun 2001 09:43:56 -0700 (PDT) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] To: Peter Wemm Cc: FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG In-Reply-To: <20010608153011.D7AF1380C@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > months now (September 2000). The infrastructure changes for this are > subject to a call-for-review right now for a merge to 4.x. This is -VERY- good news. I just have two questions: 1. Which currently broken filesystems in STABLE become usable with these fixes? 2. Do you have any wild-assed guess as to how long the approval and MFC are likely to take? (I.e., When might it be available in -STABLE) (I chose the word 'guess' carefully - I know better than to rely on any such prediction. Nevertheless, a ballpark estimate would help me decide whether to consider delaying a project I'm starting until those fixes are in.) Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 10: 1:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 2B29537B401; Fri, 8 Jun 2001 10:01:51 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f58H1Ui14469; Fri, 8 Jun 2001 13:01:30 -0400 (EDT) Date: Fri, 8 Jun 2001 13:01:28 -0400 From: Alfred Perlstein To: Peter Wemm Cc: tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? Message-ID: <20010608130128.E1832@superconductor.rush.net> References: <3B2096AB.309B2D14@mindspring.com> <20010608153011.D7AF1380C@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010608153011.D7AF1380C@overcee.netplex.com.au>; from peter@wemm.org on Fri, Jun 08, 2001 at 08:30:11AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Peter Wemm [010608 11:30] wrote: > Terry Lambert wrote: > > "Patrick W. Penzias Dirks" wrote: > > > > > > Hi, > > > > > > I'm the filesystems tech lead in Apple's Mac OS X Core OS group. > > > Prompted by the needs of, among others, virus protection software > > > developers who want to be able to mount "on" the root directory to > > > intercept ALL filesystem calls in the system, I'm contemplating > > > implementation of a new system call in Mac OS X to do something like > > > Linux's pivot_root system call: > > > > > > int pivot_root(const char *new_root, const char *put_old); > > > > > > (which basically installs "new_root" as the new "/" [root_vnode] in > > > the system and transfers the current root directory to the pathname > > > specified my "put_old") > > > > It doesn't work in FreeBSD proper because of cache coherency > > bugs that have been around since 1995, but: > > > > mount -t nullfs / /put_old # or wherever > > mount -t / > > > > Would do what you want, I think. > > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > months now (September 2000). The infrastructure changes for this are > subject to a call-for-review right now for a merge to 4.x. The cache coherency bugs are not fixed for all cases, being able to ask the underlying filesystem for the vm_object does not solve the problem. What if i have a stacking layer where each page alternates between two files that i'm stacked on top of? Passing the vm_object back doesn't work for this. Unless something else has been done. -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 14:27:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id B65BB37B405; Fri, 8 Jun 2001 14:27:33 -0700 (PDT) (envelope-from pwd@apple.com) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA05909; Fri, 8 Jun 2001 14:27:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 8 Jun 2001 14:25:46 +0100 Received: from thunder (thunder.apple.com [17.202.40.76]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id OAA23988; Fri, 8 Jun 2001 14:27:05 -0700 (PDT) Message-Id: <200106082127.OAA23988@scv1.apple.com> Date: Fri, 8 Jun 2001 14:27:04 -0700 From: Pat Dirks Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: Support for pivot_root-like system call? Cc: FreeBSD-Arch@freebsd.org, FreeBSD-FS@freebsd.org To: tlambert2@mindspring.com X-Mailer: Apple Mail (2.388) In-Reply-To: <3B2096AB.309B2D14@mindspring.com> Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, June 8, 2001, at 02:11 AM, Terry Lambert wrote: >> Prompted by the needs of, among others, virus protection software >> developers who want to be able to mount "on" the root directory to >> intercept ALL filesystem calls in the system, I'm contemplating >> implementation of a new system call in Mac OS X to do something like >> Linux's pivot_root system call: >> >> int pivot_root(const char *new_root, const char *put_old); >> >> (which basically installs "new_root" as the new "/" [root_vnode] in >> the system and transfers the current root directory to the pathname >> specified my "put_old") > > It doesn't work in FreeBSD proper because of cache coherency > bugs that have been around since 1995, but: > > mount -t nullfs / /put_old # or wherever > mount -t / > > Would do what you want, I think. True, that is the exact effect, except that it leaves the old root accessible only through a nullfs layer, which is unnecessarily ineffcient. > Really, the BSD way of doing this is to stack an FS with the > feature you want on top of the one without the feature in it. Oh, I know. The reason the developers are interested in this is for exactly that reason - in order to supplant "/" with a mount of their own so that they can layer their virus protection checks on the ordinary filesystem. They'd like to be able to implement a layered fileystem that'll cover the entire filesystem tree and which checks on various operations to make sure no viruses are being handled. Their antivirusfs_open code would, for instance, scan the underlying file before returning to the caller, forcing an error if a virus was detected. There are, I suppose, two aspects of pivot_root that are appealing: it provides a clean way to supplant all references to the existing 'rootvnode', not just in the kernel globals but in all running processes, and, in addition, it allows an atomic reorganization of the mount structure that can't be done with exactly the same effect in two separate operations because the old root will be inaccessible after the mounting of the new root. I see I missed a crucial bit in the checkdirs() code that's invoked after a mount where 'rootvnode' is automatically updated if something's mounted on "/". Considering that the main initial use for this call would actually be for the first reason above (merely supplanting "/"), not the second reason (moving where the current "/" appears) I think it'll be sufficient to adopt a bit more of the FreeBSD mount code to call checkdirs() after mount to update the existing processes in the system along with 'rootvnode'. If we find a call for pivot_root's more exotic restructuring functionality, we'll revisit the issue of implementing a new system call. Thanks for everyone's coments! -Pat Dirks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 17:56:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 563D537B405; Fri, 8 Jun 2001 17:56:11 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id RAA15083; Fri, 8 Jun 2001 17:56:09 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id RAA80976; Fri, 8 Jun 2001 17:56:08 -0700 (PDT) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id RAA16800; Fri, 8 Jun 2001 17:56:08 -0700 (PDT) From: Don Lewis Message-Id: <200106090056.RAA16800@salsa.gv.tsc.tdk.com> Date: Fri, 8 Jun 2001 17:56:07 -0700 In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> References: <20010608005234.W92206-200000@achilles.silby.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Mike Silbersack , , Subject: Re: New TCP sequence number generation algorithm; review needed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Jun 8, 12:56am, Mike Silbersack wrote: } Subject: New TCP sequence number generation algorithm; review needed [ snip ] } Q: How does this new patch generate sequence numbers? } } A: In short, the patch provides a seperate sequence number space for each } host. These sequence spaces have no relation to the sequence spaces of } other hosts, and are re-randomized whenever a host becomes idle. } } Q: How is this done? } } A: We are able to store a 16-bit variable which corresponds to the upper } 16 bits of a host's sequence number in the cloned route entry for that } host, thanks to extra space which exists in the routing metric structure. } When we need a new sequence number for a host, we load in that value. If } it is zero, as it is when the route is first cloned, we initialize it to a } random value. Then, on this connection and every one after, we shift it } left by 16 bits and increment it by a random value of up to 2^20. } Subsequently, we store the upper 16 bits of the resulting value back in } the cloned route entry, waiting for the next sequence number. Checks are } present to make sure that the sequence number always increments by more } than 2^16-1 and that the sequence number does not go to zero and cause a } re-randomization. If a host is idle for a long period of time, the cloned } route entry will be flushed and we will start the process over. [ snip ] } Q: Ok, what's this RFC1948 sequence number generation scheme I keep } hearing about? } } A: RFC1948 suggests segementing each hostA/portA/hostB/portB pair into a } seperate sequence number space using a hash function of the form: } } ISN = timecounter + MD5(localhost, localport, remotehost, remoteport, shared secret) } } While clever, this algorithm has a major weakness. The shared secret is } used in generating the ISN for all connections to the host in question. } To ensure monotonicity for each connection, this implies that the shared } secret must remain constant for the entire uptime of a machine. As a } result, attackers may make a few connection attempts, store the IPs/ports } used and the sequence number returned. This information can then be fed } into a cracking program which will determine the shared secret. Once the } shared secret is found, the attacker can perfectly spoof a connection to } the machine from any host until the machine is rebooted and the shared } secret changed. [ snip ] Why not combine the two schemes and feed the random per-host data from the cloned route entry into the RFC1948 algorithm? This doesn't solve Terry's objection, though. Another way of strengthening the RFC1948 would be to use some of the bits of MD5(remostehost, another secret) to extract the shared secret from a larger table. This increases the difficulty of discovering the shared secret needed to spoof the host in question, but it doesn't solve the problem of needing to keep the same shared secrets for the uptime of the machine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 19: 2:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (fumerola-laptop.corp.yahoo.com [216.145.60.111]) by hub.freebsd.org (Postfix) with ESMTP id AB5F537B401; Fri, 8 Jun 2001 19:02:41 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f592Cjb02166; Fri, 8 Jun 2001 19:12:45 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200106090212.f592Cjb02166@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Pat Dirks Cc: FreeBSD-Arch@freebsd.org, FreeBSD-FS@freebsd.org Subject: Re: Support for pivot_root-like system call? In-reply-to: Your message of "Fri, 08 Jun 2001 14:27:04 PDT." <200106082127.OAA23988@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2001 19:12:45 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Just a couple of observations about this approach: - If you only replace the / mount, you only protect /. If an application traverses off / onto another filesystem during a lookup, the eventuating vnode is going to get the vfsops pointer for the filesystem handling the FS the lookup terminates on, circumventing the protection. A better approach will probably be to implement a 'mount template', where an FS can register a hook which allows it to decide whether if wants to be automagically layered over another FS being mounted, something like an automatic version of Terry's union mount. - There's an ugly tradeoff between kernel footprint and performance here. You want the checker in kernel space to avoid context switching and piping all your I/O to/from userspace, but if you're doing dictionary searches, that's stuff that is going to be sitting permanently mapped. 8( Hope this helps; thanks for raising the issue, it's an interesting one. 8) Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 19:30:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id B071537B405; Fri, 8 Jun 2001 19:30:13 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 6720029020; Sat, 9 Jun 2001 09:29:55 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 5A91B28FF6; Sat, 9 Jun 2001 09:29:55 +0700 (ALMST) Date: Sat, 9 Jun 2001 09:29:55 +0700 (ALMST) From: Boris Popov To: Alfred Perlstein Cc: Peter Wemm , tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? In-Reply-To: <20010608130128.E1832@superconductor.rush.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Jun 2001, Alfred Perlstein wrote: > The cache coherency bugs are not fixed for all cases, being able to > ask the underlying filesystem for the vm_object does not solve the > problem. > > What if i have a stacking layer where each page alternates > between two files that i'm stacked on top of? This is a case of "fan-out" stacking and such filesystems are much more complex than fan-in ones. VOP_*VOBJECT() were specifically designed for fan-in type of stacking. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jun 8 19:56:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id EA0CC37B403 for ; Fri, 8 Jun 2001 19:56:23 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 94617 invoked by uid 1000); 9 Jun 2001 02:56:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jun 2001 02:56:22 -0000 Date: Fri, 8 Jun 2001 21:56:22 -0500 (CDT) From: Mike Silbersack To: Don Lewis Cc: , Subject: Re: New TCP sequence number generation algorithm; review needed In-Reply-To: <200106090056.RAA16800@salsa.gv.tsc.tdk.com> Message-ID: <20010608214621.V94603-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 8 Jun 2001, Don Lewis wrote: > Why not combine the two schemes and feed the random per-host data from > the cloned route entry into the RFC1948 algorithm? This doesn't solve > Terry's objection, though. That thought had occured to me, but I'm not sure it would actually add any security. I've been requested to pose the algorithm to people from outside the FreeBSD project and what they think about its strength. When I hear back from them, I'll post more details. Terry needs to clarify his objections. #3 is the only one which is definitely valid. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 3:22:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 8606237B401; Sat, 9 Jun 2001 03:22:42 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f59AMRn87725; Sat, 9 Jun 2001 13:22:27 +0300 (EEST) (envelope-from ru) Date: Sat, 9 Jun 2001 13:22:27 +0300 From: Ruslan Ermilov To: Terry Lambert Cc: Mike Silbersack , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <20010609132227.B87114@sunbay.com> Mail-Followup-To: Terry Lambert , Mike Silbersack , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <20010608005234.W92206-200000@achilles.silby.com> <3B20A02E.B1507A80@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B20A02E.B1507A80@mindspring.com>; from tlambert2@mindspring.com on Fri, Jun 08, 2001 at 02:51:42AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jun 08, 2001 at 02:51:42AM -0700, Terry Lambert wrote: [...] > > 6) This adds per-connection state, which is evil > when you want a lot of connections: the way to > get a lot of connections is to remove as much > per-connection state as possible, which in turn > reduces your per-connection resource costs, and > that in turn increases the number of connections > you are capable of sustaining with a constant > set of resources. > Umm, this adds a per-destination, not per-connection state. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 3:29:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 89A7B37B401; Sat, 9 Jun 2001 03:29:22 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f59AT6d88153; Sat, 9 Jun 2001 13:29:06 +0300 (EEST) (envelope-from ru) Date: Sat, 9 Jun 2001 13:29:06 +0300 From: Ruslan Ermilov To: Mike Silbersack Cc: Terry Lambert , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <20010609132906.C87114@sunbay.com> Mail-Followup-To: Mike Silbersack , Terry Lambert , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <3B20A02E.B1507A80@mindspring.com> <20010608080013.F93237-100000@achilles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010608080013.F93237-100000@achilles.silby.com>; from silby@silby.com on Fri, Jun 08, 2001 at 09:37:15AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jun 08, 2001 at 09:37:15AM -0500, Mike Silbersack wrote: > > On Fri, 8 Jun 2001, Terry Lambert wrote: > > > OK, I read the code. Not to poop the party, but off the top > > of my head, I have several major objections: > > > > 1) You stole the space reserved for the cache status > > flags; calling it 'tao_flags' would have been more > > honest. > > rmx_filler still has extra space in it, there's no problem fitting in > tao_flags when and if it becomes used. > > > 2) This doesn't work right for cloned routes. > > On the contrary, it only works for cloned routes. > > > 3) This blows up if you delete and re-add the default > > route, and the route in question is a clone of the > > default. > > Yes, this will cause the cloned route to get blown away, and the ISN > reset. This is only a minor issue, and can be ignored unless a host sees > frequent route changes. Even if the cloned route is blown away > frequently, this will simply cause the algorithm to revert to totally > random ISNs, which isn't the end of the world. > This still could be handled. When the parent (or even this particular) route is deleted, it is only deleted from the routing table and is marked as "down". TCP's PCB still holds on it. On the next socket write, ip_output() sees that the route is no longer "up", and reallocates the new route. tcp_output() could check that the cached route is still up before passing it to ip_output(), and reallocate the route preserving the old value of ISN (thus avoiding the re-randomization of the latter). Alternatively, ip_output() could probably do this. Just an untested idea. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 9:51:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B258537B401; Sat, 9 Jun 2001 09:51:50 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f59GpgF07875; Sat, 9 Jun 2001 09:51:42 -0700 (PDT) (envelope-from dillon) Date: Sat, 9 Jun 2001 09:51:42 -0700 (PDT) From: Matt Dillon Message-Id: <200106091651.f59GpgF07875@earth.backplane.com> To: Alfred Perlstein Cc: Peter Wemm , tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <3B2096AB.309B2D14@mindspring.com> <20010608153011.D7AF1380C@overcee.netplex.com.au> <20010608130128.E1832@superconductor.rush.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :The cache coherency bugs are not fixed for all cases, being able to :ask the underlying filesystem for the vm_object does not solve the :problem. : :What if i have a stacking layer where each page alternates :between two files that i'm stacked on top of? : :Passing the vm_object back doesn't work for this. Unless something :else has been done. : :-Alfred Perlstein [alfred@freebsd.org] Well, I suppose a vm_map would solve this, though for the specific alternating case (or a RAID configuration of some sort) it would be really expensive to do with a vm_map. We would need some kind of synthesized translation capability in the vm_map to make it efficient. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 10:14:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D037B401; Sat, 9 Jun 2001 10:14:29 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA10093; Sat, 9 Jun 2001 13:14:20 -0400 (EDT) Message-ID: <3B225989.6E2110@mindspring.com> Date: Sat, 09 Jun 2001 10:14:49 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: <20010608153011.D7AF1380C@overcee.netplex.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > months now (September 2000). The infrastructure changes for this are > subject to a call-for-review right now for a merge to 4.x. Peter, the 'cache coherency' bugs have only been fixed for the trivial case where the pages at the top are identical to the pages at the bottom of a vnode stack. In the case of a transforming stack, the "final VP" that should be returned is actually an intermediate VP, and you need to take a write fault in the putpages in order to do the correct layer boundary transition. As a simple case, consider an FS that at the top presents one page, but at the bottom presents two pages from which that one page is derived. This could be a cryptographic FS, or it could be an FS that converts from ISO-8859-1 to ISO-10646, etc.. The point is that the page contents will undergo a transformation. The problem is the same as the explicit cache coherency code that resolved the getpages/putpages in one layer by calling the read/write function in the underlying layer in the historical "nullfs" workaround, which was a kludge. When FreeBSD moved to a unified VM and buffer cache, it erroneously removed the "hint points" at which an explicit coherency call would occur to synchronize the VM and buffer cache views of an object. This is precisely the code that is needed to synchronize a vm_object_t with the backing vm_object_t after a transformation. What FreeBSD has now will work for about 1/4 of the proposed uses of stacking FS layers. It will _NOT_ work for most of the interesting uses of a stacking architecture, which involve MUX'es (e.g. "translucent FS" for "writing" to a CDROM) or for "proxy FS" for debugging your FS code in user space, etc. -- I have around 16 examples where the current code still fails. Really, you want to define the actual device I/O in terms of a "disk block FS". The thing that most people apparent fail to "get" is that there is a significant difference between a stacking layer and a local media FS. A local media FS has to interact with the VM system (or buffer cache, or whatever). We need to couch UFS in terms of talking to a local media FS on top of which it is stacked. Unfortunately, it seems that most people are unwilling to actually email John Heidemann, the architect of the stacking code in 4.4BSD (and therefore FreeBSD). Frankly, it really pisses me off that this stuff doesn't work in FreeBSD. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 10:34:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id A8E4037B403; Sat, 9 Jun 2001 10:34:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA21819; Sat, 9 Jun 2001 13:34:13 -0400 (EDT) Message-ID: <3B225E32.484672C@mindspring.com> Date: Sat, 09 Jun 2001 10:34:42 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: patl@Phoenix.Volant.ORG Cc: Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG patl@Phoenix.Volant.ORG wrote: > > On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > > Terry, the 'cache coherency' bugs have been fixed in > > -current for ~8 months now (September 2000). The > > infrastructure changes for this are subject to a > > call-for-review right now for a merge to 4.x. > > This is -VERY- good news. I just have two questions: > > 1. Which currently broken filesystems in STABLE become usable with > these fixes? The fix is _my_ design. It permits the code to get the backing object for a vm_object_t, instead of an alias. I first proposed this design in 1995, as _part_ of a total fix (in other words, it will not fix the entire problem space). In answer to your question, the FS's which become usable are the ones for which the final VP is the local media file system, and for which there are no transformations in the FS's layered on top of it. This will work for nullfs (obviously), unionfs (assuming that the using is on a per file basis, or, minimally, at a page granularity, for interleaved FS's, and similar FS's. It will also work for adjunct metadata FS's, where the memtadata is stored seperately, such as my "quotafs", which allows "UFS quotas" to be applied to any FS on which you stack them. It will _NOT_ work for cryptographic FS's, where the number of pages or the page boundaries change witing a file, compressing FS's, FS's with different block sizes (such as a DVDROM FS, which need to deal with 1024 byte sectors for an ISO 9660 FS, along with raw CD tracks), etc.. It will _NOT_ deal with paging issues from a 1024b block size FAT opr VFAT or VFAT32 FS, when aligned at a 512b boundary (the most common case, when such an FS occurs immediately after the MBR and partition table), and it will not work for more interesting FS's which do namespace folding or support things like ISO-8859-1 to ISO-10646 namespace translation on directories (an obvious use for stacking FS layers, to provide compatability). Similarly, binary compatability between, e.g. UFS on a little endian vs. a big endian FS, implemented in a stacking layer, will not work, for systems where the atomic types are inequal (c.v. the recent time_t discussion). In other words, the code will work in about 1/4 of the cases... which, however you look at it, is a hell of a lot better than 0 of the cases, and _does_ represent forward progress. It's just not the panacea that Peter makes it out to be. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 10:39:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id 90F4B37B401; Sat, 9 Jun 2001 10:39:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA31006; Sat, 9 Jun 2001 13:38:54 -0400 (EDT) Message-ID: <3B225F4C.CEE4E28C@mindspring.com> Date: Sat, 09 Jun 2001 10:39:24 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Boris Popov Cc: Alfred Perlstein , Peter Wemm , "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Boris Popov wrote: > > On Fri, 8 Jun 2001, Alfred Perlstein wrote: > > > The cache coherency bugs are not fixed for all cases, being able to > > ask the underlying filesystem for the vm_object does not solve the > > problem. > > > > What if i have a stacking layer where each page alternates > > between two files that i'm stacked on top of? > > This is a case of "fan-out" stacking and such filesystems are much > more complex than fan-in ones. VOP_*VOBJECT() were specifically designed > for fan-in type of stacking. Wrong. Read the FICUS papers. Support for a "translucent" FS was one of the intial goals, as was HSM. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 10:47:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id 9965937B401; Sat, 9 Jun 2001 10:47:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA17645; Sat, 9 Jun 2001 13:47:17 -0400 (EDT) Message-ID: <3B226142.59A48940@mindspring.com> Date: Sat, 09 Jun 2001 10:47:46 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Silbersack Cc: Don Lewis , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed References: <20010608214621.V94603-100000@achilles.silby.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Silbersack wrote: > > On Fri, 8 Jun 2001, Don Lewis wrote: > > > Why not combine the two schemes and feed the random > > per-host data from the cloned route entry into the > > RFC1948 algorithm? This doesn't solve Terry's objection, > > though. > > That thought had occured to me, but I'm not sure it would > actually add any security. It would not. Big Number Theory(tm) tells us that multiplying or adding one random number to another actually ends up with the result being _less random_. > Terry needs to clarify his objections. #3 is the only one > which is definitely valid. I disagree (of course), but will clarify later in response to your response; I really don't have time for the hour or so of deep thinking necessary to refute your objections (feel flattered, if you like, for "stumping" me... not really that hard, since you seem to be on the ball 8-)), since the points you raise involve some significant subtleties that are not really obvious without a lot of careful thought. I can't really do justice to the concepts necessary to express the fundamental objections right now, as I have other demands on my time which take precedence right now (I'm just going through my email very quickly). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 10:52:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id 31A7137B401; Sat, 9 Jun 2001 10:52:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.133.57.Dial1.SanJose1.Level3.net [209.245.133.57]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id NAA15183; Sat, 9 Jun 2001 13:52:05 -0400 (EDT) Message-ID: <3B226262.AF4858E2@mindspring.com> Date: Sat, 09 Jun 2001 10:52:34 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: Mike Silbersack , freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: New TCP sequence number generation algorithm; review needed References: <20010608005234.W92206-200000@achilles.silby.com> <3B20A02E.B1507A80@mindspring.com> <20010609132227.B87114@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > > On Fri, Jun 08, 2001 at 02:51:42AM -0700, Terry Lambert wrote: > [...] > > > > 6) This adds per-connection state, which is evil > > when you want a lot of connections: the way to > > get a lot of connections is to remove as much > > per-connection state as possible, which in turn > > reduces your per-connection resource costs, and > > that in turn increases the number of connections > > you are capable of sustaining with a constant > > set of resources. > > > Umm, this adds a per-destination, not per-connection state. For things like web servers, where the destination is a client PC with a single user, the net effect is per-connection state, since magnitude(connection) == magnitude(destination). The only escape is an edge proxy for multiple clients at a single site. I agree that this is a possibility, but I think the majority of web site traffic is single client, no pedge proxy. Note that even if there _is_ an edge proxy, that the proxy itself will satisfy the request: the origin server will never see it. As a result, we are back to ther being a direct correlation,. i.e.: magnitude(connection) == magnitude(destination), from the point of view of the server. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 11: 1:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id A9AF737B401; Sat, 9 Jun 2001 11:01:08 -0700 (PDT) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 158n2p-0006YQ-00; Sat, 9 Jun 2001 11:01:07 -0700 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id LAA10723; Sat, 9 Jun 2001 11:01:03 -0700 (PDT) From: patl@Phoenix.Volant.ORG Date: Sat, 9 Jun 2001 11:01:02 -0700 (PDT) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] To: tlambert2@mindspring.com Cc: Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG In-Reply-To: <3B225E32.484672C@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 9-Jun-01 at 10:34, Terry Lambert (tlambert2@mindspring.com) wrote: > patl@Phoenix.Volant.ORG wrote: > > > > On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > > > Terry, the 'cache coherency' bugs have been fixed in > > > -current for ~8 months now (September 2000). The > > > infrastructure changes for this are subject to a > > > call-for-review right now for a merge to 4.x. > > > > This is -VERY- good news. I just have two questions: > > > > 1. Which currently broken filesystems in STABLE become usable with > > these fixes? > > The fix is _my_ design. It permits the code to get the > backing object for a vm_object_t, instead of an alias. > > ... > > In answer to your question, the FS's which become usable > are the ones for which the final VP is the local media > file system, and for which there are no transformations > in the FS's layered on top of it. > > ... > > In other words, the code will work in about 1/4 of the > cases... which, however you look at it, is a hell of a > lot better than 0 of the cases, and _does_ represent > forward progress. It's just not the panacea that Peter > makes it out to be. Hmm. I would like to see a complete fix, some of the possibilities are quite interesting. BUT it sounds like this is enough to take care of my immediate need; which is for a way to setup jails with a read-only shared base filesystem (holding the system files and installed ports/packages), overlayed with a writeable per-jail tree with configuration and jail-specific data files. And to have the per-jail trees -really- be separate directories within a shared partition on the host system so that I don't have to worry about partition allocation issues. Aside from the obvious virtual hosting application, I see this setup as being quite useful for port maintainers as a tool for making it easier to determine exactly which files and directories are created or modified during an install. (Make a jail filesystem and install all the dependancies in it. Make the port. Overlay an empty directory over the jail fs. Make install. Examine the overlayed fs from outside the jail. Any files in it must have been edited or created by the install. Checking directories is slightly more work but still pretty easy.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 11:17:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id D9B3B37B401; Sat, 9 Jun 2001 11:17:25 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f59IHO108472; Sat, 9 Jun 2001 11:17:24 -0700 (PDT) (envelope-from dillon) Date: Sat, 9 Jun 2001 11:17:24 -0700 (PDT) From: Matt Dillon Message-Id: <200106091817.f59IHO108472@earth.backplane.com> To: Terry Lambert Cc: patl@Phoenix.Volant.ORG, Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] References: <3B225E32.484672C@mindspring.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :It will _NOT_ work for cryptographic FS's, where the number :of pages or the page boundaries change witing a file, :compressing FS's, FS's with different block sizes (such as :... :-- Terry Woa... sure it will! The VM Object is representing the clear text file, not the actual underlying crypted file. So it should work just fine. Also, in the filespace the physical sector size is irrelevant. Take the VN (now MD) device for example. If you use a file for backing store the sector size from the point of view of the MD device can be 512 bytes no matter what the actual sector size of the filesystem backing the file is. But if you use, say, swap for backing store the sector size from the point of view of the MD device is one page (4K on IA32), period end of story. Also, even in UFS the physical topology of a file varies... a file might be partially represented by a fragment (e.g. 1K) as well as a full file block (8K) in the physical topology. But the VM Object representing the file doesn't know and doesn't care. So VM Objects for files are 100% independant of the topology of the filesystem backing those files. This means that the fixed NULLFS should work just dandy for any filesystem. It may not be able to overload devices transparently, but it should definitely be able to overload a filesystem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 12:36:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 36A9C37B401; Sat, 9 Jun 2001 12:36:31 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f59JaVM65605; Sat, 9 Jun 2001 12:36:31 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E5EE9380C; Sat, 9 Jun 2001 12:36:30 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: tlambert2@mindspring.com Cc: "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? In-Reply-To: <3B225989.6E2110@mindspring.com> Date: Sat, 09 Jun 2001 12:36:30 -0700 From: Peter Wemm Message-Id: <20010609193630.E5EE9380C@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Peter Wemm wrote: > > Terry, the 'cache coherency' bugs have been fixed in -current for ~8 > > months now (September 2000). The infrastructure changes for this are > > subject to a call-for-review right now for a merge to 4.x. > > Peter, the 'cache coherency' bugs have only been fixed for > the trivial case where the pages at the top are identical > to the pages at the bottom of a vnode stack. Which is exactly what we're talking about - the trivial one-to-one mapping. See the example that you previously posted, but so thoughtfully removed: > > It doesn't work in FreeBSD proper because of cache coherency > > bugs that have been around since 1995, but: > > > > mount -t nullfs / /put_old # or wherever > > mount -t / > > > > Would do what you want, I think. There are no cache coherency bugs in this situation, which is all we were talking about to start with. You were the one that went off on a tangent on one-to-many mappings, but that is not related to the question at hand. (pivot_root(), remmeber...) Yes, you are absolutely correct about getpages/putpages etc being the real fix that enables all the good stuff, but that wasn't the issue at hand. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 14:19:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 3A76A37B401; Sat, 9 Jun 2001 14:19:13 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id RAA08333; Sat, 9 Jun 2001 17:19:12 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f59LIg207638; Sat, 9 Jun 2001 17:18:42 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15138.37554.563342.811191@grasshopper.cs.duke.edu> Date: Sat, 9 Jun 2001 17:18:42 -0400 (EDT) To: Cc: arch@freebsd.org Subject: Re: RAIDframe for FreeBSD In-Reply-To: <200106072350.f57Now356133@freefall.freebsd.org> References: <200106072350.f57Now356133@freefall.freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG scottl@FreeBSD.org writes: > > http://people.freebsd.org/~scottl/rf > > This is based on the NetBSD port of RAIDframe. It's mostly done except for > things like auto-config and root-mounting. Note that it is only for -stable > right now. Barring any vm/ffs/etc events I'll have it ported to -current > shortly. Have fun! > Awesome! Thanks! Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jun 9 15: 1:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id C7FC437B401; Sat, 9 Jun 2001 15:01:46 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f59M1ES03896; Sat, 9 Jun 2001 18:01:14 -0400 (EDT) Date: Sat, 9 Jun 2001 18:01:12 -0400 From: Alfred Perlstein To: Matt Dillon Cc: Peter Wemm , tlambert2@mindspring.com, "Patrick W. Penzias Dirks" , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG Subject: Re: Support for pivot_root-like system call? Message-ID: <20010609180111.M1832@superconductor.rush.net> References: <3B2096AB.309B2D14@mindspring.com> <20010608153011.D7AF1380C@overcee.netplex.com.au> <20010608130128.E1832@superconductor.rush.net> <200106091651.f59GpgF07875@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200106091651.f59GpgF07875@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 09, 2001 at 09:51:42AM -0700 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Matt Dillon [010609 12:51] wrote: > > :The cache coherency bugs are not fixed for all cases, being able to > :ask the underlying filesystem for the vm_object does not solve the > :problem. > : > :What if i have a stacking layer where each page alternates > :between two files that i'm stacked on top of? > : > :Passing the vm_object back doesn't work for this. Unless something > :else has been done. > : > :-Alfred Perlstein [alfred@freebsd.org] > > Well, I suppose a vm_map would solve this, though for the specific > alternating case (or a RAID configuration of some sort) it would be > really expensive to do with a vm_map. We would need some kind of > synthesized translation capability in the vm_map to make it efficient. I think the proper method would be to use GET/PUTPAGES, where a GETPAGES would require a subsequent PUT/UNLOCKPAGES. The problem is that a bunch of code digs into the backing data of the vm and vfs structures without bothering to query the vm/vfs and ask if it's ok (besideds respecting locks, and even that's not always true). -- -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message