From owner-freebsd-arch@FreeBSD.ORG Sun Apr 17 09:16:00 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 5889B16A4CE for ; Sun, 17 Apr 2005 09:16:00 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10E3943D2D for ; Sun, 17 Apr 2005 09:16:00 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 2A8B34EFCDB; Sun, 17 Apr 2005 17:15:59 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 20B774EFCDA for ; Sun, 17 Apr 2005 17:15:59 +0800 (CST) Date: Sun, 17 Apr 2005 17:15:59 +0800 (CST) From: Tai-hwa Liang To: freebsd-arch@freebsd.org Message-ID: <0504171605563.25609@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Multibyte characters in regression test script? 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, 17 Apr 2005 09:16:00 -0000 I plan to commit a regression test script for msdosfs which contains multibyte characters(to be more specific, create directory name contains Chinese characters on a msdosfs mounted with zh_TW.Big5 locale). I haven't aware that there's any existing policy on using non-ASCII strings in script; however, if that is not acceptable, I would be very appreciate it if someone who familiar with this can shed me some light. -- Cheers, Tai-hwa Liang From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 00:57:01 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 CD50316A4CE; Mon, 18 Apr 2005 00:57:01 +0000 (GMT) Received: from mail.jeamland.net (arlond.jeamland.net [202.45.126.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5371043D58; Mon, 18 Apr 2005 00:57:01 +0000 (GMT) (envelope-from benno@jeamland.net) Received: from localhost (localhost [127.0.0.1]) by mail.jeamland.net (Postfix) with ESMTP id D5464B845; Mon, 18 Apr 2005 10:56:58 +1000 (EST) Received: from mail.jeamland.net ([127.0.0.1]) by localhost (arlond.jeamland.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 89751-03; Mon, 18 Apr 2005 10:56:58 +1000 (EST) Received: from [10.6.2.207] (211.015.dsl.mel.iprimus.net.au [203.134.174.211]) by mail.jeamland.net (Postfix) with ESMTP id 33247B842; Mon, 18 Apr 2005 10:56:58 +1000 (EST) Message-ID: <426305D4.2000505@jeamland.net> Date: Mon, 18 Apr 2005 10:56:52 +1000 From: Benno Rice User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416150810.GD5452@empiric.icir.org> In-Reply-To: <20050416150810.GD5452@empiric.icir.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9935398F99CEE762D059F082" X-Virus-Scanned: by amavisd-new at jeamland.net cc: arch@freebsd.org cc: Harti Brandt Subject: Re: De-orbitting ATM-HARP 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, 18 Apr 2005 00:57:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9935398F99CEE762D059F082 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bruce M Simpson wrote: > On Fri, Apr 15, 2005 at 05:41:57PM +0200, Harti Brandt wrote: > >>While there I would also remove everything from netnatm that is not needed >>by NgATM. This is mainly the socket interface. I'm not aware of any >>application that uses it. Any thoughts on this? > > > Oh. Don't remove that. Userland PPP needs it. People who are using ADSL > modems of any kind will still need it. I concur. I'm working on some ADSL drivers at the moment and there are people wanting to use PPPoA where this is very useful. If userland PPP switches to Netgraph then I'm fine with this going, but until then I'd rather it stayed. -- Benno Rice benno@jeamland.net http://jeamland.net --------------enig9935398F99CEE762D059F082 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCYwXX4u8rkiw+H90RAu3aAJ0Y/x0Wm6ZX4XOTGPyCX23HPTF+uwCfc/PH yggiermr4fo9gC5nxJ6CGxo= =lReb -----END PGP SIGNATURE----- --------------enig9935398F99CEE762D059F082-- From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 07:38: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 E417216A4E3; Mon, 18 Apr 2005 07:38:18 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7936543D41; Mon, 18 Apr 2005 07:38:17 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Apr 2005 09:38:15 +0200 Date: Mon, 18 Apr 2005 09:38:37 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Robert Watson In-Reply-To: <20050416154049.B64125@fledge.watson.org> Message-ID: <20050418093638.B1882@beagle.kn.op.dlr.de> References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416154049.B64125@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 18 Apr 2005 07:38:15.0577 (UTC) FILETIME=[94F9D890:01C543E9] cc: arch@freebsd.org Subject: Re: De-orbitting ATM-HARP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 07:38:20 -0000 On Sat, 16 Apr 2005, Robert Watson wrote: RW> RW>On Fri, 15 Apr 2005, Harti Brandt wrote: RW> RW>> not sure whether this is actually off-topic. Some time ago I asked on RW>> freebsd-atm who would have a problem when we remove HARP (netatm, hfa) from RW>> 6. I got only two or three answers which said 'go for it'. Nobody said that RW>> he would have a problem. So should we do it and when? Perhaps the best time RW>> is before 6.0. That would be in the next two weeks as I understand. RW>> RW>> While there I would also remove everything from netnatm that is not needed RW>> by NgATM. This is mainly the socket interface. I'm not aware of any RW>> application that uses it. Any thoughts on this? RW> RW>One of the concerns I have with the ATM stacks present in the system is that RW>none appears to be MPSAFE. I am currently unable to perform any ATM-related RW>testing, and so don't feel comfortable starting on locking work on the ATM RW>components. If we can remove unused ATM code, that makes the overall task of RW>getting the last bits of the network stack MPSAFE much easier. NgATM is MPSAFE to the extend that netgraph is MPSAFE. The drivers I've written are MPSAFE too to the extend the interface driver framework is MPSAFE (think of calling interface routines while the driver is unloading and so on. There was some discussion about how to fix this, but it's still there). RW>BTW, have you tried pinging freebsd-net? Ok. I'll do that today. harti From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 07:40: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 57FDB16A4CE for ; Mon, 18 Apr 2005 07:40:34 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D4E43D3F for ; Mon, 18 Apr 2005 07:40:33 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Apr 2005 09:40:32 +0200 Date: Mon, 18 Apr 2005 09:40:55 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Bruce M Simpson In-Reply-To: <20050416150810.GD5452@empiric.icir.org> Message-ID: <20050418093938.I1882@beagle.kn.op.dlr.de> References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416150810.GD5452@empiric.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 18 Apr 2005 07:40:32.0674 (UTC) FILETIME=[E6B13020:01C543E9] cc: arch@freebsd.org Subject: Re: De-orbitting ATM-HARP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 07:40:34 -0000 On Sat, 16 Apr 2005, Bruce M Simpson wrote: BMS>On Fri, Apr 15, 2005 at 05:41:57PM +0200, Harti Brandt wrote: BMS>> While there I would also remove everything from netnatm that is not needed BMS>> by NgATM. This is mainly the socket interface. I'm not aware of any BMS>> application that uses it. Any thoughts on this? BMS> BMS>Oh. Don't remove that. Userland PPP needs it. People who are using ADSL BMS>modems of any kind will still need it. Does it really use socket(AF_ATM, ... or socket(AF_NATM, ...? Any chance to convert this to netgraph sockets? harti From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 07:46:17 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 9B65116A4CE for ; Mon, 18 Apr 2005 07:46:17 +0000 (GMT) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE2C843D48 for ; Mon, 18 Apr 2005 07:46:16 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Apr 2005 09:46:15 +0200 Date: Mon, 18 Apr 2005 09:46:39 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Bruce M Simpson In-Reply-To: <20050416211000.GF784@empiric.icir.org> Message-ID: <20050418094356.O1882@beagle.kn.op.dlr.de> References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416150810.GD5452@empiric.icir.org> <86ll7i30mc.fsf@xps.des.no> <20050416211000.GF784@empiric.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 18 Apr 2005 07:46:15.0883 (UTC) FILETIME=[B342B9B0:01C543EA] cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: De-orbitting ATM-HARP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Harti Brandt List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2005 07:46:17 -0000 On Sat, 16 Apr 2005, Bruce M Simpson wrote: BMS>On Sat, Apr 16, 2005 at 10:52:43PM +0200, Dag-Erling Sm?rgrav wrote: BMS>> Uh? PPP uses netgraph, which has its own socket thingy. BMS> BMS>Postscript. It struck my mind that you were possibly thinking of the BMS>netgraph-based, kernel-space implementation of PPP, in particular BMS>the ng_pppoe node. BMS> BMS>This only knows about the PPP-over-Ethernet encapsulation. If someone BMS>were to write the necessary node to support the PPP-over-ATM encapsulation, BMS>then yes, we probably could make NATM go away, but then Netgraph would be BMS>the only means of working with ATM virtual circuits under FreeBSD, which BMS>has debatable merits. Which? BMS>HARP may be old and crufty, NATM is but a small part of it, but it would be BMS>the last piece of ATM code which we have in common with the other BSDs. In BMS>terms of code quality and design, I've found it far nicer to work with than BMS>the equivalent Linux offering. Besides, I think being able to have native BMS>ADSL connectivity on a *BSD machine is a good thing. NATM is NOT part of HARP. We can safely remove HARP without touching NATM. But someone needs to sit down and fix NATM to be MPSAFE. harti BMS>Deprecating NATM for the 6.0 lifetime would affect several users, developers BMS>and committers who are working towards this. I'd be more than happy to see BMS>ng_pppoa go in for 6.0, though. BMS> BMS>[That would be an excellent idea - being able to run MPD on top of ATM would BMS>let us do native xDSL channel bonding on FreeBSD.] BMS> BMS>Just my 2c (about to change back to pence), BMS>BMS BMS> BMS> BMS> From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 15:43:59 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 BC8D016A4CE; Mon, 18 Apr 2005 15:43:59 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B65143D2D; Mon, 18 Apr 2005 15:43:59 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 8AE0C65218; Mon, 18 Apr 2005 16:43:29 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02710-03-7; Mon, 18 Apr 2005 16:43:29 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 21596651EE; Mon, 18 Apr 2005 16:43:25 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 833D462DB; Mon, 18 Apr 2005 08:43:52 -0700 (PDT) Date: Mon, 18 Apr 2005 08:43:52 -0700 From: Bruce M Simpson To: Harti Brandt Message-ID: <20050418154352.GB756@empiric.icir.org> References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416150810.GD5452@empiric.icir.org> <86ll7i30mc.fsf@xps.des.no> <20050416211000.GF784@empiric.icir.org> <20050418094356.O1882@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050418094356.O1882@beagle.kn.op.dlr.de> cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: arch@freebsd.org Subject: Re: De-orbitting ATM-HARP 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, 18 Apr 2005 15:43:59 -0000 On Mon, Apr 18, 2005 at 09:46:39AM +0200, Harti Brandt wrote: > Which? I've begun designing ng_pppoa. I haven't written a Netgraph node before, so that should be interesting. > NATM is NOT part of HARP. We can safely remove HARP without touching NATM. > But someone needs to sit down and fix NATM to be MPSAFE. rwatson has been volunteering to do this, I've offered to test with real hardware. I am about to move continents again so my level of disruption is likely to be high. BMS From owner-freebsd-arch@FreeBSD.ORG Mon Apr 18 15:45: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 B04DD16A4CE; Mon, 18 Apr 2005 15:45:45 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 583F243D41; Mon, 18 Apr 2005 15:45:45 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 746EA651FA; Mon, 18 Apr 2005 16:45:15 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02710-03-12; Mon, 18 Apr 2005 16:45:15 +0100 (BST) Received: from empiric.dek.spc.org (dhcp52.icir.org [192.150.187.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id EDBF2651EE; Mon, 18 Apr 2005 16:45:14 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 580AA62DB; Mon, 18 Apr 2005 08:45:42 -0700 (PDT) Date: Mon, 18 Apr 2005 08:45:42 -0700 From: Bruce M Simpson To: Harti Brandt Message-ID: <20050418154542.GC756@empiric.icir.org> References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416150810.GD5452@empiric.icir.org> <20050418093938.I1882@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050418093938.I1882@beagle.kn.op.dlr.de> cc: freebsd-arch@freebsd.org Subject: Re: De-orbitting ATM-HARP 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, 18 Apr 2005 15:45:45 -0000 On Mon, Apr 18, 2005 at 09:40:55AM +0200, Harti Brandt wrote: > BMS>Oh. Don't remove that. Userland PPP needs it. People who are using ADSL > BMS>modems of any kind will still need it. > Does it really use socket(AF_ATM, ... or socket(AF_NATM, ...? Any chance > to convert this to netgraph sockets? It uses an AF_NATM socket. I believe we probably could do a conversion to use ng_atm quite easily, and for the ATM case that would certainly be desirable, however there are then the issues of making /usr/sbin/ppp dependent on libnetgraph.so, will the original author/maintainer be happy with such a change, and so on. BMS From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 07:22:44 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 E078116A4CE for ; Tue, 19 Apr 2005 07:22:44 +0000 (GMT) Received: from lib-eth.natur.cuni.cz (lib-eth.natur.cuni.cz [195.113.56.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CA9643D54 for ; Tue, 19 Apr 2005 07:22:42 +0000 (GMT) (envelope-from xdavid@lib-eth.natur.cuni.cz) Received: from lib-eth.natur.cuni.cz (lib-eth.natur.cuni.cz [195.113.56.250]) j3J7Merc438397 for ; Tue, 19 Apr 2005 09:22:40 +0200 (MDT) X-Envelope-From: xdavid@lib-eth.natur.cuni.cz X-Envelope-To: Date: Tue, 19 Apr 2005 09:22:40 +0200 (CEST) From: David Komanek To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: designing new freebsd server for amd64 arch 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, 19 Apr 2005 07:22:45 -0000 Hi all, I am trying to design new machine for FreeBSD running on amd64 platform. I already read officially supported hardware list as well as many discussions concerning hardware for FreeBSD. Still I am not quite sure, what to choose as motherboard. I need dual opteron motherboard, which covers (or can be extended by add-on cards) 2x Gb ethernet networking device and scsi raid 5. I read that FreeBSD has problems with asus and msi motherboards, so I decided to use some tyan board. Those with integrated ZCR Adaptec seem to me to be also problematic. What do you suggest based on your experience ? Now I prefer: Tyan Thunder K8WE, S2895A2NRF 2x AMD Opteron 250 Box Adaptec 2130SLP 4x Hitachi 3.5" 73.4 GB (SCSI Ultra 320),10 000 rpm HP DLT 40/80 but I am not sure whether - motherboard's nForce chipsets are well supported on amd64 port of FreeBSD - I can install directly to RAID 5 behind the Adaptec 2130SLP and boot from it without the need of installing on a separate SATA drive (or even old ATA ?) - is it possible to attach the HP DLT drive to the same SCSI controller as the RAID5-configured disks ? - how strong power supply should I use for this or similar configuration ? (I expect at least 500W, but what is your experience) Maybe you will suggest to use completely another motherboard - I am open to it too. Thanks in advance, David Komanek Charles University in Prague Prague, CZ From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 08:01: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 6017D16A4CE for ; Tue, 19 Apr 2005 08:01:45 +0000 (GMT) Received: from ss.eunet.cz (ss.eunet.cz [193.85.228.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4212243D53 for ; Tue, 19 Apr 2005 08:01:44 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from localhost.i.cz (ss.eunet.cz [193.85.228.13]) by ss.eunet.cz (8.13.1/8.13.1) with ESMTP id j3J81cxt000284; Tue, 19 Apr 2005 10:01:39 +0200 (CEST) (envelope-from mime@traveller.cz) From: Michal Mertl To: David Komanek In-Reply-To: References: Content-Type: text/plain Date: Tue, 19 Apr 2005 10:01:37 +0200 Message-Id: <1113897697.633.18.camel@genius2.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: designing new freebsd server for amd64 arch 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, 19 Apr 2005 08:01:45 -0000 David Komanek wrote: > Hi all, > > I am trying to design new machine for FreeBSD running on amd64 platform. I > already read officially supported hardware list as well as many > discussions concerning hardware for FreeBSD. Still I am not quite sure, > what to choose as motherboard. I need dual opteron motherboard, which This is off topic for this list. Better place to ask this question may be freebsd-questions or freebsd-amd64 list. Michal From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 01:08: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 B415D16A4CE for ; Tue, 19 Apr 2005 01:08:29 +0000 (GMT) Received: from hotmail.com (bay19-f25.bay19.hotmail.com [64.4.53.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8346343D48 for ; Tue, 19 Apr 2005 01:08:29 +0000 (GMT) (envelope-from dragonylffly@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Apr 2005 18:08:29 -0700 Message-ID: Received: from 61.187.16.2 by by19fd.bay19.hotmail.msn.com with HTTP; Tue, 19 Apr 2005 01:08:29 GMT X-Originating-IP: [61.187.16.2] X-Originating-Email: [dragonylffly@hotmail.com] X-Sender: dragonylffly@hotmail.com From: "dragonfly dragonfly" To: freebsd-arch@freebsd.org Date: Tue, 19 Apr 2005 09:08:29 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 19 Apr 2005 01:08:29.0415 (UTC) FILETIME=[4C267770:01C5447C] X-Mailman-Approved-At: Tue, 19 Apr 2005 11:53:13 +0000 Subject: How about porting LVS to FreeBSD 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, 19 Apr 2005 01:08:29 -0000 Hi guys, LVS(http://www.linuxvirtualserver.org/) is a widely used server cluster schedule system,which is be included in Linux official kernel 2.4 and 2.6 release. Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version (http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm).It is only a draft release,only to prove that LVS can play happily with FreeBSD:).It support LVS/DR and Round Robin schedule algorithm.It is been in hot developing.Welcome to test it and hope it be useful. Best Regards, Li Wang _________________________________________________________________ 享用世界上最大的电子邮件系统— MSN Hotmail。 http://www.hotmail.com From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 20:00: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 828C316A4CF for ; Tue, 19 Apr 2005 20:00:43 +0000 (GMT) Received: from mail22.syd.optusnet.com.au (mail22.syd.optusnet.com.au [211.29.133.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id 422DC43D41 for ; Tue, 19 Apr 2005 20:00:42 +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]) j3JK0exl005942 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Apr 2005 06:00:40 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3JK0e7l013652; Wed, 20 Apr 2005 06:00:40 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3JK0eN7013651; Wed, 20 Apr 2005 06:00:40 +1000 (EST) (envelope-from pjeremy) Date: Wed, 20 Apr 2005 06:00:39 +1000 From: Peter Jeremy To: dragonfly dragonfly Message-ID: <20050419200039.GA12673@cirb503493.alcatel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD 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, 19 Apr 2005 20:00:45 -0000 On Tue, 2005-Apr-19 09:08:29 +0800, dragonfly dragonfly wrote: > LVS(http://www.linuxvirtualserver.org/) is a widely used server cluster >schedule system,which is be included in Linux official kernel 2.4 and 2.6 >release. > Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version >(http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm). In its current form, this code cannot be technically or legally incorporated into the FreeBSD base. Looking at the legal aspects: LVS is covered by the GPL which is incompatible with the BSD license. This is a significant impediment to LVS being included in the base system. As a minimum, all GPL code must be clearly identified and it must be possible to remove the code from the kernel compilation. Whilst you have segregated some of the code into a kernel module (ipvs), there are still 14 files added or changed in the base kernel. I also note that there are no sources to ipvsadm - which is supplied as a Linux executable. Of the 14 files affecting the base kernel: - 1 includes a copyright statement with no rights statement. This code cannot be legally used since the authors have implicitly retained all rights to the code and it therefore cannot be used by anyone else. - 4 files have no copyright statement, though in at least once case, the comments imply that a GPL copyright statement has been deleted. Again, this code cannot be legally used. - The remaining 9 files are replacements for existing FreeBSD files and include existing copyrights. There is no obvious legal impediment to those files, though studying the changes would be necessary to confirm that. As to the technical issues: The "patch" includes 9 existing files that replace existing files. This is a totally impractical way of supplying code changes. The CVS ID's in those files imply that they come from RELENG_5, possibly 5.3-RELEASE. FreeBSD rules require that all new features must be applied to HEAD (currently 6.x) first. This ensures that: 1) The new features are not lost as FreeBSD moves forward. 2) New, potentially buggy, code is tested in the "development" branch before being added to a "production" branch. The changes to the existing code must be supplied as context or unified diffs to ensure that other changes to the code are not lost. Much of the new code is not style(9) compliant which would also prevent its inclusion into the base system. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 22:15:28 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 0A73716A4CE for ; Tue, 19 Apr 2005 22:15:28 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BABA443D2D for ; Tue, 19 Apr 2005 22:15:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B22467A403; Tue, 19 Apr 2005 15:15:27 -0700 (PDT) Message-ID: <426582FF.9080100@elischer.org> Date: Tue, 19 Apr 2005 15:15:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Jeremy References: <20050419200039.GA12673@cirb503493.alcatel.com.au> In-Reply-To: <20050419200039.GA12673@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: dragonfly dragonfly cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD 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, 19 Apr 2005 22:15:28 -0000 Peter Jeremy wrote: >On Tue, 2005-Apr-19 09:08:29 +0800, dragonfly dragonfly wrote: > > >> LVS(http://www.linuxvirtualserver.org/) is a widely used server cluster >>schedule system,which is be included in Linux official kernel 2.4 and 2.6 >>release. >> Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version >>(http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm). >> >> > >In its current form, this code cannot be technically or legally >incorporated into the FreeBSD base. > > If you look at the website, you'll notice that the person you are talking to is one of the original authors and can therefore assign a a BSD/dual copyright. SO the legal aspects are really just a case of "getting around to doingthe wordsmithing" >Looking at the legal aspects: LVS is covered by the GPL which is >incompatible with the BSD license. This is a significant impediment >to LVS being included in the base system. As a minimum, all GPL code >must be clearly identified and it must be possible to remove the code >from the kernel compilation. > >Whilst you have segregated some of the code into a kernel module >(ipvs), there are still 14 files added or changed in the base kernel. >I also note that there are no sources to ipvsadm - which is supplied >as a Linux executable. > >Of the 14 files affecting the base kernel: >- 1 includes a copyright statement with no rights statement. This code > cannot be legally used since the authors have implicitly retained all > rights to the code and it therefore cannot be used by anyone else. >- 4 files have no copyright statement, though in at least once case, > the comments imply that a GPL copyright statement has been deleted. > Again, this code cannot be legally used. >- The remaining 9 files are replacements for existing FreeBSD files and > include existing copyrights. There is no obvious legal impediment to > those files, though studying the changes would be necessary to > confirm that. > >As to the technical issues: The "patch" includes 9 existing files >that replace existing files. This is a totally impractical way of >supplying code changes. The CVS ID's in those files imply that they >come from RELENG_5, possibly 5.3-RELEASE. FreeBSD rules require that >all new features must be applied to HEAD (currently 6.x) first. This >ensures that: >1) The new features are not lost as FreeBSD moves forward. >2) New, potentially buggy, code is tested in the "development" branch > before being added to a "production" branch. >The changes to the existing code must be supplied as context or >unified diffs to ensure that other changes to the code are not lost. >Much of the new code is not style(9) compliant which would also prevent >its inclusion into the base system. > > > From owner-freebsd-arch@FreeBSD.ORG Tue Apr 19 22:19:30 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 7522816A4CE for ; Tue, 19 Apr 2005 22:19:30 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3959C43D1F for ; Tue, 19 Apr 2005 22:19:30 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 325237A425; Tue, 19 Apr 2005 15:19:30 -0700 (PDT) Message-ID: <426583F2.7040104@elischer.org> Date: Tue, 19 Apr 2005 15:19:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <20050419200039.GA12673@cirb503493.alcatel.com.au> <426582FF.9080100@elischer.org> In-Reply-To: <426582FF.9080100@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Peter Jeremy cc: dragonfly dragonfly cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD 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, 19 Apr 2005 22:19:30 -0000 Julian Elischer wrote: > > > Peter Jeremy wrote: > >> On Tue, 2005-Apr-19 09:08:29 +0800, dragonfly dragonfly wrote: >> >> >>> LVS(http://www.linuxvirtualserver.org/) is a widely used server >>> cluster schedule system,which is be included in Linux official >>> kernel 2.4 and 2.6 release. >>> Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version >>> (http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm). >>> >> >> >> In its current form, this code cannot be technically or legally >> incorporated into the FreeBSD base. >> >> > > If you look at the website, you'll notice that the person you are > talking to is one of the > original authors and can therefore assign a a BSD/dual copyright. SO > the legal > aspects are really just a case of "getting around to doingthe > wordsmithing" sorry ignore this email > >> Looking at the legal aspects: LVS is covered by the GPL which is >> incompatible with the BSD license. This is a significant impediment >> to LVS being included in the base system. As a minimum, all GPL code >> must be clearly identified and it must be possible to remove the code >> from the kernel compilation. >> >> Whilst you have segregated some of the code into a kernel module >> (ipvs), there are still 14 files added or changed in the base kernel. >> I also note that there are no sources to ipvsadm - which is supplied >> as a Linux executable. >> >> Of the 14 files affecting the base kernel: >> - 1 includes a copyright statement with no rights statement. This code >> cannot be legally used since the authors have implicitly retained all >> rights to the code and it therefore cannot be used by anyone else. >> - 4 files have no copyright statement, though in at least once case, >> the comments imply that a GPL copyright statement has been deleted. >> Again, this code cannot be legally used. >> - The remaining 9 files are replacements for existing FreeBSD files and >> include existing copyrights. There is no obvious legal impediment to >> those files, though studying the changes would be necessary to >> confirm that. >> >> As to the technical issues: The "patch" includes 9 existing files >> that replace existing files. This is a totally impractical way of >> supplying code changes. The CVS ID's in those files imply that they >> come from RELENG_5, possibly 5.3-RELEASE. FreeBSD rules require that >> all new features must be applied to HEAD (currently 6.x) first. This >> ensures that: >> 1) The new features are not lost as FreeBSD moves forward. >> 2) New, potentially buggy, code is tested in the "development" branch >> before being added to a "production" branch. >> The changes to the existing code must be supplied as context or >> unified diffs to ensure that other changes to the code are not lost. >> Much of the new code is not style(9) compliant which would also prevent >> its inclusion into the base system. >> >> >> > From owner-freebsd-arch@FreeBSD.ORG Wed Apr 20 00:55: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 1BD5116A4CE for ; Wed, 20 Apr 2005 00:55:18 +0000 (GMT) Received: from hotmail.com (bay19-f36.bay19.hotmail.com [64.4.53.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEB7343D4C for ; Wed, 20 Apr 2005 00:55:17 +0000 (GMT) (envelope-from dragonylffly@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 19 Apr 2005 17:55:17 -0700 Message-ID: Received: from 61.187.16.2 by by19fd.bay19.hotmail.msn.com with HTTP; Wed, 20 Apr 2005 00:55:17 GMT X-Originating-IP: [61.187.16.2] X-Originating-Email: [dragonylffly@hotmail.com] X-Sender: dragonylffly@hotmail.com In-Reply-To: <20050419200039.GA12673@cirb503493.alcatel.com.au> From: "dragonfly dragonfly" To: PeterJeremy@optushome.com.au Date: Wed, 20 Apr 2005 08:55:17 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 20 Apr 2005 00:55:17.0453 (UTC) FILETIME=[9E8467D0:01C54543] cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD 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, 20 Apr 2005 00:55:18 -0000 Hi, Yeah,currently it is only a very draft release.My meaning is to see whether it is useful.So I only construct a framework to make it run first.I only use Linux compatibility to simplify the implementation,so no ipvsadm sources,I will rewrite it later to fit in the FreeBSD API,and will remove all unnecessary patches,such as linux_list.h,linux_kernel.h etc.My goal is to make it totally independent to the Linux Compability codes.make it a absolute kernel modules,no need kernel patches.With developing,All those problems won't be problems:). Best Regards, Li Wang >From: Peter Jeremy >To: dragonfly dragonfly >CC: freebsd-arch@freebsd.org >Subject: Re: How about porting LVS to FreeBSD >Date: Wed, 20 Apr 2005 06:00:39 +1000 > >On Tue, 2005-Apr-19 09:08:29 +0800, dragonfly dragonfly wrote: > > LVS(http://www.linuxvirtualserver.org/) is a widely used server cluster > >schedule system,which is be included in Linux official kernel 2.4 and 2.6 > >release. > > Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version > >(http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm). > >In its current form, this code cannot be technically or legally >incorporated into the FreeBSD base. > >Looking at the legal aspects: LVS is covered by the GPL which is >incompatible with the BSD license. This is a significant impediment >to LVS being included in the base system. As a minimum, all GPL code >must be clearly identified and it must be possible to remove the code >from the kernel compilation. > >Whilst you have segregated some of the code into a kernel module >(ipvs), there are still 14 files added or changed in the base kernel. >I also note that there are no sources to ipvsadm - which is supplied >as a Linux executable. > >Of the 14 files affecting the base kernel: >- 1 includes a copyright statement with no rights statement. This code > cannot be legally used since the authors have implicitly retained all > rights to the code and it therefore cannot be used by anyone else. >- 4 files have no copyright statement, though in at least once case, > the comments imply that a GPL copyright statement has been deleted. > Again, this code cannot be legally used. >- The remaining 9 files are replacements for existing FreeBSD files and > include existing copyrights. There is no obvious legal impediment to > those files, though studying the changes would be necessary to > confirm that. > >As to the technical issues: The "patch" includes 9 existing files >that replace existing files. This is a totally impractical way of >supplying code changes. The CVS ID's in those files imply that they >come from RELENG_5, possibly 5.3-RELEASE. FreeBSD rules require that >all new features must be applied to HEAD (currently 6.x) first. This >ensures that: >1) The new features are not lost as FreeBSD moves forward. >2) New, potentially buggy, code is tested in the "development" branch > before being added to a "production" branch. >The changes to the existing code must be supplied as context or >unified diffs to ensure that other changes to the code are not lost. >Much of the new code is not style(9) compliant which would also prevent >its inclusion into the base system. > >-- >Peter Jeremy _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/ From owner-freebsd-arch@FreeBSD.ORG Thu Apr 21 02:01: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 31DA616A4CE for ; Thu, 21 Apr 2005 02:01:20 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C099F43D31 for ; Thu, 21 Apr 2005 02:01:18 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j3L1xjuK015873 for ; Thu, 21 Apr 2005 11:29:45 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 21 Apr 2005 11:31:11 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j3L1wW026976 for ; Thu, 21 Apr 2005 11:28:33 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HC90NNPL; Thu, 21 Apr 2005 11:28:24 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j3L22FkN028109 for ; Thu, 21 Apr 2005 11:32:15 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j3L22F08028108 for arch@freebsd.org; Thu, 21 Apr 2005 11:32:15 +0930 (CST) (envelope-from wilkinsa) Date: Thu, 21 Apr 2005 11:32:14 +0930 From: "Wilkinson, Alex" To: arch@freebsd.org Message-ID: <20050421020214.GU27439@squash.dsto.defence.gov.au> Mail-Followup-To: arch@freebsd.org References: <20050415173711.I658@beagle.kn.op.dlr.de> <20050416150810.GD5452@empiric.icir.org> <86ll7i30mc.fsf@xps.des.no> <20050416211000.GF784@empiric.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20050416211000.GF784@empiric.icir.org> User-Agent: Mutt/1.5.6i Subject: Re: De-orbitting ATM-HARP 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, 21 Apr 2005 02:01:20 -0000 0n Sat, Apr 16, 2005 at 02:10:00PM -0700, Bruce M Simpson wrote: >In terms of code quality and design, I've found it far nicer to work with than >the equivalent Linux offering. Besides, I think being able to have native >ADSL connectivity on a *BSD machine is a good thing. > >Deprecating NATM for the 6.0 lifetime would affect several users, developers >and committers who are working towards this. I'd be more than happy to see >ng_pppoa go in for 6.0, though. > >[That would be an excellent idea - being able to run MPD on top of ATM would >let us do native xDSL channel bonding on FreeBSD.] Bruce what exactly do u mean by "native ADSL connectivity" ? - aW From owner-freebsd-arch@FreeBSD.ORG Thu Apr 21 07:54: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 DFAC116A4CE for ; Thu, 21 Apr 2005 07:54:52 +0000 (GMT) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38DB343D55 for ; Thu, 21 Apr 2005 07:54:52 +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]) j3L7snS6014844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 21 Apr 2005 17:54:50 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j3L7sn7l015733; Thu, 21 Apr 2005 17:54:49 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j3L7snun015732; Thu, 21 Apr 2005 17:54:49 +1000 (EST) (envelope-from pjeremy) Date: Thu, 21 Apr 2005 17:54:49 +1000 From: Peter Jeremy To: dragonfly dragonfly Message-ID: <20050421075449.GE12673@cirb503493.alcatel.com.au> References: <20050419200039.GA12673@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD 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, 21 Apr 2005 07:54:53 -0000 On Wed, 2005-Apr-20 08:55:17 +0800, dragonfly dragonfly wrote: >My meaning is to see whether it is useful. I think it is. I work with applications at work that run on HP TruCluster and I can see the advantages of using clustering to building HA servers. I may even have an application for it (though I'll need to study it in more details to confirm that). >So I only construct a framework to make it run first. It would be preferable if the kernel changes were distributed as diffs rather than replacement files - that would make it much easier to identify the changes. >My goal is to make it totally independent >to the Linux Compability codes.make it a absolute kernel modules,no need >kernel patches. Good. If we can resolve the licensing issues, this looks good. -- Peter Jeremy From owner-freebsd-arch@FreeBSD.ORG Thu Apr 21 09:35:05 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 A681A16A4CE for ; Thu, 21 Apr 2005 09:35:05 +0000 (GMT) Received: from lib-eth.natur.cuni.cz (lib-eth.natur.cuni.cz [195.113.56.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA68643D5D for ; Thu, 21 Apr 2005 09:35:04 +0000 (GMT) (envelope-from xdavid@lib-eth.natur.cuni.cz) Received: from lib-eth.natur.cuni.cz (lib-eth.natur.cuni.cz [195.113.56.250]) j3L9Z3AS475636 for ; Thu, 21 Apr 2005 11:35:04 +0200 (MDT) X-Envelope-From: xdavid@lib-eth.natur.cuni.cz X-Envelope-To: Date: Thu, 21 Apr 2005 11:35:03 +0200 (CEST) From: David Komanek To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: designing new freebsd server for amd64 arch 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, 21 Apr 2005 09:35:05 -0000 Thanks to all who responded. It seems amd64 architecture has still relatively big problems by the motherboards' manufacturers. I will try do the best regarding your advices and opinions. Sincerely, David Komanek From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 08:52: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 3CBBD16A4CE for ; Fri, 22 Apr 2005 08:52:41 +0000 (GMT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F75F43D2F for ; Fri, 22 Apr 2005 08:52:40 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 8E3EB31787E; Fri, 22 Apr 2005 10:52:38 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id C11E8405B; Fri, 22 Apr 2005 10:51:56 +0200 (CEST) Date: Fri, 22 Apr 2005 10:51:56 +0200 From: Jeremie Le Hen To: dragonfly dragonfly Message-ID: <20050422085156.GQ91329@obiwan.tataz.chchile.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i cc: freebsd-arch@freebsd.org Subject: Re: How about porting LVS to FreeBSD 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, 22 Apr 2005 08:52:41 -0000 Hi, > LVS(http://www.linuxvirtualserver.org/) is a widely used server cluster > schedule system,which is be included in Linux official kernel 2.4 and 2.6 > release. > Recently i ported LVS/ipvs to FreeBSD,and released 0.1.0 version > (http://dragon.linux-vs.org/~dragonfly/htm/lvs_freebsd.htm).It is only a > draft release,only to prove that LVS can play happily with FreeBSD:).It > support LVS/DR and Round Robin schedule algorithm.It is been in hot > developing.Welcome to test it and hope it be useful. This is very interesting, thank you. I know that LVS uses keepalived(8) to do VRRP and although I must admit it is very useful and powerful, this daemon is IMHO a great mess. (For the short story, the release process is awful, not to say inexistant. Indeed, I use keepalived 1.1.7 at work and this version has an annoying bug for us but we found an acceptable workaround. New versions has been released since, but when 1.1.8 was out, there have been numerous new bugs introduced that needed the version 1.1.9 to be quickly released to correct them. But this version has in turn introduced new bugs and finally version 1.1.10 fixed everything IIRC. Now the version is 1.1.11, but I'm still waiting to jump to this version as I'm afraid to come across new bugs for which I won't find an acceptable workaround.) What I want to know is if you are planning to simply port keepalived(8) to FreeBSD or use the BSD flavoured replacement for VRRP : CARP. I'm convinced this is not a trivial job as keepalived(8) is also used as a ISO level 7 health-checker. AFAIK, VRRP is completely implemented in userland on Linux as the RFC requires to use a special MAC address for the clustered IP but the Linux kernel doesn't support to have more than one MAC address for an interface. Instead, MAC address spoofing is achieved by keepalived(8), by sending gratuitous ARP requests. I think the health-checker part is interesting in keepalived(8) but it would be nice to have the HA mechanic handled by CARP (or maybe using UCARP [1] would be easier, since it's in userland too). I'll try to look at this today. Thanks again for your work. Regards, [1] http://www.ucarp.org/ -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 17:33: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 A4F2616A4D4 for ; Fri, 22 Apr 2005 17:33:06 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 562DD43D55 for ; Fri, 22 Apr 2005 17:33:06 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 416DC72DDB; Fri, 22 Apr 2005 10:33:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3C9F572DD4 for ; Fri, 22 Apr 2005 10:33:06 -0700 (PDT) Date: Fri, 22 Apr 2005 10:33:06 -0700 (PDT) From: Doug White To: freebsd-arch@freebsd.org Message-ID: <20050422103141.F5855@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: libpthread version bump 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, 22 Apr 2005 17:33:06 -0000 Hey folks, The recent changes to implement the the %fs/%gs manipulation syscalls has created a problem for 5.x compatibility. While libc has been bumped for 6.x already, libpthread hasn't, so running 5.x apps on -CURRENT ends up with the app pulling in the old libc correctly, but it pulls in the current libpthread which depends on the new libc and the linker errors out on the missing symbols. I think we need to bump libpthread's version to allow for compatibility in 6. Then we can ship the old libpthread along with the old libc and the Right Thing happens. As it is now people have to recompile any libpthread consumer. Another option is to create a hacked compatibility libc.so.5 that implements the new syscalls. This is logistically difficult but doable if just shipping the old libs isn't good enough. (I don't know the details of the fs/gs handling, but I know it has something to do with TLS. If we want to keep TLS working from 5.x this may be what we need to do.) Comments? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 17:42: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 4F12716A4CE for ; Fri, 22 Apr 2005 17:42:10 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1375C43D48 for ; Fri, 22 Apr 2005 17:42:10 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3MHg9AW097994; Fri, 22 Apr 2005 10:42:09 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3MHg9e4097993; Fri, 22 Apr 2005 10:42:09 -0700 (PDT) (envelope-from sgk) Date: Fri, 22 Apr 2005 10:42:09 -0700 From: Steve Kargl To: Doug White Message-ID: <20050422174209.GA97721@troutmask.apl.washington.edu> References: <20050422103141.F5855@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050422103141.F5855@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 17:42:10 -0000 On Fri, Apr 22, 2005 at 10:33:06AM -0700, Doug White wrote: > > I think we need to bump libpthread's version to allow for compatibility in > 6. Then we can ship the old libpthread along with the old libc and the > Right Thing happens. I certainly agree that we should bump the library if needed. > > As it is now people have to recompile any libpthread consumer. > A workaround may be the use of libmap.conf to map libc.so.5 to libc.so.6. -- Steve From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 17:48: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 D137416A4CE; Fri, 22 Apr 2005 17:48:51 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25C3943D4C; Fri, 22 Apr 2005 17:48:49 +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 j3MHoOwn002026; Fri, 22 Apr 2005 11:50:24 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42693837.7090400@samsco.org> Date: Fri, 22 Apr 2005 11:45:27 -0600 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: Steve Kargl , peter@freebsd.org References: <20050422103141.F5855@carver.gumbysoft.com> <20050422174209.GA97721@troutmask.apl.washington.edu> In-Reply-To: <20050422174209.GA97721@troutmask.apl.washington.edu> 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: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 17:48:51 -0000 Steve Kargl wrote: > On Fri, Apr 22, 2005 at 10:33:06AM -0700, Doug White wrote: > >>I think we need to bump libpthread's version to allow for compatibility in >>6. Then we can ship the old libpthread along with the old libc and the >>Right Thing happens. > > > I certainly agree that we should bump the library if needed. > On more thought, I'm not so sure. The incompatibility arose because of a change in the kernel ABI with the fs and gs CPU selectors. Will just running the old libc and libpthread work with a new kernel that has this ABI change? We might need to create a special compat libc.so.5 that understands the new ABI and provides the appropriate functions to libpthread. What a mess; Peter's changes to the selectors was the right thing to do, but now we are left with the hard questions of compatibility. Peter? > >>As it is now people have to recompile any libpthread consumer. >> > > > A workaround may be the use of libmap.conf to map libc.so.5 > to libc.so.6. > Well, we are talking about formally ensuring that 5.x compatibility works for 6.0 when it's released. Telling users to do a hack with libmap doesn't really match what we need. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 18:22: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 F287316A4CF for ; Fri, 22 Apr 2005 18:22:15 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 968A543D48 for ; Fri, 22 Apr 2005 18:22:15 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3MIMEQl003841; Fri, 22 Apr 2005 14:22:14 -0400 (EDT) Date: Fri, 22 Apr 2005 14:22:14 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Doug White In-Reply-To: <20050422103141.F5855@carver.gumbysoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 18:22:16 -0000 On Fri, 22 Apr 2005, Doug White wrote: > Hey folks, > > The recent changes to implement the the %fs/%gs manipulation syscalls has > created a problem for 5.x compatibility. While libc has been bumped for > 6.x already, libpthread hasn't, so running 5.x apps on -CURRENT ends up > with the app pulling in the old libc correctly, but it pulls in the > current libpthread which depends on the new libc and the linker errors out > on the missing symbols. > > I think we need to bump libpthread's version to allow for compatibility in > 6. Then we can ship the old libpthread along with the old libc and the > Right Thing happens. I wish someone would work on getting symbol versioning working so we don't have to keep bumping library versions for things like this :-) -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 18:27:27 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 CF1EF16A4CE; Fri, 22 Apr 2005 18:27:27 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id A715243D39; Fri, 22 Apr 2005 18:27:27 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j3MIRRSO002833; Fri, 22 Apr 2005 11:27:27 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j3MIRRgb002832; Fri, 22 Apr 2005 11:27:27 -0700 (PDT) (envelope-from sgk) Date: Fri, 22 Apr 2005 11:27:27 -0700 From: Steve Kargl To: Scott Long Message-ID: <20050422182727.GA2753@troutmask.apl.washington.edu> References: <20050422103141.F5855@carver.gumbysoft.com> <20050422174209.GA97721@troutmask.apl.washington.edu> <42693837.7090400@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42693837.7090400@samsco.org> User-Agent: Mutt/1.4.2.1i cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 18:27:27 -0000 On Fri, Apr 22, 2005 at 11:45:27AM -0600, Scott Long wrote: > Steve Kargl wrote: > > > >A workaround may be the use of libmap.conf to map libc.so.5 > >to libc.so.6. > > > > Well, we are talking about formally ensuring that 5.x compatibility > works for 6.0 when it's released. Telling users to do a hack with > libmap doesn't really match what we need. > Having lived through the std{io,err,out} libc snafu, the libm.so.2 snafu, and now the libc.so.5/libpthread.so.1 problem, I will once again suggest that *ALL* library version numbers should be bumped when a new branch is created. Yes, the above suggestion is a hack workaround, but I know that it works for me with one commercial application that I can't simply recompile. -- Steve From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 19:16:40 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 1500916A4CE; Fri, 22 Apr 2005 19:16:40 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6D4B43D31; Fri, 22 Apr 2005 19:16:39 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3MJE8am043347; Fri, 22 Apr 2005 13:14:08 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Apr 2005 13:14:08 -0600 (MDT) Message-Id: <20050422.131408.39194704.imp@bsdimp.com> To: deischen@freebsd.org From: Warner Losh In-Reply-To: References: <20050422103141.F5855@carver.gumbysoft.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: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 19:16:40 -0000 > > The recent changes to implement the the %fs/%gs manipulation syscalls has > > created a problem for 5.x compatibility. While libc has been bumped for > > 6.x already, libpthread hasn't, so running 5.x apps on -CURRENT ends up > > with the app pulling in the old libc correctly, but it pulls in the > > current libpthread which depends on the new libc and the linker errors out > > on the missing symbols. > > > > I think we need to bump libpthread's version to allow for compatibility in > > 6. Then we can ship the old libpthread along with the old libc and the > > Right Thing happens. > > I wish someone would work on getting symbol versioning working > so we don't have to keep bumping library versions for things > like this :-) Symbol versioning wouldn't help this case... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 19:16:42 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 D34C916A4E4; Fri, 22 Apr 2005 19:16:42 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 609CB43D54; Fri, 22 Apr 2005 19:16:42 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3MJFY60043352; Fri, 22 Apr 2005 13:15:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 22 Apr 2005 13:15:34 -0600 (MDT) Message-Id: <20050422.131534.59696216.imp@bsdimp.com> To: sgk@troutmask.apl.washington.edu From: Warner Losh In-Reply-To: <20050422182727.GA2753@troutmask.apl.washington.edu> References: <20050422174209.GA97721@troutmask.apl.washington.edu> <42693837.7090400@samsco.org> <20050422182727.GA2753@troutmask.apl.washington.edu> 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: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 19:16:43 -0000 > Having lived through the std{io,err,out} libc snafu, the > libm.so.2 snafu, and now the libc.so.5/libpthread.so.1 > problem, I will once again suggest that *ALL* library > version numbers should be bumped when a new branch is > created. Yes. When a library version is bumped, *ALL* libraries that depend on it need to be bumped. Sadly, this has proven to be too difficult because it would create an unholy maintanence problem for the ports. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 19:20:28 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 7590016A4CE; Fri, 22 Apr 2005 19:20:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42C7343D54; Fri, 22 Apr 2005 19:20:27 +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 j3MJLuWT002595; Fri, 22 Apr 2005 13:21:56 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42694DAC.5090505@samsco.org> Date: Fri, 22 Apr 2005 13:17:00 -0600 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: Warner Losh References: <20050422174209.GA97721@troutmask.apl.washington.edu> <42693837.7090400@samsco.org> <20050422182727.GA2753@troutmask.apl.washington.edu> <20050422.131534.59696216.imp@bsdimp.com> In-Reply-To: <20050422.131534.59696216.imp@bsdimp.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: peter@freebsd.org cc: sgk@troutmask.apl.washington.edu cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 19:20:28 -0000 Warner Losh wrote: >>Having lived through the std{io,err,out} libc snafu, the >>libm.so.2 snafu, and now the libc.so.5/libpthread.so.1 >>problem, I will once again suggest that *ALL* library >>version numbers should be bumped when a new branch is >>created. > > > Yes. When a library version is bumped, *ALL* libraries that depend on > it need to be bumped. Sadly, this has proven to be too difficult > because it would create an unholy maintanence problem for the ports. > > Warner Well, there is indeed a problem at the moment of libc being bumped for 6-current but not libpthread. However, I think that the particular problem with the fs/gs change goes above and beyond this problem. So, we have about 2 months to sort this all out. Any volunteers? Scott From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 19:48: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 744E116A4CE; Fri, 22 Apr 2005 19:48:52 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5A3343D48; Fri, 22 Apr 2005 19:48:51 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3MJmjkp024204; Fri, 22 Apr 2005 15:48:45 -0400 (EDT) Date: Fri, 22 Apr 2005 15:48:45 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <42694DAC.5090505@samsco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 19:48:52 -0000 On Fri, 22 Apr 2005, Scott Long wrote: > Warner Losh wrote: > >>Having lived through the std{io,err,out} libc snafu, the > >>libm.so.2 snafu, and now the libc.so.5/libpthread.so.1 > >>problem, I will once again suggest that *ALL* library > >>version numbers should be bumped when a new branch is > >>created. > > > > > > Yes. When a library version is bumped, *ALL* libraries that depend on > > it need to be bumped. Sadly, this has proven to be too difficult > > because it would create an unholy maintanence problem for the ports. > > > > Warner > > Well, there is indeed a problem at the moment of libc being bumped for > 6-current but not libpthread. However, I think that the particular > problem with the fs/gs change goes above and beyond this problem. So, > we have about 2 months to sort this all out. Any volunteers? I'm not sure I fully understand the problem, but can't you just make libpthread avoid using *setbase() if the symbol isn't available and use the ldt functions as a fallback? #pragma weak i386_get_gsbase static void *have_gsbase = i386_get_gsbase; ... if (have_gsbase == NULL) { /* use ldt stuff */ } else { /* use i386_get_gsbase */ } You just need something else to force the symbol i386_get_gsbase to be loaded; the #pragma weak won't force it to be loaded even if it is present. -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 19:51:14 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 462D216A4CE; Fri, 22 Apr 2005 19:51:14 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCB4A43D55; Fri, 22 Apr 2005 19:51:13 +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 j3MJqUru002755; Fri, 22 Apr 2005 13:52:30 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <426954D6.1080704@samsco.org> Date: Fri, 22 Apr 2005 13:47:34 -0600 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: Daniel Eischen , peter@freebsd.org References: In-Reply-To: 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: sgk@troutmask.apl.washington.edu cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 19:51:14 -0000 Daniel Eischen wrote: > On Fri, 22 Apr 2005, Scott Long wrote: > > >>Warner Losh wrote: >> >>>>Having lived through the std{io,err,out} libc snafu, the >>>>libm.so.2 snafu, and now the libc.so.5/libpthread.so.1 >>>>problem, I will once again suggest that *ALL* library >>>>version numbers should be bumped when a new branch is >>>>created. >>> >>> >>>Yes. When a library version is bumped, *ALL* libraries that depend on >>>it need to be bumped. Sadly, this has proven to be too difficult >>>because it would create an unholy maintanence problem for the ports. >>> >>>Warner >> >>Well, there is indeed a problem at the moment of libc being bumped for >>6-current but not libpthread. However, I think that the particular >>problem with the fs/gs change goes above and beyond this problem. So, >>we have about 2 months to sort this all out. Any volunteers? > > > I'm not sure I fully understand the problem, but can't you > just make libpthread avoid using *setbase() if the symbol > isn't available and use the ldt functions as a fallback? > > #pragma weak i386_get_gsbase > static void *have_gsbase = i386_get_gsbase; > > ... > > if (have_gsbase == NULL) { > /* use ldt stuff */ > } > else { > /* use i386_get_gsbase */ > } > > You just need something else to force the symbol i386_get_gsbase > to be loaded; the #pragma weak won't force it to be loaded even > if it is present. > If that's all that it takes, then that's fine by mean. I don't understand the mechanics of the problem well enough to comment otherwise. Peter? Scott From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 20:57: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 D564E16A4CE; Fri, 22 Apr 2005 20:57:43 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DDB43D39; Fri, 22 Apr 2005 20:57:43 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 37B9C2A8F6; Fri, 22 Apr 2005 13:57:43 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id C88D3E2B5; Fri, 22 Apr 2005 13:57:42 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.1/8.13.1) with ESMTP id j3MKvfUL072850; Fri, 22 Apr 2005 13:57:41 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.1/8.13.1/Submit) id j3MKvWYl072849; Fri, 22 Apr 2005 13:57:32 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: Scott Long Date: Fri, 22 Apr 2005 13:57:31 -0700 User-Agent: KMail/1.7.1 References: <426954D6.1080704@samsco.org> In-Reply-To: <426954D6.1080704@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504221357.31957.peter@wemm.org> cc: Daniel Eischen cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 20:57:44 -0000 On Friday 22 April 2005 12:47 pm, Scott Long wrote: > Daniel Eischen wrote: > > On Fri, 22 Apr 2005, Scott Long wrote: > >>Warner Losh wrote: > >>>>Having lived through the std{io,err,out} libc snafu, the > >>>>libm.so.2 snafu, and now the libc.so.5/libpthread.so.1 > >>>>problem, I will once again suggest that *ALL* library > >>>>version numbers should be bumped when a new branch is > >>>>created. > >>> > >>>Yes. When a library version is bumped, *ALL* libraries that > >>> depend on it need to be bumped. Sadly, this has proven to be too > >>> difficult because it would create an unholy maintanence problem > >>> for the ports. > >>> > >>>Warner > >> > >>Well, there is indeed a problem at the moment of libc being bumped > >> for 6-current but not libpthread. However, I think that the > >> particular problem with the fs/gs change goes above and beyond > >> this problem. So, we have about 2 months to sort this all out. > >> Any volunteers? > > > > I'm not sure I fully understand the problem, but can't you > > just make libpthread avoid using *setbase() if the symbol > > isn't available and use the ldt functions as a fallback? > > > > #pragma weak i386_get_gsbase > > static void *have_gsbase = i386_get_gsbase; > > > > ... > > > > if (have_gsbase == NULL) { > > /* use ldt stuff */ > > } > > else { > > /* use i386_get_gsbase */ > > } > > > > You just need something else to force the symbol i386_get_gsbase > > to be loaded; the #pragma weak won't force it to be loaded even > > if it is present. > > If that's all that it takes, then that's fine by mean. I don't > understand the mechanics of the problem well enough to comment > otherwise. Peter? The only other idea that springs to mind is to use dlsym() to test for the symbol, but that has its own serious problems. If the pragma weak stuff works, then I'd be happy with that. The only gotcha is that we still have to test for the possibility that the *base syscalls return EINVAL.. This will happen for booting old kernel.old files, and I'm not sure that current is quite robust enough yet that people aren't going to want to be able to rewind a few months. So, the options are: 1) test for have_gsbase using weak (or dlsym). 2) As previously suggested, add implemenations to libc.so.5 and pick them up via a fresh compat5x. We can add an implementation to libc.so.5. Since they wouldn't be used on 5.x, there is no risk of breaking anything. The functions would only do something when running the libc.so.5 library with a 5.x application on 6.x. I have a slight preference for #2, but that would mean adding two tiny (but otherwise unused) libc.so functions very late in the cycle. If re@ would allow it, I'd like that. But the #pragma weak option also works for me. #2 can also make it a little easier to run 5.x i386 binaries on amd64 - we could kill of most of those nasty ifdefs. #1 would end up something like: #pragma weak i386_set_gsbase #pragma weak i386_get_gsbase static void (*have_get_gsbase)(void) = i386_get_gsbase; static void (*have_set_gsbase)(void *) = i386_set_gsbase; if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { use_ldt(); } else { use_gsbase(); } I think that is sufficient to test if the symbols are present and test if they work at runtime... BTW: since somebody asked.. The runtime tests should be removed before 6.x is branched. They're only present for kernel.old compatability, nothing else. The runtime tests are ugly. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 21:05: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 8CC0216A4D0; Fri, 22 Apr 2005 21:05:46 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DE7543D67; Fri, 22 Apr 2005 21:05:46 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3ML3xwB028240; Fri, 22 Apr 2005 17:03:59 -0400 (EDT) Date: Fri, 22 Apr 2005 17:03:59 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Peter Wemm In-Reply-To: <200504221357.31957.peter@wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 21:05:46 -0000 On Fri, 22 Apr 2005, Peter Wemm wrote: > The only other idea that springs to mind is to use dlsym() to test for > the symbol, but that has its own serious problems. If the pragma weak > stuff works, then I'd be happy with that. > > The only gotcha is that we still have to test for the possibility that > the *base syscalls return EINVAL.. This will happen for booting old > kernel.old files, and I'm not sure that current is quite robust enough > yet that people aren't going to want to be able to rewind a few months. > > So, the options are: > 1) test for have_gsbase using weak (or dlsym). > 2) As previously suggested, add implemenations to libc.so.5 and pick > them up via a fresh compat5x. We can add an implementation to > libc.so.5. Since they wouldn't be used on 5.x, there is no risk of > breaking anything. The functions would only do something when running > the libc.so.5 library with a 5.x application on 6.x. > > I have a slight preference for #2, but that would mean adding two tiny > (but otherwise unused) libc.so functions very late in the cycle. If > re@ would allow it, I'd like that. But the #pragma weak option also > works for me. > > #2 can also make it a little easier to run 5.x i386 binaries on amd64 - > we could kill of most of those nasty ifdefs. > > #1 would end up something like: > #pragma weak i386_set_gsbase > #pragma weak i386_get_gsbase > static void (*have_get_gsbase)(void) = i386_get_gsbase; > static void (*have_set_gsbase)(void *) = i386_set_gsbase; > if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { > use_ldt(); > } else { > use_gsbase(); > } > I think that is sufficient to test if the symbols are present and test > if they work at runtime... I worked up a quick patch. It compiles, but it will be some time before I can try it. http://people.freebsd.org/~deischen/kse/libpthread.diffs -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 21:26: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 4F58C16A4CE; Fri, 22 Apr 2005 21:26:38 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFFD443D53; Fri, 22 Apr 2005 21:26:37 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3MLQaDB025109; Fri, 22 Apr 2005 17:26:36 -0400 (EDT) Date: Fri, 22 Apr 2005 17:26:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Peter Wemm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: peter@freebsd.org cc: sgk@troutmask.apl.washington.edu cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 21:26:38 -0000 On Fri, 22 Apr 2005, Daniel Eischen wrote: > On Fri, 22 Apr 2005, Peter Wemm wrote: > > > > > #2 can also make it a little easier to run 5.x i386 binaries on amd64 - > > we could kill of most of those nasty ifdefs. > > > > #1 would end up something like: > > #pragma weak i386_set_gsbase > > #pragma weak i386_get_gsbase > > static void (*have_get_gsbase)(void) = i386_get_gsbase; > > static void (*have_set_gsbase)(void *) = i386_set_gsbase; > > if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { > > use_ldt(); > > } else { > > use_gsbase(); > > } > > I think that is sufficient to test if the symbols are present and test > > if they work at runtime... > > I worked up a quick patch. It compiles, but it will be some time > before I can try it. > > http://people.freebsd.org/~deischen/kse/libpthread.diffs Note that I also slightly prefer #2, since you would have to make the #pragma weak hacks to both libpthread and libthr. -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 21:29:22 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 59B3216A4CE; Fri, 22 Apr 2005 21:29:22 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EAA143D48; Fri, 22 Apr 2005 21:29:22 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id EB6552A8DA; Fri, 22 Apr 2005 14:29:21 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 77275E2B5; Fri, 22 Apr 2005 14:29:21 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.1/8.13.1) with ESMTP id j3MLTKPR073214; Fri, 22 Apr 2005 14:29:20 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.1/8.13.1/Submit) id j3MLTKBt073213; Fri, 22 Apr 2005 14:29:20 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: Daniel Eischen Date: Fri, 22 Apr 2005 14:29:19 -0700 User-Agent: KMail/1.7.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504221429.20458.peter@wemm.org> cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 21:29:22 -0000 On Friday 22 April 2005 02:03 pm, Daniel Eischen wrote: > On Fri, 22 Apr 2005, Peter Wemm wrote: > > The only other idea that springs to mind is to use dlsym() to test > > for the symbol, but that has its own serious problems. If the > > pragma weak stuff works, then I'd be happy with that. > > > > The only gotcha is that we still have to test for the possibility > > that the *base syscalls return EINVAL.. This will happen for > > booting old kernel.old files, and I'm not sure that current is > > quite robust enough yet that people aren't going to want to be able > > to rewind a few months. > > > > So, the options are: > > 1) test for have_gsbase using weak (or dlsym). > > 2) As previously suggested, add implemenations to libc.so.5 and > > pick them up via a fresh compat5x. We can add an implementation to > > libc.so.5. Since they wouldn't be used on 5.x, there is no risk of > > breaking anything. The functions would only do something when > > running the libc.so.5 library with a 5.x application on 6.x. > > > > I have a slight preference for #2, but that would mean adding two > > tiny (but otherwise unused) libc.so functions very late in the > > cycle. If re@ would allow it, I'd like that. But the #pragma weak > > option also works for me. > > > > #2 can also make it a little easier to run 5.x i386 binaries on > > amd64 - we could kill of most of those nasty ifdefs. > > > > #1 would end up something like: > > #pragma weak i386_set_gsbase > > #pragma weak i386_get_gsbase > > static void (*have_get_gsbase)(void) = i386_get_gsbase; > > static void (*have_set_gsbase)(void *) = i386_set_gsbase; > > if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { > > use_ldt(); > > } else { > > use_gsbase(); > > } > > I think that is sufficient to test if the symbols are present and > > test if they work at runtime... > > I worked up a quick patch. It compiles, but it will be some time > before I can try it. > > http://people.freebsd.org/~deischen/kse/libpthread.diffs I think this will work. If somebody would like to try this, I think it would be a good thing. (rebuild libpthread.so.0, and run a 5.x threaded binary that would normally have the undefined symbols) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 21:31:14 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 20D5616A4CE; Fri, 22 Apr 2005 21:31:14 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1E5B43D46; Fri, 22 Apr 2005 21:31:12 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip68-230-188-82.dc.dc.cox.net [68.230.188.82]) (authenticated bits=0) by pittgoth.com (8.12.10/8.12.10) with ESMTP id j3MLVAkU067050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Apr 2005 17:31:11 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 22 Apr 2005 17:30:33 -0400 From: Tom Rhodes To: Peter Wemm Message-ID: <20050422173033.33890323@mobile.pittgoth.com> In-Reply-To: <200504221429.20458.peter@wemm.org> References: <200504221429.20458.peter@wemm.org> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: Daniel Eischen cc: peter@FreeBSD.org cc: sgk@troutmask.apl.washington.edu cc: freebsd-arch@FreeBSD.org Subject: Re: libpthread version bump 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, 22 Apr 2005 21:31:14 -0000 On Fri, 22 Apr 2005 14:29:19 -0700 Peter Wemm wrote: > On Friday 22 April 2005 02:03 pm, Daniel Eischen wrote: > > On Fri, 22 Apr 2005, Peter Wemm wrote: > > > The only other idea that springs to mind is to use dlsym() to test > > > for the symbol, but that has its own serious problems. If the > > > pragma weak stuff works, then I'd be happy with that. > > > > > > The only gotcha is that we still have to test for the possibility > > > that the *base syscalls return EINVAL.. This will happen for > > > booting old kernel.old files, and I'm not sure that current is > > > quite robust enough yet that people aren't going to want to be able > > > to rewind a few months. > > > > > > So, the options are: > > > 1) test for have_gsbase using weak (or dlsym). > > > 2) As previously suggested, add implemenations to libc.so.5 and > > > pick them up via a fresh compat5x. We can add an implementation to > > > libc.so.5. Since they wouldn't be used on 5.x, there is no risk of > > > breaking anything. The functions would only do something when > > > running the libc.so.5 library with a 5.x application on 6.x. > > > > > > I have a slight preference for #2, but that would mean adding two > > > tiny (but otherwise unused) libc.so functions very late in the > > > cycle. If re@ would allow it, I'd like that. But the #pragma weak > > > option also works for me. > > > > > > #2 can also make it a little easier to run 5.x i386 binaries on > > > amd64 - we could kill of most of those nasty ifdefs. > > > > > > #1 would end up something like: > > > #pragma weak i386_set_gsbase > > > #pragma weak i386_get_gsbase > > > static void (*have_get_gsbase)(void) = i386_get_gsbase; > > > static void (*have_set_gsbase)(void *) = i386_set_gsbase; > > > if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { > > > use_ldt(); > > > } else { > > > use_gsbase(); > > > } > > > I think that is sufficient to test if the symbols are present and > > > test if they work at runtime... > > > > I worked up a quick patch. It compiles, but it will be some time > > before I can try it. > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > I think this will work. If somebody would like to try this, I think it > would be a good thing. (rebuild libpthread.so.0, and run a 5.x > threaded binary that would normally have the undefined symbols) Hey! I have one of those! And I would like to use it. Building now! :) -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 22:19:09 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 9B1F416A4CE for ; Fri, 22 Apr 2005 22:19:09 +0000 (GMT) Received: from pittgoth.com (14.zlnp1.xdsl.nauticom.net [209.195.149.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED25943D46 for ; Fri, 22 Apr 2005 22:19:08 +0000 (GMT) (envelope-from trhodes@FreeBSD.org) Received: from mobile.pittgoth.com (ip68-230-188-82.dc.dc.cox.net [68.230.188.82]) (authenticated bits=0) by pittgoth.com (8.12.10/8.12.10) with ESMTP id j3MMJ7kU067263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 22 Apr 2005 18:19:08 -0400 (EDT) (envelope-from trhodes@FreeBSD.org) Date: Fri, 22 Apr 2005 18:18:29 -0400 From: Tom Rhodes To: freebsd-arch@FreeBSD.org Message-ID: <20050422181829.1e0221ce@mobile.pittgoth.com> In-Reply-To: <20050422173033.33890323@mobile.pittgoth.com> References: <200504221429.20458.peter@wemm.org> <20050422173033.33890323@mobile.pittgoth.com> X-Mailer: Sylpheed-Claws 1.0.1 (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: libpthread version bump 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, 22 Apr 2005 22:19:09 -0000 On Fri, 22 Apr 2005 17:30:33 -0400 Tom Rhodes wrote: > On Fri, 22 Apr 2005 14:29:19 -0700 > Peter Wemm wrote: > > > On Friday 22 April 2005 02:03 pm, Daniel Eischen wrote: > > > On Fri, 22 Apr 2005, Peter Wemm wrote: > > > > The only other idea that springs to mind is to use dlsym() to test > > > > for the symbol, but that has its own serious problems. If the > > > > pragma weak stuff works, then I'd be happy with that. > > > > > > > > The only gotcha is that we still have to test for the possibility > > > > that the *base syscalls return EINVAL.. This will happen for > > > > booting old kernel.old files, and I'm not sure that current is > > > > quite robust enough yet that people aren't going to want to be able > > > > to rewind a few months. > > > > > > > > So, the options are: > > > > 1) test for have_gsbase using weak (or dlsym). > > > > 2) As previously suggested, add implemenations to libc.so.5 and > > > > pick them up via a fresh compat5x. We can add an implementation to > > > > libc.so.5. Since they wouldn't be used on 5.x, there is no risk of > > > > breaking anything. The functions would only do something when > > > > running the libc.so.5 library with a 5.x application on 6.x. > > > > > > > > I have a slight preference for #2, but that would mean adding two > > > > tiny (but otherwise unused) libc.so functions very late in the > > > > cycle. If re@ would allow it, I'd like that. But the #pragma weak > > > > option also works for me. > > > > > > > > #2 can also make it a little easier to run 5.x i386 binaries on > > > > amd64 - we could kill of most of those nasty ifdefs. > > > > > > > > #1 would end up something like: > > > > #pragma weak i386_set_gsbase > > > > #pragma weak i386_get_gsbase > > > > static void (*have_get_gsbase)(void) = i386_get_gsbase; > > > > static void (*have_set_gsbase)(void *) = i386_set_gsbase; > > > > if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { > > > > use_ldt(); > > > > } else { > > > > use_gsbase(); > > > > } > > > > I think that is sufficient to test if the symbols are present and > > > > test if they work at runtime... > > > > > > I worked up a quick patch. It compiles, but it will be some time > > > before I can try it. > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > I think this will work. If somebody would like to try this, I think it > > would be a good thing. (rebuild libpthread.so.0, and run a 5.x > > threaded binary that would normally have the undefined symbols) > > Hey! I have one of those! And I would like to use it. Building > now! :) And it works. Yay. Thanks Dan. -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 23:12:33 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 6EE6F16A4CE; Fri, 22 Apr 2005 23:12:33 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3C4F43D2D; Fri, 22 Apr 2005 23:12:32 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3MNCWkQ001135; Fri, 22 Apr 2005 19:12:32 -0400 (EDT) Date: Fri, 22 Apr 2005 19:12:32 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Tom Rhodes In-Reply-To: <20050422181829.1e0221ce@mobile.pittgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2005 23:12:33 -0000 On Fri, 22 Apr 2005, Tom Rhodes wrote: > On Fri, 22 Apr 2005 17:30:33 -0400 > Tom Rhodes wrote: > > > > > > > > > I worked up a quick patch. It compiles, but it will be some time > > > > before I can try it. > > > > > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > > > I think this will work. If somebody would like to try this, I think it > > > would be a good thing. (rebuild libpthread.so.0, and run a 5.x > > > threaded binary that would normally have the undefined symbols) > > > > Hey! I have one of those! And I would like to use it. Building > > now! :) > > And it works. Yay. Thanks Dan. I'll let folks think about this for a while before committing this. -- DE From owner-freebsd-arch@FreeBSD.ORG Fri Apr 22 23:16: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 CBFB416A4CE; Fri, 22 Apr 2005 23:16:29 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE37643D2D; Fri, 22 Apr 2005 23:16:29 +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.3/8.13.3) with ESMTP id j3MNGRQZ092815; Fri, 22 Apr 2005 23:16:28 GMT (envelope-from davidxu@freebsd.org) Message-ID: <426985CA.30003@freebsd.org> Date: Sat, 23 Apr 2005 07:16:26 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050306 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump 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, 22 Apr 2005 23:16:29 -0000 Daniel Eischen wrote: >On Fri, 22 Apr 2005, Daniel Eischen wrote: > > > >>On Fri, 22 Apr 2005, Peter Wemm wrote: >> >> >> >>>#2 can also make it a little easier to run 5.x i386 binaries on amd64 - >>>we could kill of most of those nasty ifdefs. >>> >>>#1 would end up something like: >>> #pragma weak i386_set_gsbase >>> #pragma weak i386_get_gsbase >>> static void (*have_get_gsbase)(void) = i386_get_gsbase; >>> static void (*have_set_gsbase)(void *) = i386_set_gsbase; >>> if (have_i386_get_gsbase == NULL || have_get_gsbase() == -1) { >>> use_ldt(); >>> } else { >>> use_gsbase(); >>> } >>>I think that is sufficient to test if the symbols are present and test >>>if they work at runtime... >>> >>> >>I worked up a quick patch. It compiles, but it will be some time >>before I can try it. >> >> http://people.freebsd.org/~deischen/kse/libpthread.diffs >> >> > >Note that I also slightly prefer #2, since you would have to make >the #pragma weak hacks to both libpthread and libthr. > > > I won't support LDT based TLS, so you don't have to patch it. David Xu From owner-freebsd-arch@FreeBSD.ORG Sat Apr 23 00:42:40 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 AD40616A4DC; Sat, 23 Apr 2005 00:42:40 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F2343D1D; Sat, 23 Apr 2005 00:42:40 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j3N0gcka017341; Fri, 22 Apr 2005 20:42:38 -0400 (EDT) Date: Fri, 22 Apr 2005 20:42:38 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: David Xu In-Reply-To: <426985CA.30003@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: sgk@troutmask.apl.washington.edu cc: peter@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: libpthread version bump X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 00:42:40 -0000 On Sat, 23 Apr 2005, David Xu wrote: > Daniel Eischen wrote: > > >On Fri, 22 Apr 2005, Daniel Eischen wrote: > >>> > >>I worked up a quick patch. It compiles, but it will be some time > >>before I can try it. > >> > >> http://people.freebsd.org/~deischen/kse/libpthread.diffs > >> > >> > > > >Note that I also slightly prefer #2, since you would have to make > >the #pragma weak hacks to both libpthread and libthr. > > > > I won't support LDT based TLS, so you don't have to patch it. If there are applications linked to libthr and libc.so.5 (in 5.x) you have the same problem. If you aren't going to support LDT, then you should bump the library version (unless we do #2). -- DE