From owner-freebsd-arch@FreeBSD.ORG Sun Feb 27 19:39:10 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4D5C16A4D2; Sun, 27 Feb 2005 19:39:10 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E6E43D6B; Sun, 27 Feb 2005 19:39:09 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j1RJd8Jr040565; Sun, 27 Feb 2005 20:39:08 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, current@freebsd.org From: Poul-Henning Kamp Date: Sun, 27 Feb 2005 20:39:08 +0100 Message-ID: <40564.1109533148@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [REVIEW/TEST] device liberation patches. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2005 19:39:11 -0000 This patch decouples entirely the userland and kernel concept of major+minor device number. Userland will see a copy of the devfs inode number and the kernel will see what it always saw. After this patch goes into -current in the middle of march, we can do away with the notion of major device numbers, and remove the 256 limit on number of device drivers and get rid of the stupid hole in the minor number field and finally stand a chance to get the locking of devices (struct cdev) hammered into a sensible format. If anything breaks when running with this patch, a device major/minor is passed through some covert channel between userland to the kernel where it shouldn't be. Such channels very likely implement security risks in relation to jails/chroot, so they should be fixed properly and not just worked around. Poul-Henning Index: fs/devfs/devfs_devs.c =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs_devs.c,v retrieving revision 1.33 diff -u -r1.33 devfs_devs.c --- fs/devfs/devfs_devs.c 10 Feb 2005 12:22:17 -0000 1.33 +++ fs/devfs/devfs_devs.c 27 Feb 2005 19:16:35 -0000 @@ -424,3 +424,32 @@ if (ino < devfs_nextino) devfs_nextino = ino; } + +/* + * Helper sysctl for devname(3). We're given a struct cdev * and return + * the name, if any, registered by the device driver. + */ +static int +sysctl_devname(SYSCTL_HANDLER_ARGS) +{ + int error; + dev_t ud; + struct cdev *dev, **dp; + + error = SYSCTL_IN(req, &ud, sizeof (ud)); + if (error) + return (error); + if (ud == NODEV) + return(EINVAL); + dp = devfs_itod(ud); + if (dp == NULL) + return(ENOENT); + dev = *dp; + if (dev == NULL) + return(ENOENT); + return(SYSCTL_OUT(req, dev->si_name, strlen(dev->si_name) + 1)); + return (error); +} + +SYSCTL_PROC(_kern, OID_AUTO, devname, CTLTYPE_OPAQUE|CTLFLAG_RW|CTLFLAG_ANYBODY, + NULL, 0, sysctl_devname, "", "devname(3) handler"); Index: fs/devfs/devfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/fs/devfs/devfs_vnops.c,v retrieving revision 1.105 diff -u -r1.105 devfs_vnops.c --- fs/devfs/devfs_vnops.c 22 Feb 2005 18:17:31 -0000 1.105 +++ fs/devfs/devfs_vnops.c 27 Feb 2005 19:16:35 -0000 @@ -441,7 +441,7 @@ vap->va_mtime = dev->si_mtime; fix(dev->si_ctime); vap->va_ctime = dev->si_ctime; - vap->va_rdev = dev->si_udev; + vap->va_rdev = de->de_inode; } vap->va_gen = 0; vap->va_flags = 0; Index: kern/kern_conf.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_conf.c,v retrieving revision 1.172 diff -u -r1.172 kern_conf.c --- kern/kern_conf.c 22 Feb 2005 15:51:07 -0000 1.172 +++ kern/kern_conf.c 27 Feb 2005 19:16:35 -0000 @@ -800,30 +800,3 @@ free(cd, M_DEVBUF); *cdp = NULL; } - -/* - * Helper sysctl for devname(3). We're given a struct cdev * and return - * the name, if any, registered by the device driver. - */ -static int -sysctl_devname(SYSCTL_HANDLER_ARGS) -{ - int error; - dev_t ud; - struct cdev *dev; - - error = SYSCTL_IN(req, &ud, sizeof (ud)); - if (error) - return (error); - if (ud == NODEV) - return(EINVAL); - dev = findcdev(ud); - if (dev == NULL) - error = ENOENT; - else - error = SYSCTL_OUT(req, dev->si_name, strlen(dev->si_name) + 1); - return (error); -} - -SYSCTL_PROC(_kern, OID_AUTO, devname, CTLTYPE_OPAQUE|CTLFLAG_RW|CTLFLAG_ANYBODY, - NULL, 0, sysctl_devname, "", "devname(3) handler"); -- 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. From owner-freebsd-arch@FreeBSD.ORG Mon Feb 28 02:17:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6203616A4CE for ; Mon, 28 Feb 2005 02:17:34 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id E206243D2F for ; Mon, 28 Feb 2005 02:17:33 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j1S2HWJf018852; Sun, 27 Feb 2005 21:17:32 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <421DAD8F.6000704@portaone.com> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> Date: Sun, 27 Feb 2005 21:17:31 -0500 To: Maxim Sobolev From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-arch@freebsd.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 02:17:34 -0000 At 12:33 PM +0200 2/24/05, Maxim Sobolev wrote: >Garance A Drosihn wrote: >> >>As I see it, we have the following choices to fix this: >> >>1) MFC the January 31st change to kern/imgact_shell.c to 5.3-stable, >> as it is. This means we haven't fixed the problem that people >> complained about in 2002 and again in 2004. And I still think >> it is "not appropriate" for the execve() system to be deciding >> what '#' means on that line. The biggest advantage is that this >> means 5.4-release will behave exactly the same as 3.5 through >> 5.3-release have behaved. We have the code-freeze coming up on Wednesday. It turns out the Jan 31st change had some bugs in it, and afaik we are still coming up with a better version of that for *current*, never mind -stable. At this point I think we should revert change 1.26.4.1 in -stable, such that 5.4-release will behave the same way as all previous releases. Which is to say, it will continue to look for '#' on the shebang line, and ignore everything after one is found. I have a patch ready to do this, assuming people aren't too upset at the idea. I just don't feel comfortable trying to rush through multiple changes for this issue at the last minute. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Mon Feb 28 16:26:24 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F20EE16A4CE for ; Mon, 28 Feb 2005 16:26:23 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id ED66143D39 for ; Mon, 28 Feb 2005 16:26:20 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 57449 invoked by uid 0); 28 Feb 2005 16:17:03 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 28 Feb 2005 16:17:03 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 1CF591321B9; Tue, 1 Mar 2005 00:26:00 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67934-04; Tue, 1 Mar 2005 00:25:48 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 1C369135C87; Tue, 1 Mar 2005 00:25:48 +0800 (CST) Date: Tue, 1 Mar 2005 00:25:48 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, freebsd-security@FreeBSD.org Message-ID: <20050228162548.GA57140@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #15: Wed Dec 15 10:43:16 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net Subject: bind() on 127.0.0.1 in jail: bound to the outside address? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 16:26:24 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear folks, It seems that doing bind() inside a jail (whose IP address is an outside address), will result in some wierd behavior, that the actual bind is done on the outside address. For example, binding to 127.0.0.1:6666 inside a jail addressed 192.168.1.1, will finally result in a bind to 192.168.1.1:6666. With this in mind, it is possible that some formerly secure configuration fail in jail environment. It seems that our implementation will forward every loopback connection to the outside address. A simple hack to work around this issue might be to modify the individual bind procedures to treat prison case with loopback address, but I'm not sure if a true solution can solve the issue with minimum code change and code complexity. Your ideas are highly appreciated! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCI0YM/cVsHxFZiIoRAnqIAJ9POX6OwQUb9k8jOQcNmdyEanmutwCeLQaA rxIUQwv4OU3t2ziOu5defsQ= =li2c -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 28 16:48:57 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCB4916A4CE for ; Mon, 28 Feb 2005 16:48:57 +0000 (GMT) Received: from diri.bris.ac.uk (diri.bris.ac.uk [137.222.10.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6107643D1F for ; Mon, 28 Feb 2005 16:48:57 +0000 (GMT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by diri.bris.ac.uk with esmtp (Exim 4.50) id 1D5o4l-0000CO-F9; Mon, 28 Feb 2005 16:48:56 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.44) id 1D5o4h-0002DJ-7I; Mon, 28 Feb 2005 16:48:51 +0000 Date: Mon, 28 Feb 2005 16:48:51 +0000 (GMT) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Xin LI In-Reply-To: <20050228162548.GA57140@frontfree.net> Message-ID: References: <20050228162548.GA57140@frontfree.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jan Grant X-Spam-Score: -2.8 X-Spam-Level: -- cc: freebsd-arch@FreeBSD.org Subject: Re: bind() on 127.0.0.1 in jail: bound to the outside address? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 16:48:58 -0000 On Tue, 1 Mar 2005, Xin LI wrote: > Your ideas are highly appreciated! It's not minimal, but assuming that it's desirable that processes listening on loopback sockets shouldn't collide outside the jail, one approach might be as follows: - get jails to the point where they can manage more than one IP address per jail; - a jail config will then include an alias on the loopback address (127.0.0.2, ...) unfortunately like all jail extensions this has other problems - for instance, the close association of a jail to "its IP address" is broken by this. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287864 or +44 (0)117 9287088 http://ioctl.org/jan/ From owner-freebsd-arch@FreeBSD.ORG Mon Feb 28 18:10:52 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41F3B16A4CE for ; Mon, 28 Feb 2005 18:10:52 +0000 (GMT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBCF43D55 for ; Mon, 28 Feb 2005 18:10:51 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from [213.51.128.134] (port=39527 helo=smtp3.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1D5pLy-0001ED-OK; Mon, 28 Feb 2005 19:10:46 +0100 Received: from cc740438-a.deven1.ov.home.nl ([82.72.18.239]:34416 helo=192.168.1.104) by smtp3.home.nl with esmtp (Exim 4.30) id 1D5pLv-0000XB-Qb; Mon, 28 Feb 2005 19:10:43 +0100 From: "Devon H. O'Dell" To: Jan Grant In-Reply-To: References: <20050228162548.GA57140@frontfree.net> Content-Type: text/plain Organization: Offmyserver, Inc. Date: Mon, 28 Feb 2005 19:10:42 +0100 Message-Id: <1109614242.3934.101.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Please contact support@home.nl for more information X-AtHome-MailScanner: Found to be clean cc: freebsd-arch@FreeBSD.org Subject: Re: bind() on 127.0.0.1 in jail: bound to the outside address? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 18:10:52 -0000 On Mon, 2005-02-28 at 16:48 +0000, Jan Grant wrote: > On Tue, 1 Mar 2005, Xin LI wrote: > > > Your ideas are highly appreciated! > > It's not minimal, but assuming that it's desirable that processes > listening on loopback sockets shouldn't collide outside the jail, one > approach might be as follows: > > - get jails to the point where they can manage more than one IP address > per jail; > - a jail config will then include an alias on the loopback address > (127.0.0.2, ...) > > unfortunately like all jail extensions this has other problems - for > instance, the close association of a jail to "its IP address" is broken > by this. While this might be a known issue, I really think this should be seen as a bug, and it's a security issue as well IMO. I know Samy Bahra has some (experimental) work[1] with giving jails a different unique identifier and conglomerating jails. This work on its own might give something useful for implementing something to solve this issue. I can certainly understand the security issues with jails using loopback sockets. Certainly very many daemon processes make use of them for various reasons (client / server communication in databases, etc) and presenting them to an outside address is simply broken. Binding to a local address that turns out to not be local can be a big hazard for several control daemons that I can think of off the top of my head. It's also not always possible to replace these with UDS solutions; some things I can think of are closed source. I'm sorry to bring up an old issue, but what are the current reasons / issues with the PJD MIP jail patches that it is not committable? Kind regards, Devon H. O'Dell [1] http://samy.kerneled.org/wordpress/index.php?p=7 From owner-freebsd-arch@FreeBSD.ORG Mon Feb 28 21:12:29 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB0FA16A4CE for ; Mon, 28 Feb 2005 21:12:29 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33D0643D46 for ; Mon, 28 Feb 2005 21:12:29 +0000 (GMT) (envelope-from fehwalker@gmail.com) Received: by wproxy.gmail.com with SMTP id 49so16810wri for ; Mon, 28 Feb 2005 13:12:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WPhoVyFFt4GrYAJv0e3PhwncN3xdAQdcODqsUV+mVU7DD3Qc4rekisBBqB6DlVzty/TYcVLkgZzyhO9XZH11BbtjZjMkutvfQCTumrx/IXtyxmHeIud5msdo3cXEpa//HYfI/kRq2yl/KTG3HCaEm2wDfZxk/v4VubPn8QyUwcY= Received: by 10.54.17.14 with SMTP id 14mr64523wrq; Mon, 28 Feb 2005 13:12:28 -0800 (PST) Received: by 10.54.19.52 with HTTP; Mon, 28 Feb 2005 13:12:28 -0800 (PST) Message-ID: <35de0c300502281312617af051@mail.gmail.com> Date: Mon, 28 Feb 2005 16:12:28 -0500 From: Bryan Fullerton To: freebsd-arch@freebsd.org, freebsd-security@freebsd.org In-Reply-To: <20050228162548.GA57140@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050228162548.GA57140@frontfree.net> Subject: Re: bind() on 127.0.0.1 in jail: bound to the outside address? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bryan Fullerton List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2005 21:12:29 -0000 I'd noticed this as well, but assumed it was a feature. Given that there's only one IP inside the jail, how do you bind to a loopback IP that doesn't exist? I suspect the behavior you're seeing is another 'simple hack' to allow binding to the loopback IP to not just immediately fail with "unable to bind". If this isn't documented somewhere (I didn't bother to check, it made sense to me once I figured out what it was doing) it should be. I have noticed that documentation of jail in the handbook in general is a bit lacking, maybe I'll see if I can find time to look at that (heh). Bryan On Tue, 1 Mar 2005 00:25:48 +0800, Xin LI wrote: > Dear folks, > > It seems that doing bind() inside a jail (whose IP address is an outside > address), will result in some wierd behavior, that the actual bind is > done on the outside address. > > For example, binding to 127.0.0.1:6666 inside a jail addressed 192.168.1.1, > will finally result in a bind to 192.168.1.1:6666. With this in mind, > it is possible that some formerly secure configuration fail in jail > environment. > > It seems that our implementation will forward every loopback connection > to the outside address. A simple hack to work around this issue might > be to modify the individual bind procedures to treat prison case with > loopback address, but I'm not sure if a true solution can solve the > issue with minimum code change and code complexity. > > Your ideas are highly appreciated! > > Cheers, > -- > Xin LI http://www.delphij.net/ > See complete headers for GPG key and other information. > > > From owner-freebsd-arch@FreeBSD.ORG Tue Mar 1 02:41:38 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E49516A4D2 for ; Tue, 1 Mar 2005 02:41:38 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D29F043D5A for ; Tue, 1 Mar 2005 02:41:33 +0000 (GMT) (envelope-from sureshnaidu.chaganti@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so970695wri for ; Mon, 28 Feb 2005 18:41:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FiH2a0eKXY9s8t5rLgfs1NvTd8mPYP4W7WDsNvXeeviy1Fh517cT95MewOdglnJfF+KRdn825BCa5/6+PttnQBLiSk42WE91UfP0PGhxbtBuvEkE4JBG2qqTU/r5bhUbq+zTerxzd/alRoS40nVEH5BqGsXS646w3Q60CvqHmlA= Received: by 10.54.54.49 with SMTP id c49mr103946wra; Mon, 28 Feb 2005 18:41:32 -0800 (PST) Received: by 10.54.42.66 with HTTP; Mon, 28 Feb 2005 18:41:31 -0800 (PST) Message-ID: Date: Tue, 1 Mar 2005 10:41:31 +0800 From: Suresh Naidu To: freebsd-x11@freebsd.org, nxdevelopers@nomachine.com, nxusers@nomachine.com, nxannounce@nomachine.com, freebsd-arch@freebsd.org, freebsd-questions@freebsd.org, freebsd-stable@freebsd.org, freebsd-test@freebsd.org, freebsd-testing@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Subject: (Help Me!) Problem in Compiling Nx Src on FreeBSD Machine of version 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0:) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Suresh Naidu List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 02:41:39 -0000 Hi Guys GREETING!!! I am facing few errors while compiling Nx src can Any one please help me in the below issue. I am giving detail explanation ( with errors printed) about the errors I got step by Step please go through the errors if necessary and please do let me know any solution. FYI, I am using FreeBSD machine for compiling the below src, and FreeBSD version is 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0:) After Untar I noticed .... 11 CONFIGURE SCRIPTS and MAKE FILES , which can be executed I have executed all the 11 CONFIGURE SCRIPTS and MAKE files and explained u all the output for ur reference I have downloaded following tarballs from the http://www.nomachine.com/sources NX-OSS Sources NOTE: IF I am worng with the following procedure please do let me know the correct way to compile NX SRC on FreeBSD machine ----------Start of TAR BALLS List ------- 1. nxagent-1.4.0-65.tar.gz 2. nxdarwin-1.4.0-3.tar.gz 3. nxauth-1.4.0-2.tar.gz 4. nxwin-1.4.0-4.tar.gz 5. nxcomp-1.4.0-31.tar.gz 6. nx-X11-1.4.0-10.tar.gz 7. nxcompext-1.4.0-3.tar.gz 8. nxviewer-1.4.0-5.tar.gz 9. nxdesktop-1.4.0-61.tar.gz 10. nxspool-1.4.0-4.tar.gz 11.nxesd-1.4.0-1.tar.gz 12.nxssh-1.4.0-22.tar.gz 13. nxproxy-1.4.0-3.tar.gz 14. nxuexec-1.4.0-13.tar.gz 15. nxscripts-1.4.0-3.tar.gz ----------Start of TAR BALLS List ------- out of 15 tar balls I was in need of first 7 tar balls and I have untar all the 7 tar balls I got the directories as. $ ls -l total 10 drwxr-xr-x 10 600 200 512 Feb 28 09:58 nx-X11 drwxr-xr-x 3 600 200 5632 Feb 28 14:24 nxcomp drwxr-xr-x 3 10004 100 1024 Feb 28 10:33 nxcompext and I found all the configure scripts location by using the command ... $ find . | grep configure$ then I got output as --- Start of finding the configure file loc --- 1. ./nx-X11/extras/expat/configure 2. ./nx-X11/programs/xterm/configure 3. ./nx-X11/extras/freetype2/configure 4. ./nx-X11/extras/FreeType/contrib/ttf2bdf/configure 5. ./nx-X11/extras/FreeType/contrib/ttf2pfb/configure 6. ./nx-X11/extras/FreeType/contrib/ttf2pk/configure 7. ./nx-X11/extras/FreeType/contrib/ttfbanner/configure 8. ./nx-X11/extras/FreeType/configure 9. ./nx-X11/extras/freetype2/builds/unix/configure 10. ./nxcomp/configure 11. ./nxcompext/configure ------ Start of finding the configure file loc ----- 1 . configure script executed successfully and I can also do MAKE and MAKE INSTALL works fine.. 2. configure script executed successfully (./nx-X11/programs/xterm/configure) $ make $ make install also executed successfully! 3. Configure script ( ./nx-X11/extras/freetype2/configure ) executed successfully $ gmake $ gmake install also executed successfully! 4. when I try to run (./nx-X11/extras/FreeType/contrib/ttf2bdf/configure) script it gives the following output ----4. Start Of configure scipt output ---- loading cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for TT_Init_FreeType in -lttf... no configure: error: Can't find ttf library! Compile FreeType first. ----- 4. End of configure script output ----- 5 . when I try to run (./nx-X11/extras/FreeType/contrib/ttf2pfb/configure) script it gives the following output ----5. Start Of configure scipt output ---- loading cache ./config.cache checking host system type... i386-unknown-freebsdelf5.2.1 checking target system type... i386-unknown-freebsdelf5.2.1 checking build system type... i386-unknown-freebsdelf5.2.1 checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking for TT_Init_FreeType in -lttf... no configure: error: Can't find ttf library! Compile FreeType first. ----- 5. End of configure script output ----- 6. as same as above asking to compile FreeType First 7. as same as above asking to compile FreeType First 8. then I did $ cd ./nx-X11/extras/FreeType/ $ ./configure then it gives the following output ----- 8. Start of configure script output ----- loading cache ./config.cache checking host system type... i386-unknown-freebsdelf5.2.1 checking build system type... i386-unknown-freebsdelf5.2.1 checking for ranlib... (cached) ranlib checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for ld used by GCC... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes checking for BSD-compatible nm... (cached) /usr/bin/nm -B checking whether ln -s works... (cached) yes updating cache ./config.cache loading cache ./config.cache within ltconfig checking for object suffix... o checking for executable suffix... (cached) no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions ... no checking if gcc static flag -static works... -static checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking command to parse /usr/bin/nm -B output... ok checking how to hardcode library paths into programs... immediate checking for /usr/bin/ld option to reload object files... -r checking dynamic linker characteristics... freebsdelf5.2.1 ld.so checking if libtool supports shared libraries... yes *** Warning: the command libtool uses to detect shared libraries, *** /usr/bin/file, produces output that libtool cannot recognize. *** The result is that libtool may fail to recognize shared libraries *** as such. This will affect the creation of libtool libraries that *** depend on shared libraries, but programs linked with such libtool *** libraries will work regardless of this problem. Nevertheless, you *** may want to report the problem to your system manager and/or to *** bug-libtool@gnu.org checking whether to build shared libraries... yes checking whether to build static libraries... no checking for objdir... .libs creating libtool updating cache ./config.cache loading cache ./config.cache checking host system type... i386-unknown-freebsdelf5.2.1 checking target system type... i386-unknown-freebsdelf5.2.1 checking build system type... i386-unknown-freebsdelf5.2.1 checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking whether make sets ${MAKE}... (cached) yes checking for locale.h... (cached) yes checking for setlocale... (cached) yes checking for libintl.h... (cached) no checking for gettext in -lintl... (cached) no checking for msgfmt... (cached) /usr/local/bin/msgfmt checking for dcgettext... (cached) no checking for gmsgfmt... (cached) /usr/local/bin/msgfmt checking for xgettext... (cached) /usr/local/bin/xgettext checking for msgmerge... (cached) /usr/local/bin/msgmerge checking for rm... (cached) rm checking for rmdir... (cached) rmdir checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether ln -s works... (cached) yes checking for gethostbyname... (cached) yes checking for socket... (cached) yes checking for cos in -lm... (cached) yes checking for X... (cached) libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for dnet_ntoa in -ldnet... (cached) no checking for dnet_ntoa in -ldnet_stub... (cached) no checking for gethostbyname... (cached) yes checking for connect... (cached) yes checking for remove... (cached) yes checking for shmat... (cached) yes checking for IceConnectionNumber in -lICE... (cached) yes checking for stdlib.h... (cached) yes checking for fcntl.h... (cached) yes checking for unistd.h... (cached) yes checking for working const... (cached) yes checking size of int... (cached) 4 checking size of long... (cached) 4 checking for unistd.h... (cached) yes checking for getpagesize... (cached) yes checking for working mmap... (cached) yes checking for memcpy... (cached) yes checking for memmove... (cached) yes updating cache ./config.cache creating ./config.status creating Makefile creating MakeSub creating lib/arch/unix/Makefile creating test/arch/unix/Makefile creating po/Makefile.in creating ft_conf.h ft_conf.h is unchanged ----- 8. End of configure script output ----- then again I tried with the following command $ make ---- 8. Start of Make command ouput ---- cd lib; make -f arch/unix/Makefile all rm -f memory.c file.c mutex.c ln -s /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../ttmemory.c memory.c ln -s /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../arch/unix/ttmmap.c file.c ln -s /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../ttmutex.c mutex.c make -f arch/unix/Makefile LIB_FILES="freetype.lo ftxkern.lo ftxgasp.lo ftxpost.lo ftxcmap.lo ftxsbit.lo ftxwidth.lo ftxerr18.lo ftxgsub.lo ftxgpos.lo ftxgdef.lo ftxopen.lo" libttf.la ../libtool --mode=compile gcc -c -g -O2 -Wall -pedantic -ansi -I. -I.. -I/home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../.. -I/home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../extend -DLOCALEDIR='"/usr/local/share/locale"' -DTT_MAKE_OPTION_SINGLE_OBJECT /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../arch/unix/freetype.c gcc -c -g -O2 -Wall -pedantic -ansi -I. -I.. -I/home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../.. -I/home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../extend -DLOCALEDIR=\"/usr/local/share/locale\" -DTT_MAKE_OPTION_SINGLE_OBJECT -fPIC -DPIC /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/../../arch/unix/freetype.c -o freetype.lo In file included from ttobjs.h:27, from ttapi.c:34, from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:7: ttcmap.h:124: error: syntax error before "Bool" In file included from ttapi.c:34, from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:7: ttobjs.h:192: error: syntax error before "Bool" ttobjs.h:200: error: syntax error before "Bool" ttobjs.h:262: error: syntax error before "Bool" ttobjs.h:357: error: syntax error before "Bool" ttobjs.h:464: error: syntax error before "Bool" ttobjs.h:511: error: syntax error before "Bool" ttobjs.h:596: error: syntax error before "Bool" ttobjs.h:630: error: syntax error before "Bool" ttobjs.h:679: error: syntax error before "Bool" ttobjs.h:722: error: syntax error before "Bool" ttobjs.h:730: error: syntax error before "Bool" ttobjs.h:836: error: syntax error before "Bool" In file included from ttapi.c:35, from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:7: ttload.h:56: error: syntax error before "Bool" In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:7: ttapi.c: In function `TT_Init_FreeType': ttapi.c:124: warning: dereferencing type-punned pointer will break strict-aliasing rules ttapi.c: In function `TT_Done_FreeType': ttapi.c:196: warning: dereferencing type-punned pointer will break strict-aliasing rules ttapi.c: In function `TT_Open_Face': ttapi.c:285: warning: dereferencing type-punned pointer will break strict-aliasing rules ttapi.c: In function `TT_Open_Collection': ttapi.c:349: warning: dereferencing type-punned pointer will break strict-aliasing rules ttapi.c: In function `TT_Get_Face_Properties': ttapi.c:409: error: structure has no member named `verticalInfo' ttapi.c: In function `TT_Get_Face_Metrics': ttapi.c:589: error: structure has no member named `verticalInfo' ttapi.c: In function `TT_New_Instance': ttapi.c:706: warning: dereferencing type-punned pointer will break strict-aliasing rules ttapi.c: In function `TT_Set_Instance_Resolutions': ttapi.c:763: error: structure has no member named `valid' ttapi.c: In function `TT_Set_Instance_CharSizes': ttapi.c:834: error: structure has no member named `valid' ttapi.c: In function `TT_Set_Instance_PixelSizes': ttapi.c:912: error: structure has no member named `valid' ttapi.c: In function `TT_Set_Instance_Transform_Flags': ttapi.c:953: error: structure has no member named `rotated' ttapi.c:954: error: structure has no member named `stretched' ttapi.c:955: error: structure has no member named `valid' ttapi.c: In function `TT_Get_Instance_Metrics': ttapi.c:986: error: structure has no member named `valid' ttapi.c: In function `TT_New_Glyph': ttapi.c:1132: warning: dereferencing type-punned pointer will break strict-aliasing rules ttapi.c: In function `TT_Load_Glyph': ttapi.c:1214: error: structure has no member named `valid' ttapi.c: In function `TT_Copy_Outline': ttapi.c:1640: warning: implicit declaration of function `memcpy' ttapi.c: In function `TT_Get_CharMap': ttapi.c:1941: error: structure has no member named `loaded' ttapi.c:1953: error: structure has no member named `loaded' In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:8: ttcache.c: In function `Element_New': ttcache.c:75: warning: dereferencing type-punned pointer will break strict-aliasing rules ttcache.c: In function `Cache_Done': ttcache.c:363: error: syntax error before "destroy" ttcache.c:391: error: `destroy' undeclared (first use in this function) ttcache.c:391: error: (Each undeclared identifier is reported only once ttcache.c:391: error: for each function it appears in.) ttcache.c: In function `TTCache_Done': ttcache.c:456: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:10: ttcmap.c: In function `CharMap_Load': ttcmap.c:66: error: structure has no member named `loaded' ttcmap.c: In function `CharMap_Free': ttcmap.c:283: error: structure has no member named `loaded' In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:12: ttgload.c: At top level: ttgload.c:92: error: syntax error before "Bool" ttgload.c: In function `Get_HMetrics': ttgload.c:96: error: `face' undeclared (first use in this function) ttgload.c:96: error: `index' undeclared (first use in this function) ttgload.c:96: error: `lsb' undeclared (first use in this function) ttgload.c:96: error: `aw' undeclared (first use in this function) ttgload.c:98: error: `check' undeclared (first use in this function) ttgload.c: In function `Load_Simple_Glyph': ttgload.c:385: error: structure has no member named `is_hinted' ttgload.c:398: error: structure has no member named `is_composite' ttgload.c:399: error: structure has no member named `pedantic_hinting' ttgload.c:402: error: structure has no member named `pedantic_hinting' ttgload.c:411: error: structure has no member named `preserve_pps' ttgload.c: In function `Load_Composite_End': ttgload.c:441: error: structure has no member named `is_hinted' ttgload.c:490: error: structure has no member named `is_hinted' ttgload.c:502: error: structure has no member named `is_hinted' ttgload.c:504: error: structure has no member named `is_composite' ttgload.c:505: error: structure has no member named `pedantic_hinting' ttgload.c:508: error: structure has no member named `pedantic_hinting' ttgload.c: In function `Init_Glyph_Component': ttgload.c:532: error: structure has no member named `is_scaled' ttgload.c:533: error: structure has no member named `is_hinted' ttgload.c:547: error: structure has no member named `preserve_pps' ttgload.c: In function `Load_TrueType_Glyph': ttgload.c:645: error: structure has no member named `debug' ttgload.c:682: error: structure has no member named `is_hinted' ttgload.c:687: error: structure has no member named `is_hinted' ttgload.c:873: error: structure has no member named `is_hinted' ttgload.c:920: error: structure has no member named `is_hinted' ttgload.c:920: error: structure has no member named `is_hinted' ttgload.c:979: error: structure has no member named `is_scaled' ttgload.c:985: error: structure has no member named `is_scaled' ttgload.c:993: error: structure has no member named `is_scaled' ttgload.c:1007: error: structure has no member named `is_hinted' ttgload.c:1037: error: structure has no member named `preserve_pps' ttgload.c:1046: error: structure has no member named `preserve_pps' ttgload.c:1051: error: structure has no member named `is_scaled' ttgload.c:1199: error: structure has no member named `is_hinted' ttgload.c:1250: error: structure has no member named `verticalInfo' ttgload.c:1309: error: structure has no member named `is_hinted' ttgload.c:1323: error: structure has no member named `is_hinted' ttgload.c:1344: error: structure has no member named `debug' In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:13: ttinterp.c: At top level: ttinterp.c:648: error: syntax error before "Calc_Length" ttinterp.c:649: warning: return type defaults to `int' ttinterp.c:742: error: syntax error before "Ins_Goto_CodeRange" ttinterp.c:743: warning: return type defaults to `int' ttinterp.c: In function `Compute_Funcs': ttinterp.c:1450: error: structure has no member named `cached_metrics' ttinterp.c: At top level: ttinterp.c:1509: error: syntax error before "Normalize" ttinterp.c:1512: warning: return type defaults to `int' ttinterp.c: In function `Normalize': ttinterp.c:1514: error: syntax error before "S1" ttinterp.c:1550: error: `S1' undeclared (first use in this function) ttinterp.c:1558: error: `S2' undeclared (first use in this function) ttinterp.c: At top level: ttinterp.c:1608: error: syntax error before "Ins_SxVTL" ttinterp.c:1612: warning: return type defaults to `int' ttinterp.c: In function `Ins_SxVTL': ttinterp.c:1621: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MINDEX': ttinterp.c:2961: warning: implicit declaration of function `memmove' ttinterp.c: At top level: ttinterp.c:2998: error: syntax error before "SkipCode" ttinterp.c:2999: warning: return type defaults to `int' ttinterp.c: In function `Ins_IF': ttinterp.c:3019: error: syntax error before "Out" ttinterp.c:3026: error: `Out' undeclared (first use in this function) ttinterp.c: At top level: ttinterp.c:3091: error: syntax error before "Bool" ttinterp.c: In function `Locate_FDef': ttinterp.c:3105: error: `new_def' undeclared (first use in this function) ttinterp.c:3105: error: `n' undeclared (first use in this function) ttinterp.c:3105: error: `exc' undeclared (first use in this function) ttinterp.c:3112: error: structure has no member named `Active' ttinterp.c: In function `Ins_FDEF': ttinterp.c:3162: error: structure has no member named `Active' ttinterp.c:3168: error: structure has no member named `Active' ttinterp.c: In function `Ins_ENDF': ttinterp.c:3213: error: structure has no member named `step_ins' ttinterp.c: In function `Ins_CALL': ttinterp.c:3274: error: structure has no member named `step_ins' ttinterp.c: In function `Ins_LOOPCALL': ttinterp.c:3321: error: structure has no member named `step_ins' ttinterp.c: In function `Ins_IDEF': ttinterp.c:3361: error: structure has no member named `Active' ttinterp.c: In function `Ins_NPUSHW': ttinterp.c:3440: error: structure has no member named `step_ins' ttinterp.c: In function `Ins_PUSHW': ttinterp.c:3491: error: structure has no member named `step_ins' ttinterp.c: In function `Ins_GC': ttinterp.c:3522: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SCFS': ttinterp.c:3562: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MD': ttinterp.c:3605: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SDPVTL': ttinterp.c:3642: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SZP0': ttinterp.c:3705: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SZP1': ttinterp.c:3732: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SZP2': ttinterp.c:3759: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SZPS': ttinterp.c:3786: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_INSTCTRL': ttinterp.c:3815: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SCANCTRL': ttinterp.c:3843: error: structure has no member named `scan_control' ttinterp.c:3848: error: structure has no member named `scan_control' ttinterp.c:3855: error: structure has no member named `scan_control' ttinterp.c:3857: error: structure has no member named `rotated' ttinterp.c:3858: error: structure has no member named `scan_control' ttinterp.c:3860: error: structure has no member named `stretched' ttinterp.c:3861: error: structure has no member named `scan_control' ttinterp.c:3864: error: structure has no member named `scan_control' ttinterp.c:3866: error: structure has no member named `rotated' ttinterp.c:3867: error: structure has no member named `scan_control' ttinterp.c:3869: error: structure has no member named `stretched' ttinterp.c:3870: error: structure has no member named `scan_control' ttinterp.c: In function `Ins_FLIPPT': ttinterp.c:3927: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_FLIPRGON': ttinterp.c:3961: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_FLIPRGOFF': ttinterp.c:3988: error: structure has no member named `pedantic_hinting' ttinterp.c: At top level: ttinterp.c:3998: error: syntax error before "Compute_Point_Displacement" ttinterp.c:4003: warning: return type defaults to `int' ttinterp.c: In function `Compute_Point_Displacement': ttinterp.c:4022: error: structure has no member named `pedantic_hinting' ttinterp.c: At top level: ttinterp.c:4043: error: syntax error before "Bool" ttinterp.c: In function `Move_Zp2_Point': ttinterp.c:4045: error: `exc' undeclared (first use in this function) ttinterp.c:4047: error: `point' undeclared (first use in this function) ttinterp.c:4047: error: `dx' undeclared (first use in this function) ttinterp.c:4048: error: `touch' undeclared (first use in this function) ttinterp.c:4054: error: `dy' undeclared (first use in this function) ttinterp.c: In function `Ins_SHP': ttinterp.c:4092: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SHC': ttinterp.c:4130: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SHZ': ttinterp.c:4181: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_SHPIX': ttinterp.c:4235: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MSIRP': ttinterp.c:4268: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MDAP': ttinterp.c:4309: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MIAP': ttinterp.c:4351: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MDRP': ttinterp.c:4422: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_MIRP': ttinterp.c:4509: error: structure has no member named `pedantic_hinting' ttinterp.c:4554: error: structure has no member named `auto_flip' ttinterp.c: In function `Ins_ALIGNRP': ttinterp.c:4622: error: structure has no member named `pedantic_hinting' ttinterp.c:4635: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_ISECT': ttinterp.c:4692: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_ALIGNPTS': ttinterp.c:4754: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_IP': ttinterp.c:4813: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_UTP': ttinterp.c:4868: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_DELTAP': ttinterp.c:5147: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_DELTAC': ttinterp.c:5184: error: structure has no member named `pedantic_hinting' ttinterp.c: In function `Ins_GETINFO': ttinterp.c:5255: error: structure has no member named `rotated' ttinterp.c:5259: error: structure has no member named `stretched' ttinterp.c: In function `Ins_UNKNOWN': ttinterp.c:5275: error: structure has no member named `Active' ttinterp.c:5300: error: structure has no member named `step_ins' ttinterp.c: In function `RunIns': ttinterp.c:5691: error: structure has no member named `step_ins' ttinterp.c:5820: error: structure has no member named `step_ins' ttinterp.c:5952: error: structure has no member named `pedantic_hinting' ttinterp.c:5960: error: structure has no member named `pedantic_hinting' ttinterp.c:5964: error: structure has no member named `pedantic_hinting' ttinterp.c:5968: error: structure has no member named `pedantic_hinting' ttinterp.c:5994: error: structure has no member named `auto_flip' ttinterp.c:5998: error: structure has no member named `auto_flip' ttinterp.c:6116: error: structure has no member named `pedantic_hinting' ttinterp.c:6139: error: structure has no member named `step_ins' ttinterp.c:6143: error: structure has no member named `step_ins' ttinterp.c:6253: error: structure has no member named `Active' ttinterp.c:6293: error: structure has no member named `step_ins' ttinterp.c:6316: error: structure has no member named `instruction_trap' In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:14: ttload.c: In function `Load_TrueType_Gasp': ttload.c:383: warning: dereferencing type-punned pointer will break strict-aliasing rules ttload.c:406: warning: dereferencing type-punned pointer will break strict-aliasing rules ttload.c: At top level: ttload.c:500: error: syntax error before "Bool" ttload.c: In function `Load_TrueType_Metrics': ttload.c:516: error: `vertical' undeclared (first use in this function) ttload.c:525: error: `face' undeclared (first use in this function) ttload.c: At top level: ttload.c:628: error: syntax error before "Bool" ttload.c: In function `Load_TrueType_Metrics_Header': ttload.c:639: error: `vertical' undeclared (first use in this function) ttload.c:641: error: `face' undeclared (first use in this function) ttload.c: In function `Load_TrueType_Names': ttload.c:883: warning: dereferencing type-punned pointer will break strict-aliasing rules ttload.c:949: warning: dereferencing type-punned pointer will break strict-aliasing rules ttload.c: In function `Load_TrueType_CMap': ttload.c:1106: error: structure has no member named `loaded' In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:15: ttobjs.c: In function `New_Context': ttobjs.c:56: warning: dereferencing type-punned pointer will break strict-aliasing rules ttobjs.c: In function `Context_Load': ttobjs.c:583: error: structure has no member named `instruction_trap' ttobjs.c: At top level: ttobjs.c:624: error: syntax error before "Bool" ttobjs.c: In function `Context_Run': ttobjs.c:629: error: `exec' undeclared (first use in this function) ttobjs.c:655: error: `debug' undeclared (first use in this function) ttobjs.c: At top level: ttobjs.c:671: warning: excess elements in struct initializer ttobjs.c:671: warning: (near initialization for `Default_GraphicsState') ttobjs.c:672: warning: excess elements in struct initializer ttobjs.c:672: warning: (near initialization for `Default_GraphicsState') ttobjs.c: In function `Instance_Destroy': ttobjs.c:704: error: structure has no member named `debug' ttobjs.c:708: error: structure has no member named `debug' ttobjs.c:731: error: structure has no member named `valid' ttobjs.c: In function `Instance_Create': ttobjs.c:765: error: structure has no member named `valid' ttobjs.c:785: error: structure has no member named `rotated' ttobjs.c:786: error: structure has no member named `stretched' ttobjs.c: In function `Instance_Init': ttobjs.c:838: error: structure has no member named `debug' ttobjs.c:881: error: structure has no member named `instruction_trap' ttobjs.c:912: error: structure has no member named `debug' ttobjs.c:916: error: structure has no member named `valid' ttobjs.c: In function `Instance_Reset': ttobjs.c:949: error: structure has no member named `valid' ttobjs.c:1005: error: structure has no member named `debug' ttobjs.c:1023: error: structure has no member named `instruction_trap' ttobjs.c:1034: error: structure has no member named `debug' ttobjs.c:1046: error: structure has no member named `debug' ttobjs.c:1051: error: structure has no member named `valid' ttobjs.c: In function `Face_Destroy': ttobjs.c:1128: error: structure has no member named `verticalInfo' ttobjs.c:1132: error: structure has no member named `verticalInfo' ttobjs.c: In function `TTObjs_Init': ttobjs.c:1432: warning: dereferencing type-punned pointer will break strict-aliasing rules ttobjs.c:1433: warning: dereferencing type-punned pointer will break strict-aliasing rules ttobjs.c:1459: warning: dereferencing type-punned pointer will break strict-aliasing rules ttobjs.c:1460: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:16: ttraster.c: At top level: ttraster.c:261: error: syntax error before "Bool" ttraster.c:306: error: syntax error before "Bool" ttraster.c:406: error: syntax error before "Bool" ttraster.c: In function `Set_High_Precision': ttraster.c:408: error: `High' undeclared (first use in this function) ttraster.c:410: error: `raster' undeclared (first use in this function) ttraster.c: At top level: ttraster.c:443: error: syntax error before "New_Profile" ttraster.c:444: warning: return type defaults to `int' ttraster.c: In function `New_Profile': ttraster.c:486: error: structure has no member named `fresh' ttraster.c:487: error: structure has no member named `joint' ttraster.c: At top level: ttraster.c:506: error: syntax error before "End_Profile" ttraster.c:507: warning: return type defaults to `int' ttraster.c: In function `End_Profile': ttraster.c:545: error: structure has no member named `joint' ttraster.c: At top level: ttraster.c:563: error: syntax error before "Insert_Y_Turn" ttraster.c:564: warning: return type defaults to `int' ttraster.c:614: error: syntax error before "Finalize_Profile_Table" ttraster.c:615: warning: return type defaults to `int' ttraster.c:741: error: syntax error before "Line_Up" ttraster.c:744: warning: return type defaults to `int' ttraster.c: In function `Line_Up': ttraster.c:794: error: structure has no member named `joint' ttraster.c:797: error: structure has no member named `joint' ttraster.c:800: error: structure has no member named `joint' ttraster.c:802: error: structure has no member named `fresh' ttraster.c:805: error: structure has no member named `fresh' ttraster.c: At top level: ttraster.c:852: error: syntax error before "Line_Down" ttraster.c:855: warning: return type defaults to `int' ttraster.c: In function `Line_Down': ttraster.c:856: error: syntax error before "result" ttraster.c:859: error: `fresh' undeclared (first use in this function) ttraster.c:859: error: structure has no member named `fresh' ttraster.c:861: error: `result' undeclared (first use in this function) ttraster.c:863: error: structure has no member named `fresh' ttraster.c: At top level: ttraster.c:884: error: syntax error before "Bezier_Up" ttraster.c:885: warning: return type defaults to `int' ttraster.c: In function `Bezier_Up': ttraster.c:920: error: structure has no member named `joint' ttraster.c:923: error: structure has no member named `joint' ttraster.c:934: error: structure has no member named `fresh' ttraster.c:937: error: structure has no member named `fresh' ttraster.c:954: error: structure has no member named `joint' ttraster.c:981: error: structure has no member named `joint' ttraster.c: At top level: ttraster.c:1013: error: syntax error before "Bezier_Down" ttraster.c:1014: warning: return type defaults to `int' ttraster.c: In function `Bezier_Down': ttraster.c:1016: error: syntax error before "result" ttraster.c:1023: error: `fresh' undeclared (first use in this function) ttraster.c:1023: error: structure has no member named `fresh' ttraster.c:1025: error: `result' undeclared (first use in this function) ttraster.c:1027: error: structure has no member named `fresh' ttraster.c: At top level: ttraster.c:1048: error: syntax error before "Line_To" ttraster.c:1049: warning: return type defaults to `int' ttraster.c:1127: error: syntax error before "Bezier_To" ttraster.c:1131: warning: return type defaults to `int' ttraster.c:1241: error: syntax error before "Decompose_Curve" ttraster.c:1243: error: syntax error before "Bool" ttraster.c:1244: warning: return type defaults to `int' ttraster.c: In function `Decompose_Curve': ttraster.c:1253: error: syntax error before "on_curve" ttraster.c:1255: error: `raster' undeclared (first use in this function) ttraster.c:1255: error: `first' undeclared (first use in this function) ttraster.c:1258: error: `flipped' undeclared (first use in this function) ttraster.c:1260: error: `last' undeclared (first use in this function) ttraster.c:1268: error: `on_curve' undeclared (first use in this function) ttraster.c: At top level: ttraster.c:1373: error: syntax error before "Convert_Glyph" ttraster.c:1374: warning: return type defaults to `int' ttraster.c: In function `Convert_Glyph': ttraster.c:1382: error: structure has no member named `joint' ttraster.c:1383: error: structure has no member named `fresh' ttraster.c: In function `Vertical_Sweep_Span': ttraster.c:1655: warning: implicit declaration of function `memset' ttraster.c: At top level: ttraster.c:2142: error: syntax error before "Draw_Sweep" ttraster.c:2143: warning: return type defaults to `int' ttraster.c:2392: error: syntax error before "Bool" ttraster.c: In function `Render_Single_Pass': ttraster.c:2397: error: `raster' undeclared (first use in this function) ttraster.c:2406: error: `flipped' undeclared (first use in this function) ttraster.c: In function `Render_Glyph': ttraster.c:2496: error: structure has no member named `second_pass' ttraster.c:2517: error: structure has no member named `second_pass' ttraster.c: In function `Render_Gray_Glyph': ttraster.c:2592: error: structure has no member named `second_pass' ttraster.c:2620: error: structure has no member named `second_pass' In file included from /usr/include/string.h:49, from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c:25, from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:19: /usr/include/strings.h: At top level: /usr/include/strings.h:45: error: `index' used prior to declaration In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:19: /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c: In function `Allocate_Map': /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c:375: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c: In function `Release_Map': /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c:405: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c: In function `TT_Open_Stream': /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c:484: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c: In function `TT_Close_Stream': /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/ttmmap.c:511: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib/arch/unix/freetype.c:27: ttextend.c: In function `TTExtend_Init': ttextend.c:53: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib. *** Error code 1 Stop in /home/suresh/Trail-NX/nx-X11/extras/FreeType/lib. *** Error code 1 Stop in /home/suresh/Trail-NX/nx-X11/extras/FreeType. ---- 8. End of Make command ouput -------- then Finally I cannot able to compile the src. I was strucked since long back .. 9. only configure script ( ./nx-X11/extras/freetype2/builds/unix/configure) executed no make file was generated or created to run ... 10. configurescript (./nxcomp/configure ) successfull ---- 10. Start of configure command ouput ---- checking for g++... g++ checking for C++ compiler default output... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking whether compiler needs -Wno-deprecated... yes checking whether compiler accepts -Wmissing-declarations and -Wnested-externs... no checking for a BSD-compatible install... /usr/bin/install -c checking how to run the C++ preprocessor... g++ -E checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for Cygwin32 environment... no checking for Darwin environment... no checking for Solaris environment... no checking for FreeBSD environment... yes checking for in_addr_t... yes compiling version 1.4.0 enabling dynamic linking of PNG library enabling dynamic linking of JPEG library enabling dynamic linking of Z library disabling production of debug symbols disabling info output in the log file disabling valgrind memory checker workarounds configure: creating ./config.status config.status: creating Makefile ---- 10. End of configure command ouput ---- then I tried the command $make ---- 10. Start of Make command ouput ---- g++ -c -O3 -Wno-deprecated -I/usr/local/include -DIN_ADDR_T=in_addr_t -DVERSION=\"1.4.0\" -I/usr/X11R6/include -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes Loop.cpp In file included from /usr/include/c++/3.3/ios:48, from /usr/include/c++/3.3/istream:44, from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/bits/localefwd.h:58:34: macro "isspace" passed 2 arguments, but takes just 1 In file included from /usr/include/c++/3.3/ios:48, from /usr/include/c++/3.3/istream:44, from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/bits/localefwd.h:58: error: `std::isspace' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:58: error: template declaration of `bool std::isspace' /usr/include/c++/3.3/bits/localefwd.h:58: error: `template bool std::isspace' redeclared as different kind of symbol /usr/include/ctype.h:79: error: previous declaration of `int isspace(int)' /usr/include/c++/3.3/bits/localefwd.h:62:34: macro "isprint" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:62: error: `std::isprint' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:62: error: template declaration of `bool std::isprint' /usr/include/c++/3.3/bits/localefwd.h:62: error: `template bool std::isprint' redeclared as different kind of symbol /usr/include/ctype.h:77: error: previous declaration of `int isprint(int)' /usr/include/c++/3.3/bits/localefwd.h:66:34: macro "iscntrl" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:66: error: `std::iscntrl' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:66: error: template declaration of `bool std::iscntrl' /usr/include/c++/3.3/bits/localefwd.h:66: error: `template bool std::iscntrl' redeclared as different kind of symbol /usr/include/ctype.h:73: error: previous declaration of `int iscntrl(int)' /usr/include/c++/3.3/bits/localefwd.h:70:34: macro "isupper" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:70: error: `std::isupper' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:70: error: template declaration of `bool std::isupper' /usr/include/c++/3.3/bits/localefwd.h:70: error: `template bool std::isupper' redeclared as different kind of symbol /usr/include/ctype.h:80: error: previous declaration of `int isupper(int)' /usr/include/c++/3.3/bits/localefwd.h:74:34: macro "islower" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:74: error: `std::islower' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:74: error: template declaration of `bool std::islower' /usr/include/c++/3.3/bits/localefwd.h:74: error: `template bool std::islower' redeclared as different kind of symbol /usr/include/ctype.h:76: error: previous declaration of `int islower(int)' /usr/include/c++/3.3/bits/localefwd.h:78:34: macro "isalpha" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:78: error: `std::isalpha' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:78: error: template declaration of `bool std::isalpha' /usr/include/c++/3.3/bits/localefwd.h:78: error: `template bool std::isalpha' redeclared as different kind of symbol /usr/include/ctype.h:72: error: previous declaration of `int isalpha(int)' /usr/include/c++/3.3/bits/localefwd.h:82:34: macro "isdigit" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:82: error: `std::isdigit' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:82: error: template declaration of `bool std::isdigit' /usr/include/c++/3.3/bits/localefwd.h:82: error: `template bool std::isdigit' redeclared as different kind of symbol /usr/include/ctype.h:74: error: previous declaration of `int isdigit(int)' /usr/include/c++/3.3/bits/localefwd.h:86:34: macro "ispunct" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:86: error: `std::ispunct' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:86: error: template declaration of `bool std::ispunct' /usr/include/c++/3.3/bits/localefwd.h:86: error: `template bool std::ispunct' redeclared as different kind of symbol /usr/include/ctype.h:78: error: previous declaration of `int ispunct(int)' /usr/include/c++/3.3/bits/localefwd.h:90:35: macro "isxdigit" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:90: error: `std::isxdigit' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:90: error: template declaration of `bool std::isxdigit' /usr/include/c++/3.3/bits/localefwd.h:90: error: `template bool std::isxdigit' redeclared as different kind of symbol /usr/include/ctype.h:81: error: previous declaration of `int isxdigit(int)' /usr/include/c++/3.3/bits/localefwd.h:94:34: macro "isalnum" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:94: error: `std::isalnum' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:94: error: template declaration of `bool std::isalnum' /usr/include/c++/3.3/bits/localefwd.h:94: error: `template bool std::isalnum' redeclared as different kind of symbol /usr/include/ctype.h:71: error: previous declaration of `int isalnum(int)' /usr/include/c++/3.3/bits/localefwd.h:98:34: macro "isgraph" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:98: error: `std::isgraph' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:98: error: template declaration of `bool std::isgraph' /usr/include/c++/3.3/bits/localefwd.h:98: error: `template bool std::isgraph' redeclared as different kind of symbol /usr/include/ctype.h:75: error: previous declaration of `int isgraph(int)' /usr/include/c++/3.3/bits/localefwd.h:102:34: macro "toupper" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:102: error: `std::toupper' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:102: error: template declaration of ` _CharT std::toupper' /usr/include/c++/3.3/bits/localefwd.h:102: error: `template _CharT std::toupper' redeclared as different kind of symbol /usr/include/ctype.h:83: error: previous declaration of `int toupper(int)' /usr/include/c++/3.3/bits/localefwd.h:106:34: macro "tolower" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/localefwd.h:106: error: `std::tolower' declared as an `inline' variable /usr/include/c++/3.3/bits/localefwd.h:106: error: template declaration of ` _CharT std::tolower' /usr/include/c++/3.3/bits/localefwd.h:106: error: `template _CharT std::tolower' redeclared as different kind of symbol /usr/include/ctype.h:82: error: previous declaration of `int tolower(int)' In file included from /usr/include/c++/3.3/bits/basic_ios.h:44, from /usr/include/c++/3.3/ios:51, from /usr/include/c++/3.3/istream:44, from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/bits/locale_facets.h:197:53: macro "toupper" passed 2 arguments, but takes just 1 In file included from /usr/include/c++/3.3/bits/basic_ios.h:44, from /usr/include/c++/3.3/ios:51, from /usr/include/c++/3.3/istream:44, from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/bits/locale_facets.h:197: error: syntax error before ` const' /usr/include/c++/3.3/bits/locale_facets.h:201: error: syntax error before `(' token /usr/include/c++/3.3/bits/locale_facets.h:201: error: syntax error before `)' token /usr/include/c++/3.3/bits/locale_facets.h:202: error: non-member function `int std::__tolower(...)' cannot have `const' method qualifier /usr/include/c++/3.3/bits/locale_facets.h: In function `int std::__tolower(...) ': /usr/include/c++/3.3/bits/locale_facets.h:202: error: invalid use of `this' in non-member function /usr/include/c++/3.3/bits/locale_facets.h:202: error: `__c' undeclared (first use this function) /usr/include/c++/3.3/bits/locale_facets.h:202: error: (Each undeclared identifier is reported only once for each function it appears in.) /usr/include/c++/3.3/bits/locale_facets.h: At global scope: /usr/include/c++/3.3/bits/locale_facets.h:204: error: syntax error before `*' token /usr/include/c++/3.3/bits/locale_facets.h:205:53: macro "tolower" passed 2 arguments, but takes just 1 /usr/include/c++/3.3/bits/locale_facets.h:209: error: syntax error before `)' token /usr/include/c++/3.3/bits/locale_facets.h:40:1: unterminated #ifndef In file included from /usr/include/c++/3.3/ios:51, from /usr/include/c++/3.3/istream:44, from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/bits/basic_ios.h:36:1: unterminated #ifndef In file included from /usr/include/c++/3.3/istream:44, from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/ios:39:1: unterminated #ifndef In file included from /usr/include/c++/3.3/fstream:45, from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/istream:39:1: unterminated #ifndef In file included from /usr/include/c++/3.3/backward/fstream.h:32, from Loop.cpp:35: /usr/include/c++/3.3/fstream:40:1: unterminated #ifndef In file included from Loop.cpp:35: /usr/include/c++/3.3/backward/fstream.h:28:1: unterminated #ifndef *** Error code 1 Stop in /home/suresh/Trail-NX/nxcomp. ---- 10. End of Make command ouput ---- 11. configure executed successfully ( ./nxcompext/configure ) --- 11. Start of configure Script ----- checking for g++... g++ checking for C++ compiler default output... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for a BSD-compatible install... /usr/bin/install -c checking how to run the C++ preprocessor... g++ -E checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for Cygwin32 environment... no checking for SunOS environment... no checking for FreeBSD environment... yes enabling dynamic linking of PNG library disabling production of debug symbols disabling info output in the log file disabling valgrind memory checker workarounds compiling version 1.4.0 configure: creating ./config.status config.status: creating Makefile --- 11. End of configure Script ----- and then I tried the following command $ make --- 11. Start of MAke Script ----- gcc -c -O3 -I/usr/local/include -DVERSION=\"1.4.0\" -I/usr/X11R6/include -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -D__USE_MALLOC -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -I. -I../nxcomp -I../nx-X11/lib/X11 -I../nx-X11/include -I../nx-X11/programs/Xserver/include Clean.c Clean.c: In function `NXCleanInPlaceImage': Clean.c:681: error: `SA_NOMASK' undeclared (first use in this function) Clean.c:681: error: (Each undeclared identifier is reported only once Clean.c:681: error: for each function it appears in.) *** Error code 1 Stop in /home/suresh/Trail-NX/nxcompext. --- 11. End of MAke Script ----- ######################################################################### The above all steps are done sequentially .. by seeing the above steps and errors can any one help me in this issue. Thanks and Best Regards Suresh From owner-freebsd-arch@FreeBSD.ORG Tue Mar 1 06:44:39 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDBA016A4CE; Tue, 1 Mar 2005 06:44:39 +0000 (GMT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87DB943D60; Tue, 1 Mar 2005 06:44:39 +0000 (GMT) (envelope-from wes@softweyr.com) Received: from zaphod.softweyr.com (cpe-66-75-60-23.san.res.rr.com [66.75.60.23]) by smtp-relay.omnis.com (Postfix) with ESMTP id 8207014077E4; Mon, 28 Feb 2005 22:44:38 -0800 (PST) From: Wes Peters Organization: Softweyr.COM To: obrien@freebsd.org Date: Mon, 28 Feb 2005 22:44:38 -0800 User-Agent: KMail/1.7.2 References: <200502282142.j1SLgvhh067909@repoman.freebsd.org> <20050301041945.GA85655@dragon.nuxi.com> In-Reply-To: <20050301041945.GA85655@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_W9AJCLS/87tB/ON" Message-Id: <200502282244.38877@zaphod.softweyr.com> cc: arch@freebsd.org Subject: Review request (Re: cvs commit: src/sys/i386/i386 machdep.c et al) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 06:44:39 -0000 --Boundary-00=_W9AJCLS/87tB/ON Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 28 February 2005 20:19, David O'Brien wrote: > On Mon, Feb 28, 2005 at 09:42:57PM +0000, Wes Peters wrote: > > wes 2005-02-28 21:42:57 UTC > > FreeBSD src repository > > Modified files: > > sys/i386/i386 machdep.c > > sys/kern kern_mib.c > > sys/sys sysctl.h systm.h > > Log: > > Add a sysctl that records the amount of physical memory in the machine. > > > > Submitted by: Nicko Dehaine > > MFC after: 1 day > > Uh, I hope you will fix the build on all non-i386 platforms before you > MFC. Where were they suppose to get the 'realmem' definition from? I've tested the attached patch on sparc64. Does this look OK for the rest of the arches? I left amd64 out since you have (apparently) already fixed that. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com --Boundary-00=_W9AJCLS/87tB/ON Content-Type: text/x-diff; charset="iso-8859-1"; name="realmem.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="realmem.patch" Index: alpha/alpha/machdep.c =================================================================== RCS file: /ncvs/src/sys/alpha/alpha/machdep.c,v retrieving revision 1.232 diff -u -r1.232 machdep.c --- alpha/alpha/machdep.c 6 Feb 2005 01:55:06 -0000 1.232 +++ alpha/alpha/machdep.c 1 Mar 2005 14:35:38 -0000 @@ -194,6 +194,7 @@ struct msgbuf *msgbufp=0; long Maxmem = 0; +long realmem = 0; long totalphysmem; /* total amount of physical memory in system */ long resvmem; /* amount of memory reserved for PROM */ @@ -250,6 +251,7 @@ #endif printf("real memory = %ld (%ld MB)\n", alpha_ptob(Maxmem), alpha_ptob(Maxmem) / 1048576); + realmem = (long)alpha_ptob(Maxmem); /* * Display any holes after the first chunk of extended memory. Index: ia64/ia64/machdep.c =================================================================== RCS file: /ncvs/src/sys/ia64/ia64/machdep.c,v retrieving revision 1.196 diff -u -r1.196 machdep.c --- ia64/ia64/machdep.c 6 Feb 2005 01:55:07 -0000 1.196 +++ ia64/ia64/machdep.c 1 Mar 2005 14:34:25 -0000 @@ -143,6 +143,7 @@ struct msgbuf *msgbufp=0; long Maxmem = 0; +long realmem = 0; vm_offset_t phys_avail[100]; @@ -246,6 +247,7 @@ #endif printf("real memory = %ld (%ld MB)\n", ia64_ptob(Maxmem), ia64_ptob(Maxmem) / 1048576); + realmem = (long)ia64_ptob(Maxmem); /* * Display any holes after the first chunk of extended memory. Index: pc98/i386/machdep.c =================================================================== RCS file: /ncvs/src/sys/pc98/i386/machdep.c,v retrieving revision 1.353 diff -u -r1.353 machdep.c --- pc98/i386/machdep.c 24 Feb 2005 13:15:05 -0000 1.353 +++ pc98/i386/machdep.c 1 Mar 2005 14:33:52 -0000 @@ -196,6 +196,7 @@ #endif long Maxmem = 0; +long realmem = 0; vm_paddr_t phys_avail[10]; @@ -228,6 +229,8 @@ #endif printf("real memory = %ju (%ju MB)\n", ptoa((uintmax_t)Maxmem), ptoa((uintmax_t)Maxmem) / 1048576); + realmem = (long)ptoa((uintmax_t)Maxmem); + /* * Display any holes after the first chunk of extended memory. */ Index: sparc64/sparc64/machdep.c =================================================================== RCS file: /ncvs/src/sys/sparc64/sparc64/machdep.c,v retrieving revision 1.121 diff -u -r1.121 machdep.c --- sparc64/sparc64/machdep.c 6 Feb 2005 01:55:08 -0000 1.121 +++ sparc64/sparc64/machdep.c 1 Mar 2005 14:33:36 -0000 @@ -118,6 +118,7 @@ int cold = 1; long Maxmem; +long realmem; char pcpu0[PCPU_PAGES * PAGE_SIZE]; struct trapframe frame0; @@ -198,6 +199,7 @@ physsz += sparc64_memreg[i].mr_size; printf("real memory = %lu (%lu MB)\n", physsz, physsz / (1024 * 1024)); + realmem = (long)physsz; vm_ksubmap_init(&kmi); Index: powerpc/powerpc/machdep.c =================================================================== RCS file: /ncvs/src/sys/powerpc/powerpc/machdep.c,v retrieving revision 1.82 diff -u -r1.82 machdep.c --- powerpc/powerpc/machdep.c 6 Feb 2005 01:55:08 -0000 1.82 +++ powerpc/powerpc/machdep.c 1 Mar 2005 14:33:13 -0000 @@ -160,6 +160,7 @@ void asm_panic(char *); long Maxmem = 0; +long realmem = 0; struct pmap ofw_pmap; extern int ofmsr; @@ -197,6 +198,7 @@ #endif printf("real memory = %ld (%ld MB)\n", ptoa(Maxmem), ptoa(Maxmem) / 1048576); + realmem = (long)ptoa(Maxmem); /* * Display any holes after the first chunk of extended memory. --Boundary-00=_W9AJCLS/87tB/ON-- From owner-freebsd-arch@FreeBSD.ORG Tue Mar 1 16:46:35 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C948D16A4CE for ; Tue, 1 Mar 2005 16:46:35 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E5943D1F for ; Tue, 1 Mar 2005 16:46:35 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id j21GkYgb022031 for ; Wed, 2 Mar 2005 01:46:34 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id j21GkYN1022030 for freebsd-arch@freebsd.org; Wed, 2 Mar 2005 01:46:34 +0900 (KST) (envelope-from ssw) Date: Wed, 2 Mar 2005 01:46:34 +0900 From: Sangwoo Shim To: freebsd-arch@freebsd.org Message-ID: <20050301164634.GA21959@neo.redjade.org> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 16:46:35 -0000 Hello. I'm using mpd to have ADSL connection (pppoe) on my machine, (I think most of FreeBSD users do that with mpd, no?) and tracking -CURRENT. But when netgraph ABI changes sometimes, I often forget to recompile mpd and become embarrassed after finding that I cannot connect to the line. If your cron daemon happened to have cvsup'd ports tree in the meanwhile, you should even set up ADSL line by using pppd to fetch newer version of mpd. :-) Mpd is likely to be used by FreeBSD (and might DFBSD) exclusively. So, how about import mpd into the base tree? Is there any stopper to prevent mpd from being included into the tree? Thanks for your attention. Sangwoo Shim From owner-freebsd-arch@FreeBSD.ORG Tue Mar 1 16:50:29 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16F2816A4CE for ; Tue, 1 Mar 2005 16:50:29 +0000 (GMT) Received: from peedub.jennejohn.org (Jb739.j.pppool.de [85.74.183.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C0D643D39 for ; Tue, 1 Mar 2005 16:50:28 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.1/8.11.6) with ESMTP id j21GoI7o018125; Tue, 1 Mar 2005 17:50:22 +0100 (CET) (envelope-from garyj@jennejohn.org) Message-Id: <200503011650.j21GoI7o018125@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Sangwoo Shim In-Reply-To: Message from Sangwoo Shim <20050301164634.GA21959@neo.redjade.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Mar 2005 17:50:18 +0100 From: Gary Jennejohn cc: freebsd-arch@freebsd.org Subject: Re: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 16:50:29 -0000 Sangwoo Shim writes: > Mpd is likely to be used by FreeBSD (and might DFBSD) exclusively. So, how > about import mpd into the base tree? Is there any stopper to prevent mpd from > being included into the tree? > Why? /usr/sbin/ppp supports PPPoE just fine and is already in the base. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org garyj[at]denx.de From owner-freebsd-arch@FreeBSD.ORG Tue Mar 1 17:29:06 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0106316A4CE for ; Tue, 1 Mar 2005 17:29:06 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EF0543D1F for ; Tue, 1 Mar 2005 17:29:05 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j21HT3If061203; Tue, 1 Mar 2005 18:29:03 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Gary Jennejohn From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 01 Mar 2005 17:50:18 +0100." <200503011650.j21GoI7o018125@peedub.jennejohn.org> Date: Tue, 01 Mar 2005 18:29:03 +0100 Message-ID: <61202.1109698143@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: Sangwoo Shim cc: freebsd-arch@freebsd.org Subject: Re: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 17:29:06 -0000 In message <200503011650.j21GoI7o018125@peedub.jennejohn.org>, Gary Jennejohn w rites: > >Sangwoo Shim writes: >> Mpd is likely to be used by FreeBSD (and might DFBSD) exclusively. So, how >> about import mpd into the base tree? Is there any stopper to prevent mpd from >> being included into the tree? >> > >Why? /usr/sbin/ppp supports PPPoE just fine and is already in the base. They should be merged. mpd-netgraph has functionality missing in the ppp in the base system. -- 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. From owner-freebsd-arch@FreeBSD.ORG Tue Mar 1 17:37:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D80A16A4CE for ; Tue, 1 Mar 2005 17:37:34 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06D5943D5C for ; Tue, 1 Mar 2005 17:37:33 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 67D4862D11; Tue, 1 Mar 2005 18:37:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1])958EAC4BF; Tue, 1 Mar 2005 18:37:33 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25870-01; Tue, 1 Mar 2005 18:37:24 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 765E3C4B5; Tue, 1 Mar 2005 18:37:24 +0100 (CET) To: Gary Jennejohn From: Eric Masson In-Reply-To: <200503011650.j21GoI7o018125@peedub.jennejohn.org> (Gary Jennejohn's message of "Tue, 01 Mar 2005 17:50:18 +0100") References: <200503011650.j21GoI7o018125@peedub.jennejohn.org> X-Operating-System: FreeBSD 5.3-STABLE i386 Date: Tue, 01 Mar 2005 18:37:24 +0100 Message-ID: <86wtsr1d4b.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com cc: Sangwoo Shim cc: freebsd-arch@freebsd.org Subject: Re: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 17:37:34 -0000 >>>>> "Gary" == Gary Jennejohn writes: Hi Gary, Gary> Why? /usr/sbin/ppp supports PPPoE just fine and is already in the Gary> base. Maybe because ppp(8) acts as a bottleneck because of kernel/userland switching. Another solution for fast pppoe support would be kernel pppoe as seen in Net/Open. Éric Masson -- Ceci était mon dernier message, quels que soient les messages suivants, je n'y répondrai pas car ce ne sont que des opinions. -+-LH in: GNU-Toutes les opinions sont respectables sauf les votres. -+- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 2 01:09:12 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BD0016A4CE; Wed, 2 Mar 2005 01:09:12 +0000 (GMT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B36B543D54; Wed, 2 Mar 2005 01:09:11 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])j2219AA6029962; Wed, 2 Mar 2005 12:09:10 +1100 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) j22196Mq022041; Wed, 2 Mar 2005 12:09:08 +1100 Date: Wed, 2 Mar 2005 12:09:06 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Wes Peters In-Reply-To: <200502282244.38877@zaphod.softweyr.com> Message-ID: <20050302111650.Q7969@delplex.bde.org> References: <200502282142.j1SLgvhh067909@repoman.freebsd.org> <200502282244.38877@zaphod.softweyr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: arch@FreeBSD.org cc: obrien@FreeBSD.org Subject: Re: Review request (Re: cvs commit: src/sys/i386/i386 machdep.c et al) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 01:09:12 -0000 On Mon, 28 Feb 2005, Wes Peters wrote: > On Monday 28 February 2005 20:19, David O'Brien wrote: >> Uh, I hope you will fix the build on all non-i386 platforms before you >> MFC. Where were they suppose to get the 'realmem' definition from? > > I've tested the attached patch on sparc64. Does this look OK for > the rest of the arches? I left amd64 out since you have (apparently) > already fixed that. % Index: alpha/alpha/machdep.c % =================================================================== % RCS file: /ncvs/src/sys/alpha/alpha/machdep.c,v % retrieving revision 1.232 % diff -u -r1.232 machdep.c % --- alpha/alpha/machdep.c 6 Feb 2005 01:55:06 -0000 1.232 % +++ alpha/alpha/machdep.c 1 Mar 2005 14:35:38 -0000 % @@ -194,6 +194,7 @@ % struct msgbuf *msgbufp=0; % % long Maxmem = 0; % +long realmem = 0; realmem is MI, so its declaration shouldn't be N-tuplicated for N arches. It should be next to the declaration of physmem. Maxmem is the MD variant of this variable. Maxmem is close to being MI too -- you could probably have just used it. % % long totalphysmem; /* total amount of physical memory in system */ % long resvmem; /* amount of memory reserved for PROM */ % @@ -250,6 +251,7 @@ % #endif % printf("real memory = %ld (%ld MB)\n", alpha_ptob(Maxmem), % alpha_ptob(Maxmem) / 1048576); % + realmem = (long)alpha_ptob(Maxmem); There too much duplication here too, but it is harder to untangle. The duplication is almost 2*N times (previously only N times for the printfs). Just one arch (sparc64) has the size not in pages and/or not in a variable "long Maxmem". Otherwise, Maxmem is just as MI as physmem. The patch highlights other gratuitous machine dependencies in exisiting code. ctob() should always be used to convert pages to bytes, except it should have been renamed ptob() when clusters went away 10+ years ago. Some arches use ptoa() which is bogus becaue a size and not an address is wanted here... Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Mar 2 08:10:16 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9826E16A4CE for ; Wed, 2 Mar 2005 08:10:16 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01C5F43D2F for ; Wed, 2 Mar 2005 08:10:16 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id j228AKIe025267; Wed, 2 Mar 2005 17:10:20 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id j228AJd2025266; Wed, 2 Mar 2005 17:10:19 +0900 (KST) (envelope-from ssw) Date: Wed, 2 Mar 2005 17:10:19 +0900 From: Sangwoo Shim To: Poul-Henning Kamp Message-ID: <20050302081019.GA25222@neo.redjade.org> References: <200503011650.j21GoI7o018125@peedub.jennejohn.org> <61202.1109698143@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <61202.1109698143@critter.freebsd.dk> User-Agent: Mutt/1.5.4i cc: Gary Jennejohn cc: freebsd-arch@freebsd.org Subject: Re: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 08:10:16 -0000 On Tue, Mar 01, 2005 at 06:29:03PM +0100, Poul-Henning Kamp wrote: > In message <200503011650.j21GoI7o018125@peedub.jennejohn.org>, Gary Jennejohn w > rites: > > > >Sangwoo Shim writes: > >> Mpd is likely to be used by FreeBSD (and might DFBSD) exclusively. So, how > >> about import mpd into the base tree? Is there any stopper to prevent mpd from > >> being included into the tree? > >> > > > >Why? /usr/sbin/ppp supports PPPoE just fine and is already in the base. > > They should be merged. > > mpd-netgraph has functionality missing in the ppp in the base system. Exactly my opinion. I'm glad to know you think like that! Hmm, I'm curious whether there is any commiter planning mpd import. Will it help someone submit PR about this? Regards, Sangwoo Shim From owner-freebsd-arch@FreeBSD.ORG Wed Mar 2 08:17:31 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C7E216A4CE for ; Wed, 2 Mar 2005 08:17:31 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10D8443D2D for ; Wed, 2 Mar 2005 08:17:31 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 294DC51228; Wed, 2 Mar 2005 00:17:30 -0800 (PST) Date: Wed, 2 Mar 2005 00:17:30 -0800 From: Kris Kennaway To: Sangwoo Shim Message-ID: <20050302081729.GA76106@xor.obsecurity.org> References: <200503011650.j21GoI7o018125@peedub.jennejohn.org> <61202.1109698143@critter.freebsd.dk> <20050302081019.GA25222@neo.redjade.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: <20050302081019.GA25222@neo.redjade.org> User-Agent: Mutt/1.4.2.1i cc: Poul-Henning Kamp cc: Gary Jennejohn cc: freebsd-arch@freebsd.org Subject: Re: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 08:17:31 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 02, 2005 at 05:10:19PM +0900, Sangwoo Shim wrote: > On Tue, Mar 01, 2005 at 06:29:03PM +0100, Poul-Henning Kamp wrote: > > In message <200503011650.j21GoI7o018125@peedub.jennejohn.org>, Gary Jen= nejohn w > > rites: > > > > > >Sangwoo Shim writes: > > >> Mpd is likely to be used by FreeBSD (and might DFBSD) exclusively. S= o, how > > >> about import mpd into the base tree? Is there any stopper to prevent= mpd from > > >> being included into the tree? > > >>=20 > > > > > >Why? /usr/sbin/ppp supports PPPoE just fine and is already in the base. > >=20 > > They should be merged. > >=20 > > mpd-netgraph has functionality missing in the ppp in the base system. >=20 > Exactly my opinion. I'm glad to know you think like that! > Hmm, I'm curious whether there is any commiter planning mpd import. He said 'merged', as in 'combined into one program instead of having two (three, including pppd) separate ppp implementations that do almost the same thing'. Kris --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCJXaZWry0BWjoQKURAmFEAKCyn0Tm+MsGBWpyVxsd0DA03UXLQwCfSG7S VoFIvSW04cBUpkcQxn8J+rI= =ORMT -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 2 08:27:29 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B48316A4CE for ; Wed, 2 Mar 2005 08:27:29 +0000 (GMT) Received: from neo.redjade.org (neo.redjade.org [219.254.21.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A8F43D5D for ; Wed, 2 Mar 2005 08:27:28 +0000 (GMT) (envelope-from ssw@neo.redjade.org) Received: from neo.redjade.org (localhost [127.0.0.1]) by neo.redjade.org (8.13.1/8.13.1) with ESMTP id j228RYYY025365; Wed, 2 Mar 2005 17:27:34 +0900 (KST) (envelope-from ssw@neo.redjade.org) Received: (from ssw@localhost) by neo.redjade.org (8.13.1/8.13.1/Submit) id j228RYWT025364; Wed, 2 Mar 2005 17:27:34 +0900 (KST) (envelope-from ssw) Date: Wed, 2 Mar 2005 17:27:34 +0900 From: Sangwoo Shim To: Kris Kennaway Message-ID: <20050302082734.GA25310@neo.redjade.org> References: <200503011650.j21GoI7o018125@peedub.jennejohn.org> <61202.1109698143@critter.freebsd.dk> <20050302081019.GA25222@neo.redjade.org> <20050302081729.GA76106@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Disposition: inline In-Reply-To: <20050302081729.GA76106@xor.obsecurity.org> User-Agent: Mutt/1.5.4i cc: Poul-Henning Kamp cc: Gary Jennejohn cc: freebsd-arch@freebsd.org Subject: Re: How about import mpd into base system? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2005 08:27:29 -0000 On Wed, Mar 02, 2005 at 12:17:30AM -0800, Kris Kennaway wrote: > On Wed, Mar 02, 2005 at 05:10:19PM +0900, Sangwoo Shim wrote: > > On Tue, Mar 01, 2005 at 06:29:03PM +0100, Poul-Henning Kamp wrote: > > > In message <200503011650.j21GoI7o018125@peedub.jennejohn.org>, Gary Jennejohn w > > > rites: > > > > > > > >Sangwoo Shim writes: > > > >> Mpd is likely to be used by FreeBSD (and might DFBSD) exclusively. So, how > > > >> about import mpd into the base tree? Is there any stopper to prevent mpd from > > > >> being included into the tree? > > > >> > > > > > > > >Why? /usr/sbin/ppp supports PPPoE just fine and is already in the base. > > > > > > They should be merged. > > > > > > mpd-netgraph has functionality missing in the ppp in the base system. > > > > Exactly my opinion. I'm glad to know you think like that! > > Hmm, I'm curious whether there is any commiter planning mpd import. > > He said 'merged', as in 'combined into one program instead of having > two (three, including pppd) separate ppp implementations that do > almost the same thing'. > > Kris Ah, now I'm stand corrected. I should study more English. (sigh) Thanks for clarification. Regards, Sangwoo Shim From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 07:43:18 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A67016A4CE for ; Thu, 3 Mar 2005 07:43:18 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id D506343D55 for ; Thu, 3 Mar 2005 07:43:17 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j237ghC4014878 for ; Thu, 3 Mar 2005 02:42:43 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j237ggmU014877 for arch@FreeBSD.ORG; Thu, 3 Mar 2005 02:42:42 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 3 Mar 2005 02:42:42 -0500 From: David Schultz To: arch@FreeBSD.ORG Message-ID: <20050303074242.GA14699@VARK.MIT.EDU> Mail-Followup-To: arch@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 07:43:18 -0000 Any objections to the idea of removing the feature of swapping out kernel stacks? Unlike disabling UAREA swapping, this has the small downside that it wastes 16K (give or take a power of 2) of wired memory per kernel thread that we would otherwise have swapped out. However, this disadvantage is probably negligible by today's standards, and there are several advantages: 1. David Xu found that some kernel code stores externally-accessible data structures on the stack, then goes to sleep and allows the stack to become swappable. This can result in a kernel panic. 2. We don't know how many instances of the above problem there are. Selectively disabling swapping for the right threads at the right times would decrease maintainability. 3. Thread stack swapping doesn't work very well anymore anyway. KSE introduced the idea that a process could have multiple kernel threads and hence multiple kernel stacks, but the swapper was not taught about this very well. All the threads in a process get swapped out at the same time, and this only happens if all the threads happen to be swappable at the same time. 4. The code isn't well maintained. That's not to say that it doesn't work, but it's conceivable that changes in locking elsewhere might introduce new bugs. What if swapout races with exit() while the latter is trying to kill off the threads in the process, for instance? If there were a bug, it could be very difficult to reproduce and track down. At least for now, I would retain the swapper daemon and its medium-term scheduling feature. (That is, under high load, it could mark some processes as unrunnable, thereby reducing contention and allowing their user space pages to be paged out.) This feature does not add much complexity to other parts of the kernel. If it turns out not to be very useful by itself, it can be removed later, but I'm not as zealous with the axe as phk. ;-) From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 14:12:51 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C64816A4CE for ; Thu, 3 Mar 2005 14:12:51 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 49A7043D48 for ; Thu, 3 Mar 2005 14:12:50 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 93022 invoked by uid 0); 3 Mar 2005 14:11:50 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 3 Mar 2005 14:11:50 -0000 Message-ID: <42271B6A.4070802@gamersimpact.com> Date: Thu, 03 Mar 2005 08:12:58 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <20050303074242.GA14699@VARK.MIT.EDU> In-Reply-To: <20050303074242.GA14699@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:12:51 -0000 David Schultz wrote: > Any objections to the idea of removing the feature of swapping out > kernel stacks? Unlike disabling UAREA swapping, this has the > small downside that it wastes 16K (give or take a power of 2) of > wired memory per kernel thread that we would otherwise have > swapped out. However, this disadvantage is probably negligible by > today's standards, and there are several advantages: I like the idea of fixing a lot of possible panics. However, I don't know if we should nix it completely. Wasting this little memory won't hurt anyone on a contemporary computer. However, our embedded systems folks don't look at memory in the same light, and 16K here or there can begin to really add up in a memory tight architecture. Of course it could be argued that embedded systems probably don't have many threads, many threads that can be swapped, or even swap space in the first place. I guess it's a judgment call that one of our embedded systems engineers could better answer. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 14:37:20 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4452A16A4CE; Thu, 3 Mar 2005 14:37:20 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26CED43D1F; Thu, 3 Mar 2005 14:37:20 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23EbHJ7091654; Thu, 3 Mar 2005 14:37:19 GMT (envelope-from davidxu@freebsd.org) Message-ID: <4227211F.5070505@freebsd.org> Date: Thu, 03 Mar 2005 22:37:19 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <20050303074242.GA14699@VARK.MIT.EDU> <42271B6A.4070802@gamersimpact.com> In-Reply-To: <42271B6A.4070802@gamersimpact.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: David Schultz Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:37:20 -0000 Ryan Sommers wrote: > David Schultz wrote: > >> Any objections to the idea of removing the feature of swapping out >> kernel stacks? Unlike disabling UAREA swapping, this has the >> small downside that it wastes 16K (give or take a power of 2) of >> wired memory per kernel thread that we would otherwise have >> swapped out. However, this disadvantage is probably negligible by >> today's standards, and there are several advantages: > > > I like the idea of fixing a lot of possible panics. However, I don't > know if we should nix it completely. Wasting this little memory won't > hurt anyone on a contemporary computer. However, our embedded systems > folks don't look at memory in the same light, and 16K here or there > can begin to really add up in a memory tight architecture. Of course > it could be argued that embedded systems probably don't have many > threads, many threads that can be swapped, or even swap space in the > first place. > > I guess it's a judgment call that one of our embedded systems > engineers could better answer. > Does your embedded system has swap device ? I have joined some embedded projects in the company, and there is no swap devices at all, no HDD etcs, just a CF card or flash memory card and swap is totally turned off. David Xu From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 14:51:46 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E783616A4CE; Thu, 3 Mar 2005 14:51:46 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 769FE43D3F; Thu, 3 Mar 2005 14:51:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j23ErqQ1004431; Thu, 3 Mar 2005 07:53:52 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <422723FD.6030103@samsco.org> Date: Thu, 03 Mar 2005 07:49:33 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryan Sommers References: <20050303074242.GA14699@VARK.MIT.EDU> <42271B6A.4070802@gamersimpact.com> In-Reply-To: <42271B6A.4070802@gamersimpact.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: arch@freebsd.org cc: David Schultz Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:51:47 -0000 Ryan Sommers wrote: > David Schultz wrote: > >> Any objections to the idea of removing the feature of swapping out >> kernel stacks? Unlike disabling UAREA swapping, this has the >> small downside that it wastes 16K (give or take a power of 2) of >> wired memory per kernel thread that we would otherwise have >> swapped out. However, this disadvantage is probably negligible by >> today's standards, and there are several advantages: > > > I like the idea of fixing a lot of possible panics. However, I don't > know if we should nix it completely. Wasting this little memory won't > hurt anyone on a contemporary computer. However, our embedded systems > folks don't look at memory in the same light, and 16K here or there can > begin to really add up in a memory tight architecture. Of course it > could be argued that embedded systems probably don't have many threads, > many threads that can be swapped, or even swap space in the first place. > > I guess it's a judgment call that one of our embedded systems engineers > could better answer. > Please stop thinking about the process table in terms of what you see on your desktop or laptop. FreeBSD is a whole lot more than that, and we have to keep it in perspective. 16k or 32k might not seem like much, but it really does make a difference when you look at the process workload on a real server and is one of the reasons that FreeBSD has always performed well. Yes, it's hard to get it right, but it's not as hard as David Xu and David Shultz are trying to project it, and it's a worthwhile feature. I formally object to removing this feature, and I heavily encourage the current problem (sigwait) to be fixed and the uninformed FUD to stop. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 14:52:46 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E501516A4CF for ; Thu, 3 Mar 2005 14:52:46 +0000 (GMT) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AFBC43D2F for ; Thu, 3 Mar 2005 14:52:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23267 invoked from network); 3 Mar 2005 14:52:46 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 3 Mar 2005 14:52:45 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j23EqcVX090058; Thu, 3 Mar 2005 09:52:38 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 3 Mar 2005 09:54:07 -0500 User-Agent: KMail/1.6.2 References: <20050303074242.GA14699@VARK.MIT.EDU> In-Reply-To: <20050303074242.GA14699@VARK.MIT.EDU> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503030954.08271.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: David Schultz Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 14:52:47 -0000 On Thursday 03 March 2005 02:42 am, David Schultz wrote: > Any objections to the idea of removing the feature of swapping out > kernel stacks? Unlike disabling UAREA swapping, this has the > small downside that it wastes 16K (give or take a power of 2) of > wired memory per kernel thread that we would otherwise have > swapped out. However, this disadvantage is probably negligible by > today's standards, and there are several advantages: > > 1. David Xu found that some kernel code stores externally-accessible > data structures on the stack, then goes to sleep and allows the > stack to become swappable. This can result in a kernel panic. He found one instance. > 2. We don't know how many instances of the above problem there are. > Selectively disabling swapping for the right threads at the > right times would decrease maintainability. Probably 1. Note that since at least FreeBSD 1.0 programmers have had to realize that the stack can be swapped out. The signal code in pre-5.x stores part of the signal state in struct proc directly in order to support swapped out stacks. In 5.x we just malloc the whole signal state directly since we killed the u-area. sigwait() has a bug that should be fixed, let's not engage in overkill and throw the baby out with the bath water. In general we need to discourage use of stack variables anyway because when people use stack space rather than malloc() space the failure case for running out is much worse, i.e. kernel panic when you overflow your stack (even though KVM may be available) vs. waiting until some memory is available or returning NULL. Hence, don't kill this whole feature just because someone is too lazy to fix a bug. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 15:35:41 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D379E16A4CE; Thu, 3 Mar 2005 15:35:41 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C44843D46; Thu, 3 Mar 2005 15:35:41 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j23FZ5rL017052; Thu, 3 Mar 2005 10:35:05 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j23FZ5ro017051; Thu, 3 Mar 2005 10:35:05 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Thu, 3 Mar 2005 10:35:05 -0500 From: David Schultz To: John Baldwin Message-ID: <20050303153505.GA16964@VARK.MIT.EDU> Mail-Followup-To: John Baldwin , freebsd-arch@FreeBSD.ORG References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503030954.08271.jhb@FreeBSD.org> cc: freebsd-arch@FreeBSD.ORG Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 15:35:42 -0000 On Thu, Mar 03, 2005, John Baldwin wrote: > On Thursday 03 March 2005 02:42 am, David Schultz wrote: > > Any objections to the idea of removing the feature of swapping out > > kernel stacks? Unlike disabling UAREA swapping, this has the > > small downside that it wastes 16K (give or take a power of 2) of > > wired memory per kernel thread that we would otherwise have > > swapped out. However, this disadvantage is probably negligible by > > today's standards, and there are several advantages: > > > > 1. David Xu found that some kernel code stores externally-accessible > > data structures on the stack, then goes to sleep and allows the > > stack to become swappable. This can result in a kernel panic. > > He found one instance. > > > 2. We don't know how many instances of the above problem there are. > > Selectively disabling swapping for the right threads at the > > right times would decrease maintainability. > > Probably 1. Note that since at least FreeBSD 1.0 programmers have had to > realize that the stack can be swapped out. The signal code in pre-5.x stores > part of the signal state in struct proc directly in order to support swapped > out stacks. In 5.x we just malloc the whole signal state directly since we > killed the u-area. sigwait() has a bug that should be fixed, let's not > engage in overkill and throw the baby out with the bath water. In general we > need to discourage use of stack variables anyway because when people use > stack space rather than malloc() space the failure case for running out is > much worse, i.e. kernel panic when you overflow your stack (even though KVM > may be available) vs. waiting until some memory is available or returning > NULL. > > Hence, don't kill this whole feature just because someone is too lazy to fix a > bug. Fair enough. I'll defer to you on the extent of the problem. David seemed to think that it was more widespread. (BTW, does *anyone* know what the PHOLD() in kern_physio is for? Is it a holdover from when the PCB was in struct user?) That still leaves my third point, which is that kernel stack swapping is no longer as effective as it was in 4.X. Resource hogs, particularly multithreaded ones, tend to get passed over by the swapper, so only the well-behaved processes (e.g. interactive ones) tend to get swapped out under high load. I have a WIP that I mentioned to you briefly before that fixes this by doing two things: a) The swapper sets a flag on threads that are unswappable. When I finish this, those threads will swap themselves out the next time they try to enter or exit the kernel. b) Individual threads within a process can be swapped out; they don't all have to be swapped out at the same time. I'm not actually sure if (b) is a good thing to do. For many applications, swapping out one thread will just cause all the others to quickly stall while waiting for it. Thoughts? In any case, I have no time to finish it right now, but assuming I don't get to axe it all, I'll get to finishing it eventually... From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 16:48:12 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C324516A4CE; Thu, 3 Mar 2005 16:48:12 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29C2443D58; Thu, 3 Mar 2005 16:48:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j23Gk7M5010692; Thu, 3 Mar 2005 09:46:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 03 Mar 2005 09:46:30 -0700 (MST) Message-Id: <20050303.094630.46868412.imp@bsdimp.com> To: ryans@gamersimpact.com From: "M. Warner Losh" In-Reply-To: <42271B6A.4070802@gamersimpact.com> References: <20050303074242.GA14699@VARK.MIT.EDU> <42271B6A.4070802@gamersimpact.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: das@freebsd.org Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:48:12 -0000 In message: <42271B6A.4070802@gamersimpact.com> Ryan Sommers writes: : Of course it : could be argued that embedded systems probably don't have many threads, : many threads that can be swapped, or even swap space in the first place. You'd be wrong about the 'embedded systems don't have many threads' part of your statement. Our embedded and semiembedded systems tend to have dozens of the goofy thing. However, you'd be right about the 'no swap space' part. We run without swap. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 16:51:53 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4418A16A4CE for ; Thu, 3 Mar 2005 16:51:53 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id A607643D48 for ; Thu, 3 Mar 2005 16:51:52 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 2585 invoked by uid 89); 3 Mar 2005 16:51:23 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 3 Mar 2005 16:51:23 -0000 Received: (qmail 2463 invoked by uid 89); 3 Mar 2005 16:51:22 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 3 Mar 2005 16:51:22 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j23GpKw6016814; Thu, 3 Mar 2005 11:51:21 -0500 (EST) (envelope-from ups@tree.com) From: Stephan Uphoff To: David Schultz In-Reply-To: <20050303153505.GA16964@VARK.MIT.EDU> References: <20050303074242.GA14699@VARK.MIT.EDU> <20050303153505.GA16964@VARK.MIT.EDU> Content-Type: text/plain Message-Id: <1109868680.56784.17236.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 03 Mar 2005 11:51:20 -0500 Content-Transfer-Encoding: 7bit cc: John Baldwin cc: "freebsd-arch@freebsd.org" Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:51:53 -0000 On Thu, 2005-03-03 at 10:35, David Schultz wrote: > On Thu, Mar 03, 2005, John Baldwin wrote: > > On Thursday 03 March 2005 02:42 am, David Schultz wrote: > > > Any objections to the idea of removing the feature of swapping out > > > kernel stacks? Unlike disabling UAREA swapping, this has the > > > small downside that it wastes 16K (give or take a power of 2) of > > > wired memory per kernel thread that we would otherwise have > > > swapped out. However, this disadvantage is probably negligible by > > > today's standards, and there are several advantages: > > > > > > 1. David Xu found that some kernel code stores externally-accessible > > > data structures on the stack, then goes to sleep and allows the > > > stack to become swappable. This can result in a kernel panic. > > > > He found one instance. > > > > > 2. We don't know how many instances of the above problem there are. > > > Selectively disabling swapping for the right threads at the > > > right times would decrease maintainability. > > > > Probably 1. Note that since at least FreeBSD 1.0 programmers have had to > > realize that the stack can be swapped out. The signal code in pre-5.x stores > > part of the signal state in struct proc directly in order to support swapped > > out stacks. In 5.x we just malloc the whole signal state directly since we > > killed the u-area. sigwait() has a bug that should be fixed, let's not > > engage in overkill and throw the baby out with the bath water. In general we > > need to discourage use of stack variables anyway because when people use > > stack space rather than malloc() space the failure case for running out is > > much worse, i.e. kernel panic when you overflow your stack (even though KVM > > may be available) vs. waiting until some memory is available or returning > > NULL. > > > > Hence, don't kill this whole feature just because someone is too lazy to fix a > > bug. > > Fair enough. I'll defer to you on the extent of the problem. > David seemed to think that it was more widespread. (BTW, does > *anyone* know what the PHOLD() in kern_physio is for? Is it a > holdover from when the PCB was in struct user?) I guess the intend is to avoid swapping out the thread while it holds the pages needed for the I/O. > > That still leaves my third point, which is that kernel stack > swapping is no longer as effective as it was in 4.X. Resource > hogs, particularly multithreaded ones, tend to get passed over by > the swapper, so only the well-behaved processes (e.g. interactive > ones) tend to get swapped out under high load. I have a WIP that > I mentioned to you briefly before that fixes this by doing two > things: > > a) The swapper sets a flag on threads that are unswappable. > When I finish this, those threads will swap themselves out > the next time they try to enter or exit the kernel. > > b) Individual threads within a process can be swapped out; they > don't all have to be swapped out at the same time. > > I'm not actually sure if (b) is a good thing to do. For many > applications, swapping out one thread will just cause all the > others to quickly stall while waiting for it. Thoughts? I think (b) is a good idea - especially for threads on long term sleep in the kernel. Not sure about your stalling scenario. I guess the thing to watch out for is that multi-threaded applications have the same chance to run as single threaded applications. Stalling may even be the right thing to do ;-) > In any case, I have no time to finish it right now, but assuming I > don't get to axe it all, I'll get to finishing it eventually... > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 16:58:26 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A10AA16A4CE; Thu, 3 Mar 2005 16:58:26 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31BEC43D55; Thu, 3 Mar 2005 16:58:26 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j23GwPr8014802; Thu, 3 Mar 2005 08:58:25 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j23GwPUC014801; Thu, 3 Mar 2005 08:58:25 -0800 Date: Thu, 3 Mar 2005 08:58:25 -0800 From: Brooks Davis To: John Baldwin Message-ID: <20050303165825.GB4737@odin.ac.hmc.edu> References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <200503030954.08271.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: David Schultz cc: freebsd-arch@freebsd.org Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:58:26 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 03, 2005 at 09:54:07AM -0500, John Baldwin wrote: > On Thursday 03 March 2005 02:42 am, David Schultz wrote: > > Any objections to the idea of removing the feature of swapping out > > kernel stacks? Unlike disabling UAREA swapping, this has the > > small downside that it wastes 16K (give or take a power of 2) of > > wired memory per kernel thread that we would otherwise have > > swapped out. However, this disadvantage is probably negligible by > > today's standards, and there are several advantages: > > > > 1. David Xu found that some kernel code stores externally-accessible > > data structures on the stack, then goes to sleep and allows the > > stack to become swappable. This can result in a kernel panic. >=20 > He found one instance. >=20 > > 2. We don't know how many instances of the above problem there are. > > Selectively disabling swapping for the right threads at the > > right times would decrease maintainability. >=20 > Probably 1. Note that since at least FreeBSD 1.0 programmers have had to= =20 > realize that the stack can be swapped out. The signal code in pre-5.x st= ores=20 > part of the signal state in struct proc directly in order to support swap= ped=20 > out stacks. In 5.x we just malloc the whole signal state directly since = we=20 > killed the u-area. sigwait() has a bug that should be fixed, let's not= =20 > engage in overkill and throw the baby out with the bath water. In genera= l we=20 > need to discourage use of stack variables anyway because when people use= =20 > stack space rather than malloc() space the failure case for running out i= s=20 > much worse, i.e. kernel panic when you overflow your stack (even though K= VM=20 > may be available) vs. waiting until some memory is available or returning= =20 > NULL. >=20 > Hence, don't kill this whole feature just because someone is too lazy > to fix a bug. It would be very useful and informative if someone were to write a high level description of the ways in which the kernel is not a POSIX C programming environment. In addition to providing somewhere to point people who wonder why -lbigcomplicatedlibrary doesn't work with their kernel source, such a list would force us to enumerate those differences and make sure they are based on design decisions that make sense. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCJ0IxXY6L6fI4GtQRAgK6AJ94dNJWmBRGqdlSTsIYpGDEv4qSwQCfZyiV Qkn4jkSplCvp6PCCZXnRKBY= =Fjes -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 23:29:53 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B75D16A4CE; Thu, 3 Mar 2005 23:29:53 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1371C43D31; Thu, 3 Mar 2005 23:29:53 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23NTm89078083; Thu, 3 Mar 2005 23:29:50 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42279DEF.2030901@freebsd.org> Date: Fri, 04 Mar 2005 07:29:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org> <20050303165825.GB4737@odin.ac.hmc.edu> In-Reply-To: <20050303165825.GB4737@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: David Schultz cc: freebsd-arch@freebsd.org Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 23:29:53 -0000 Brooks Davis wrote: >On Thu, Mar 03, 2005 at 09:54:07AM -0500, John Baldwin wrote: > > >>Hence, don't kill this whole feature just because someone is too lazy >>to fix a bug. >> >> > >It would be very useful and informative if someone were to write a >high level description of the ways in which the kernel is not a POSIX C >programming environment. > when you are importing a POSIX C programmed piece of code into kernel, this will be a problem, I always think problem from another side, not just stand at my side. :) > In addition to providing somewhere to point >people who wonder why -lbigcomplicatedlibrary doesn't work with their >kernel source, such a list would force us to enumerate those differences >and make sure they are based on design decisions that make sense. > >-- Brooks > > > From owner-freebsd-arch@FreeBSD.ORG Fri Mar 4 00:34:26 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C561E16A4CE; Fri, 4 Mar 2005 00:34:26 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2133243D1F; Fri, 4 Mar 2005 00:34:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j240aHFA007283; Thu, 3 Mar 2005 17:36:17 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4227AC82.7000606@samsco.org> Date: Thu, 03 Mar 2005 17:32:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org> <20050303165825.GB4737@odin.ac.hmc.edu> <42279DEF.2030901@freebsd.org> In-Reply-To: <42279DEF.2030901@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: David Schultz cc: freebsd-arch@freebsd.org Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 00:34:26 -0000 David Xu wrote: > Brooks Davis wrote: > >> On Thu, Mar 03, 2005 at 09:54:07AM -0500, John Baldwin wrote: >> >> >>> Hence, don't kill this whole feature just because someone is too lazy >>> to fix a bug. >>> >> >> >> It would be very useful and informative if someone were to write a >> high level description of the ways in which the kernel is not a POSIX C >> programming environment. > > when you are importing a POSIX C programmed piece of code into kernel, > this will be a problem, I always think problem from another side, not just > stand at my side. :) The kernel is not a POSIX C environment. It's not just a program that happens to do special things. I know that Linux goes to great lengths to support this concept, but it's simply not true. Programming in the kernel ideally is not much different from other forms of embedded system programming where resources are finite and expensive and it's the responibility of the programmer to develop efficient and safe code. Scott From owner-freebsd-arch@FreeBSD.ORG Sat Mar 5 09:17:23 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A26DC16A4CE; Sat, 5 Mar 2005 09:17:23 +0000 (GMT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF46643D60; Sat, 5 Mar 2005 09:17:22 +0000 (GMT) SRS0+5c290cbdc9111d424b69+559+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.43 #1 (Red Hat Linux)) id 1D7VPV-0004hv-7G; Sat, 05 Mar 2005 09:17:21 +0000 Date: Sat, 5 Mar 2005 09:17:21 +0000 From: Christoph Hellwig To: Scott Long Message-ID: <20050305091721.GA18089@infradead.org> References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org> <20050303165825.GB4737@odin.ac.hmc.edu> <42279DEF.2030901@freebsd.org> <4227AC82.7000606@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4227AC82.7000606@samsco.org> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html cc: David Schultz cc: David Xu cc: freebsd-arch@freebsd.org Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 09:17:23 -0000 On Thu, Mar 03, 2005 at 05:32:02PM -0700, Scott Long wrote: > The kernel is not a POSIX C environment. It's not just a program that > happens to do special things. I know that Linux goes to great lengths > to support this concept, That's not true at all. The Liux kernel enviroment is very different from normal userland programming and there's not move towards changing that, quite contrary. From owner-freebsd-arch@FreeBSD.ORG Sat Mar 5 18:24:43 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2C7B16A4D0 for ; Sat, 5 Mar 2005 18:24:43 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CEF743D31 for ; Sat, 5 Mar 2005 18:24:43 +0000 (GMT) (envelope-from masjeloc@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1104424wra for ; Sat, 05 Mar 2005 10:24:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=JUXdYlyzONLmE6/mAu29SxiQTkeB5pZxa5/B29w4PePXLYufQ12MChteZGVCR+ECdPyvP9AvywIufIwTBrgofSpk1YmA8IMqI/5aH70n7kIEpnNJzoU+1BI/lV+93SaeKEofsd5bBmoU+f4XmiF1NWMo0M9d+Rkx4i3NhQqpuO4= Received: by 10.54.34.14 with SMTP id h14mr23352wrh; Sat, 05 Mar 2005 10:24:43 -0800 (PST) Received: by 10.54.28.54 with HTTP; Sat, 5 Mar 2005 10:24:42 -0800 (PST) Message-ID: <2b50dc97050305102439f6ffcb@mail.gmail.com> Date: Sat, 5 Mar 2005 09:24:42 -0900 From: Sam Cole To: freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FreeBSD for Macs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sam Cole List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 18:24:44 -0000 Hello, I'm sort of a novice about different types of processors and operating systems other than Windows. Is there a version of FreeBSD that will run on Apple's g4/g5 processors? Thanks! Sam Cole From owner-freebsd-arch@FreeBSD.ORG Sat Mar 5 21:26:45 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E27B16A4CE for ; Sat, 5 Mar 2005 21:26:45 +0000 (GMT) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE6643D1F for ; Sat, 5 Mar 2005 21:26:44 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j25LQgdB013016 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 6 Mar 2005 08:26:42 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j25LQg7l009885; Sun, 6 Mar 2005 08:26:42 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j25LQbY5009884; Sun, 6 Mar 2005 08:26:38 +1100 (EST) (envelope-from pjeremy) Date: Sun, 6 Mar 2005 08:26:37 +1100 From: Peter Jeremy To: Sam Cole Message-ID: <20050305212637.GG4394@cirb503493.alcatel.com.au> References: <2b50dc97050305102439f6ffcb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b50dc97050305102439f6ffcb@mail.gmail.com> User-Agent: Mutt/1.4.2i cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD for Macs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 21:26:45 -0000 On Sat, 2005-Mar-05 09:24:42 -0900, Sam Cole wrote: >I'm sort of a novice about different types of processors and operating >systems other than Windows. Is there a version of FreeBSD that will >run on Apple's g4/g5 processors? There is some work being done in -current (which will be released as FreeBSD 6.x, probably next year) but I'm not sure what state it is in. At this stage, the closest you'll get to FreeBSD on a g4 is Mac OS-X. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Sat Mar 5 22:46:35 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC3816A4CE for ; Sat, 5 Mar 2005 22:46:35 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06E8043D5F for ; Sat, 5 Mar 2005 22:46:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j25MmExL058760; Sat, 5 Mar 2005 15:48:15 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <422A363F.1@samsco.org> Date: Sat, 05 Mar 2005 15:44:15 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <2b50dc97050305102439f6ffcb@mail.gmail.com> <20050305212637.GG4394@cirb503493.alcatel.com.au> In-Reply-To: <20050305212637.GG4394@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Sam Cole cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD for Macs? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 22:46:35 -0000 Peter Jeremy wrote: > On Sat, 2005-Mar-05 09:24:42 -0900, Sam Cole wrote: > >>I'm sort of a novice about different types of processors and operating >>systems other than Windows. Is there a version of FreeBSD that will >>run on Apple's g4/g5 processors? > > > There is some work being done in -current (which will be released as > FreeBSD 6.x, probably next year) but I'm not sure what state it is in. > > At this stage, the closest you'll get to FreeBSD on a g4 is Mac OS-X. > FreeBSD/ppc is actually making good progress. There are instructions for installing a custom build at: http://people.freebsd.org/~grehan/miniinst.txt http://people.freebsd.org/~grehan/miniinst.iso It's not for the faint of heart, and it probably isn't as stable as the other platforms, but it's a good start. Scott