From gd78059@sac.sfbay.sun.com Thu Oct 8 00:24:18 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n987OHes002212 for ; Thu, 8 Oct 2009 00:24:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n987O75W010933; Thu, 8 Oct 2009 08:24:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR600907PWEJU00@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 00:24:14 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR600H9VPWD4V90@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 00:24:13 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n987ODPf034556; Thu, 08 Oct 2009 00:24:13 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n987OBVt002207; Thu, 08 Oct 2009 00:24:11 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n987OBne002203; Thu, 08 Oct 2009 00:24:11 -0700 (PDT) Date: Thu, 08 Oct 2009 00:24:11 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: EOF of libucb [PSARC/2009/541 OnePager] To: PSARC-ext@sun.com Message-id: <200910080724.n987OBne002203@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 4331 I'm submitting the following *full* case on my own behalf. Note that I'm not filing using the "normal" 20q format. I think this case will be easier to understand without it. The major concerns raised in this case have to do with our compatibility guarantees, which is why this case must be handled as a full review. The content itself is fairly straight forward. I'm hoping to have a slot on the agenda for discussion on Oct. 21, 2009. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF of libucb 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 08 October, 2009 4. Technical Description EOF of /usr/ucblib ------------------ We have already removed Source Compatibility for legacy SunOS 4.x (BSD) applications. Right now we retain some of the infrastructure to support legacy applications at *run-time* in the form of these libraries located under /usr/ucblib (with both .so and .so.1, and 32 and 64-bit variants as appropriate): libcurses libdbm librpcsoc libtermcap libucb Its our belief that these libraries should not be used in any applications, even at run time. This is ancient, legacy stuff, best avoided by everyone. There is quite a collection of advice to developers that these libraries should be avoided, including in the man pages for the libraries themselves, as well as numerous internet forum, mailing list, and usenet postings, spanning a history well over a decade. While this kind of removal is not normally appropriate for a "minor" release, the unique rules surrounding the release of OpenSolaris (and subsequently Solaris.Next) makes this seem a particularly good opportunity to finally ditch this bit of baggage from the 1980's. RISKS ----- The main risk is that some software out there might still be using these libraries. This would be particularly unfortunate, since those applications will cease to function. A web search found only one common case, which is the Mplayer and associated ffmpeg open source video player, where this was found to be an issue. (In this case, a recompile of the open source application without /usr/ucb in the compiler/linker search paths resolves the problem.) MITIGATION ----------- Fortunately, for applications that might have this problem but which cannot be recompiled (such as when source code is not available), we do have a mitigation strategy. The delivery of S10C (PSARC 2009/253) will make it possible to use these applications in a legacy Solaris 10 container, which will still have the /usr/ucblib libraries. Its possible therefore that the Members might decide to insist that this project not deliver before the S10C project does. Its worth mentioning that this mitigation strategy is not perfect, since the S10C project does not necessarily support all applications. However, we believe that the S10C project will cover the bulk of any applcations that need this kind of support, and we truly believe the number of such applicattions to be vanishingly small. COMMANDS IN /usr/ucb/ --------------------- One possible concern is our own commands that are delivered in /usr/ucb. The project team has undertaken the effort to investigate these further. All of them have now been converted (in a local workspace) to use safer modern SYSV libraries located in /usr/lib ... with just a couple of minor exceptions. reset and tset use libtermcap in ways such that the terminfo replacement does not provide equivalent functionality. While we believe that these utilities should be converted to use native terminfo instead of termcap, it turns out that it is simply more expedient to link a private copy of libtermcap statically against these two utilities. Updating them to use terminfo should be the subject of another effort, with a separate CR. The remaining commands are the plotting commands, which the project team is hoping to EOF separately per PSARC 2009/540. With these changes, we no longer have a need for any of these libraries to build our own software. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: OnePager 6.6. ARC Exposure: open From peter.tribble@gmail.com Thu Oct 8 01:38:12 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n988cCSA003604 for ; Thu, 8 Oct 2009 01:38:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n988c43L028737 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 09:38:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR600H03TBM2900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 01:38:10 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR6005Q3TBLLHD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 01:38:09 -0700 (PDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n988Uubc012654 for ; Thu, 08 Oct 2009 08:38:09 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay42i.sun.com with ESMTP id BT-MMP-681444 for PSARC-ext@sun.com; Thu, 08 Oct 2009 08:38:09 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-22507765 for PSARC-ext@sun.com; Thu, 08 Oct 2009 08:38:03 +0000 (Z) Received: from mail-yw0-f180.google.com ([209.85.211.180] [209.85.211.180]) by relay4i.sun.com with ESMTP id BT-MMP-5068769 for PSARC-ext@sun.com; Thu, 08 Oct 2009 08:38:03 +0000 (Z) Received: by mail-yw0-f180.google.com with SMTP id 10so5251417ywh.8 for ; Thu, 08 Oct 2009 01:37:33 -0700 (PDT) Received: by 10.101.21.17 with SMTP id y17mr931197ani.152.1254991053334; Thu, 08 Oct 2009 01:37:33 -0700 (PDT) Date: Thu, 08 Oct 2009 09:37:33 +0100 From: Peter Tribble Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <200910080724.n987OBne002203@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UpKIomwis3CwXASnAiDrgd8vN2k2JUgJuk6nsehS2L8=; b=Hx4D+RRadaGjsYTIRVhfMSA58jpo7iK0AxJaUs2OqZvy25PB1a3lDAq5X0cJHJW8mW b6QIk0gF14ubK4SQPkB9WNyRWs+dkAgYDj604a7v2LSU2X7cX5Q8CQjCwUXKKBzY0+Mv SPSBHx3ABzV1HWHArTejrROzza0feIyt6QTl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=M7poA/7Mat4lMqmzKJNG7KFxjGgd7/dKn49V7Y5mdLggcw/CDmhrABQ9wn33sVY8Mh Tsf8UV797pFY6hGBiiGtKNPzDEwIPhKDaRP6HckSl6aN6e4uoTV04zudhybPKqMf8VMG 1pIWeivYbhbCRN0EhzuZFepUhgWcwZi2F3b2o= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 3.630sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910080724.n987OBne002203@sac.sfbay.sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n988cCSA003604 Status: RO Content-Length: 2939 On Thu, Oct 8, 2009 at 8:24 AM, Garrett D'Amore - sun microsystems wrote: > I'm submitting the following *full* case on my own behalf. > > Note that I'm not filing using the "normal" 20q format.  I think this case > will be easier to understand without it.  The major concerns raised in > this case have to do with our compatibility guarantees, which is why this > case must be handled as a full review. The title seems slightly misnamed. This isn't just libucb; isn't it really the removal of SunOS 4 binary compatibility? > The content itself is fairly straight > forward. Or maybe not. > EOF of /usr/ucblib > ------------------ > > We have already removed Source Compatibility for legacy SunOS 4.x (BSD) > applications.  Right now we retain some of the infrastructure to support > legacy applications at *run-time* in the form of these libraries located > under /usr/ucblib And /usr/4lib (some of the filenames there are enough to turn one's hair grey). Why no mention of that? > (with both .so and .so.1, and 32 and 64-bit variants as > appropriate): > >        libcurses >        libdbm >        librpcsoc >        libtermcap >        libucb > > Its our belief that these libraries should not be used in any applications, > even at run time.  This is ancient, legacy stuff, best avoided by everyone. Apart from customers who actually need this stuff in order for their applications to work at all. > RISKS > ----- > > The main risk is that some software out there might still be using these > libraries.  This would be particularly unfortunate, since those applications > will cease to function.  A web search found only one common case, which is the > Mplayer and associated ffmpeg open source video player, where this was found > to be an issue.  (In this case, a recompile of the open source application > without /usr/ucb in the compiler/linker search paths resolves the problem.) You need to look harder. Searching the web isn't much help; a lot of affected software will (almost by definition) predate the web; much of it is also commercial. I know that I use some SunOS 4 binaries pretty regularly. However, a quick look around one of our datacenters indicates that we have a variety of old, presumably commercial, software still using the old ucb stuff. > we truly believe the number > of such applicattions to be vanishingly small. I believe you're sadly mistaken in believing this to be a small problem. One of the key advantages of Solaris is that old software just runs. (And in practice this actually works better the further back you go, as you don't have to worry about all the unstable FOSS applications and libraries that have been introduced in recent times.) All this stuff only applies to SPARC, of course. There was no SunOS 4 on x86 to worry about (and /usr/4lib doesn't exist there). -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From casper@holland.sun.com Thu Oct 8 01:51:12 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n988pCUX003755 for ; Thu, 8 Oct 2009 01:51:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n988pBrN004876 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 01:51:12 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR600I0FTXAUF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 01:51:10 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR600IBITX84U10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 01:51:09 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n988p6rq014578; Thu, 08 Oct 2009 09:51:06 +0100 (BST) Date: Thu, 08 Oct 2009 10:51:06 +0200 From: Casper.Dik@sun.com Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: Sender: casper@holland.sun.com To: Peter Tribble Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <200910080851.n988p6rq014578@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> Status: RO Content-Length: 423 >The title seems slightly misnamed. This isn't just libucb; isn't it really >the removal of SunOS 4 binary compatibility? > Correct; the SUNWbcp package (SunOS 4.x Binary Compatibity) uses these libraries. Are these libraries listed in the SPARC ABI? Just removing the compile symlinks I have no issue with, but removing these libraries themselves also requires the removal of SunOS 4.x Binary Compatibility. Casper From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Oct 8 03:28:31 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98ASUKx005649 for ; Thu, 8 Oct 2009 03:28:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98ASTm9011939 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 03:28:30 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR600M0BYFI6K00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 03:28:30 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR600GN4YFGVV40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 03:28:29 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n98AKmJk024174 for ; Thu, 08 Oct 2009 10:28:28 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-3624263 for PSARC-ext@sun.com; Thu, 08 Oct 2009 10:28:27 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-66609535 for PSARC-ext@sun.com; Thu, 08 Oct 2009 10:28:27 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay1i.sun.com with ESMTP id BT-MMP-15500719 for PSARC-ext@sun.com; Thu, 08 Oct 2009 10:28:27 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 43D0F7D4004; Thu, 08 Oct 2009 12:28:26 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 29D037D4012; Thu, 08 Oct 2009 12:28:25 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n98ASNUm002820; Thu, 08 Oct 2009 12:28:23 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 08 Oct 2009 12:28:23 +0200 Date: Thu, 08 Oct 2009 12:26:57 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <200910080724.n987OBne002203@sac.sfbay.sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4acdbe71.ZrWqznSK5nMSJLgy%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910080724.n987OBne002203@sac.sfbay.sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 08 Oct 2009 10:28:23.0428 (UTC) FILETIME=[104FCC40:01CA4802] Status: RO Content-Length: 1620 "Garrett D'Amore - sun microsystems" wrote: > COMMANDS IN /usr/ucb/ > --------------------- > > One possible concern is our own commands that are delivered in /usr/ucb. > > The project team has undertaken the effort to investigate these further. > All of them have now been converted (in a local workspace) to use safer > modern SYSV libraries located in /usr/lib ... with just a couple of minor > exceptions. > > reset and tset use libtermcap in ways such that the terminfo replacement > does not provide equivalent functionality. While we believe that these > utilities should be converted to use native terminfo instead of termcap, > it turns out that it is simply more expedient to link a private copy of > libtermcap statically against these two utilities. Updating them to use > terminfo should be the subject of another effort, with a separate CR. Terminfo indeed is not compatible enough to support all termcap based applications. If you need a 100% compatible modern replacement, look for libxtermcap from: ftp://ftp.berlios.de/pub/schily/ It was written from scratch in 1986, it is higly portable and it supports new ideas from BSD like e.g. TERMPATH= Note that you of course cannot remove /etc/termcap and that you should think about upgrading the file from time to time. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From sks@cvok.co.uk Thu Oct 8 03:53:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98ArPZc005842 for ; Thu, 8 Oct 2009 03:53:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98ArNN7024620 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 11:53:25 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR600B01ZL0PK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 03:53:24 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR6006D9ZL0JT20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 03:53:24 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98AjKEU004461 for ; Thu, 08 Oct 2009 10:53:24 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-432589 for PSARC-ext@sun.com; Thu, 08 Oct 2009 10:53:06 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-66654402 for PSARC-ext@sun.com; Thu, 08 Oct 2009 10:53:06 +0000 (Z) Received: from relay.pcl-ipout01.plus.net ([212.159.7.99] [212.159.7.99]) by relay1i.sun.com with ESMTP id BT-MMP-26442653 for PSARC-ext@sun.com; Thu, 08 Oct 2009 10:53:06 +0000 (Z) Received: from pih-relay04.plus.net ([212.159.14.17]) by relay.pcl-ipout01.plus.net with ESMTP; Thu, 08 Oct 2009 11:52:05 +0100 Received: from [212.159.121.54] (helo=[192.168.0.2]) by pih-relay04.plus.net with esmtp (Exim) id 1MvqbL-0003F2-Nl; Thu, 08 Oct 2009 11:52:04 +0100 Date: Thu, 08 Oct 2009 11:52:02 +0100 From: Sean Sprague Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4acdbe71.ZrWqznSK5nMSJLgy%Joerg.Schilling@fokus.fraunhofer.de> To: Joerg Schilling Cc: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4ACDC452.4010003@cvok.co.uk> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHtgzUrUnw4R/2dsb2JhbADYeIQqBA X-Plusnet-Relay: 063bd4ccb2471370f3b7a57434dfa766 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4acdbe71.ZrWqznSK5nMSJLgy%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090903 SeaMonkey/2.0b2 Status: RO Content-Length: 354 Joerg, > Note that you of course cannot remove /etc/termcap and that you should think > about upgrading the file from time to time. > My first recollection of /etc/termcap was on an Altos 986 running Xenix 3.0b in the early 80's. I must get my one out of the cupboard downstairs and crank it up (and it will do...) to confirm. Regards... Sean. From gdamore@sun.com Thu Oct 8 06:44:00 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98DhxIA010079 for ; Thu, 8 Oct 2009 06:44:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n98DhfKB024730 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 21:43:58 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700B4Z7H9GT00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 06:43:57 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700AGM7H9YN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 06:43:57 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98Dhvhb023628 for ; Thu, 08 Oct 2009 06:43:57 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700C007DI1L00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 06:43:57 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR7002S37H81K90@fe-sfbay-09.sun.com>; Thu, 08 Oct 2009 06:43:57 -0700 (PDT) Date: Thu, 08 Oct 2009 06:43:56 -0700 From: "Garrett D'Amore" Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: Sender: Garrett.Damore@sun.com To: Peter Tribble Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4ACDEC9C.9040204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4689 Peter Tribble wrote: > On Thu, Oct 8, 2009 at 8:24 AM, Garrett D'Amore - sun microsystems > wrote: > >> I'm submitting the following *full* case on my own behalf. >> >> Note that I'm not filing using the "normal" 20q format. I think this case >> will be easier to understand without it. The major concerns raised in >> this case have to do with our compatibility guarantees, which is why this >> case must be handled as a full review. >> > > The title seems slightly misnamed. This isn't just libucb; isn't it really > the removal of SunOS 4 binary compatibility? > Yes, I suppose that I could have named it better. This is really about dropping support for older 4.x BCP. > >> The content itself is fairly straight >> forward. >> > > Or maybe not. > I didn't say "non-controversial". :-) > >> EOF of /usr/ucblib >> ------------------ >> >> We have already removed Source Compatibility for legacy SunOS 4.x (BSD) >> applications. Right now we retain some of the infrastructure to support >> legacy applications at *run-time* in the form of these libraries located >> under /usr/ucblib >> > > And /usr/4lib (some of the filenames there are enough to turn one's > hair grey). Why no mention of that? > Ah, because I only have x86 systems, I wasn't even noticing it. You're right, this should be removed as well, as part of removing SunOS 4.x binary compatibility. > >> (with both .so and .so.1, and 32 and 64-bit variants as >> appropriate): >> >> libcurses >> libdbm >> librpcsoc >> libtermcap >> libucb >> >> Its our belief that these libraries should not be used in any applications, >> even at run time. This is ancient, legacy stuff, best avoided by everyone. >> > > Apart from customers who actually need this stuff in order for their > applications to work at all. > It would be good to understand how widespread the need for this stuff is. I had been under the impression that few people were still using 4.x binaries anymore. Certainly, these libraries shouldn't be used with newer SunOS 5.x binaries. > >> RISKS >> ----- >> >> The main risk is that some software out there might still be using these >> libraries. This would be particularly unfortunate, since those applications >> will cease to function. A web search found only one common case, which is the >> Mplayer and associated ffmpeg open source video player, where this was found >> to be an issue. (In this case, a recompile of the open source application >> without /usr/ucb in the compiler/linker search paths resolves the problem.) >> > > You need to look harder. Searching the web isn't much help; a lot > of affected software will (almost by definition) predate the web; > much of it is also commercial. > I'm not as much interested in what *existed* before the web, as much as whether that software is still in use today. I think the "web" is a good indicator of what components are still in use. > I know that I use some SunOS 4 binaries pretty regularly. However, > a quick look around one of our datacenters indicates that we have > a variety of old, presumably commercial, software still using the old > ucb stuff. > Can you list some of them? Are there no "newer" alternatives available? Is it the case that these applications would not be usable within an S10 container? > >> we truly believe the number >> of such applicattions to be vanishingly small. >> > > I believe you're sadly mistaken in believing this to be a small problem. > I believe that the number of "interesting" applications which require 4.x ABI or which require these libraries, *and* which won't run in an S10 container, *is* vanishingly small. (Yes, some applications can be contrived, but for the most part I doubt our customers will be running such applications.) > One of the key advantages of Solaris is that old software just runs. (And > in practice this actually works better the further back you go, as you don't > have to worry about all the unstable FOSS applications and libraries that > have been introduced in recent times.) > > All this stuff only applies to SPARC, of course. There was no SunOS 4 > on x86 to worry about (and /usr/4lib doesn't exist there). > Yes. Although /usr/ucblib *does* exist there, presumably to support source compatibility. At some level, some of the rigidness of our binary compatibility guarantee has been broken in OpenSolaris. So, given the existence of S10C as a mitigation strategy, it seemed (to me) like the time was ripe to consider finally dropping native support for these binaries. - Garrett From gdamore@Sun.com Thu Oct 8 07:14:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98EEaVf010809 for ; Thu, 8 Oct 2009 07:14:37 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98EEVV2005259 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 15:14:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700D0L8WAT400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 07:14:34 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700B4W8WAEO30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 07:14:34 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98EEYvT006039 for ; Thu, 08 Oct 2009 07:14:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700H008QIEP00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 07:14:34 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR700IVC8W9Y3B0@fe-sfbay-10.sun.com>; Thu, 08 Oct 2009 07:14:34 -0700 (PDT) Date: Thu, 08 Oct 2009 07:14:33 -0700 From: "Garrett D'Amore" Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACDEC9C.9040204@sun.com> Sender: Garrett.Damore@Sun.com To: Peter Tribble Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.com Message-id: <4ACDF3C9.7030207@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 492 Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you get the libraries in /usr/4lib, using the a.out exec module. I don't think you wind up using any of the ELF stuff in /usr/ucblib. So, maybe I didn't name this inappropriately after all. What *would* break, are 4.x *sources* that have been *compiled* on SunOS 5.x. Hopefully there are few, if any, such programs still around. - Garrett From casper@holland.sun.com Thu Oct 8 07:22:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98EMktg010950 for ; Thu, 8 Oct 2009 07:22:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n98EMgd7025728; Thu, 8 Oct 2009 08:22:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700D1199XDB00@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 07:22:45 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700AEM99WYS30@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 07:22:44 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98EMe8H055250; Thu, 08 Oct 2009 15:22:40 +0100 (BST) Date: Thu, 08 Oct 2009 16:22:37 +0200 From: Casper.Dik@sun.com Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACDF3C9.7030207@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Peter Tribble , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <200910081422.n98EMe8H055250@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> Status: RO Content-Length: 1071 >Actually, looking at the code, I don't see how /usr/ucblib is used by >4.x *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you >get the libraries in /usr/4lib, using the a.out exec module. I don't >think you wind up using any of the ELF stuff in /usr/ucblib. dump -Lv /usr/4lib/sbcp **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libmapmalloc.so.1 [2] NEEDED libc.so.1.9 [3] NEEDED libucb.so.1 [4] NEEDED libnsl.so.1 [5] NEEDED libc.so.1 [6] RUNPATH /usr/4lib:/usr/ucblib [7] RPATH /usr/4lib:/usr/ucblib (sbcp is for "Static Binary Compatibility"; however, it's easy to have a partially statically linked executable so I think sbcp is always loaded for an a.out executable) Also, /usr/4lib/libc.so.1.9 is linked to libucb.so.1. >So, maybe I didn't name this inappropriately after all. > >What *would* break, are 4.x *sources* that have been *compiled* on SunOS >5.x. And 4.x binary compatibility :-) Casper From peter.tribble@gmail.com Thu Oct 8 07:23:55 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98ENtqs010964 for ; Thu, 8 Oct 2009 07:23:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98ENqZ0004077; Thu, 8 Oct 2009 07:23:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700M3O9BTSJ00@brm-avmta-1.central.sun.com>; Thu, 08 Oct 2009 08:23:53 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LKA9BSINY4@brm-avmta-1.central.sun.com>; Thu, 08 Oct 2009 08:23:52 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98EFfXS007978; Thu, 08 Oct 2009 14:23:51 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-3642824; Thu, 08 Oct 2009 14:23:51 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-67074450; Thu, 08 Oct 2009 14:23:51 +0000 (Z) Received: from mail-yx0-f203.google.com ([209.85.210.203] [209.85.210.203]) by relay1i.sun.com with ESMTP id BT-MMP-35882247; Thu, 08 Oct 2009 14:23:51 +0000 (Z) Received: by yxe41 with SMTP id 41so12455682yxe.30 for ; Thu, 08 Oct 2009 07:23:09 -0700 (PDT) Received: by 10.101.205.8 with SMTP id h8mr1390939anq.142.1255011789321; Thu, 08 Oct 2009 07:23:09 -0700 (PDT) Date: Thu, 08 Oct 2009 15:23:09 +0100 From: Peter Tribble Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACDF3C9.7030207@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=W81UW42HFHS1PRmCDrNWh5z0Aw5ef9rZokxSSamiDIo=; b=hC9fR9l1Lqm91hrWmKBvtk70Qbe3xa6Dhg+70Tl9h938PuSu0geCTy59M5scOvXIPN +H0heYbCSBQrElSDmrOq/c/dvGpayxPmAZreDFddoVvNimVoodKkmymjQHIdjW96TF6i YlZqAtL5W1LzJY9/FNq7qdXgY1JC9qb9PDaEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EIKsxwhHhNJhyu6A8kTpc9B6A9jUSAJw8BMTfl+C1F4QBmvTN2qRaEIm48cwiuRcAu 1YIHlKXT1s5TatIjufWgJXG09zSFn/HEbW7jfQQ8fy9yVSMeY7X/yac7xbFhVLb7rbyo eHeEKoGiSqofnK2J1PLT8TioUfagUuqwfSAvk= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n98ENtqs010964 Status: RO Content-Length: 1581 On Thu, Oct 8, 2009 at 3:14 PM, Garrett D'Amore wrote: > Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x > *binaries*.  I.e. if you have a SunOS 4.x binary, it looks like you get the > libraries in /usr/4lib, using the a.out exec module.  I don't think you wind > up using any of the ELF stuff in /usr/ucblib. % ldd /usr/4lib/libc.so.1.9 libucb.so.1 => /usr/ucblib/libucb.so.1 libc.so.1 => /lib/libc.so.1 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 => /lib/libsocket.so.1 libelf.so.1 => /lib/libelf.so.1 libmp.so.2 => /lib/libmp.so.2 libmd.so.1 => /lib/libmd.so.1 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,T5140/lib/libc_psr.so.1 /platform/SUNW,T5140/lib/libmd_psr.so.1 % dump -Lv /usr/4lib/libc.so.1.9 /usr/4lib/libc.so.1.9: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libucb.so.1 [2] NEEDED libc.so.1 [3] NEEDED libnsl.so.1 [4] NEEDED libsocket.so.1 [5] INIT 0x42f7c [6] FINI 0x42f90 [7] SONAME libc.so.1.9 [8] RUNPATH /usr/ucblib [9] RPATH /usr/ucblib ... It's definitely pulling libucb in. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From gdamore@Sun.COM Thu Oct 8 07:40:56 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98EeuHN011031 for ; Thu, 8 Oct 2009 07:40:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98Eesja012425 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 07:40:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70010NA47BQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 08:40:55 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LMXA43IR55@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 08:40:51 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98Eep2P008324 for ; Thu, 08 Oct 2009 07:40:51 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700B00A33NP00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 07:40:51 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR700LPXA3P2Q40@fe-sfbay-10.sun.com>; Thu, 08 Oct 2009 07:40:37 -0700 (PDT) Date: Thu, 08 Oct 2009 07:40:37 -0700 From: "Garrett D'Amore" Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: Sender: Garrett.Damore@Sun.COM To: Peter Tribble Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM Message-id: <4ACDF9E5.7010801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1981 Okay, corrected I stand. Although I *suspect* this problem could be corrected too. The library is coming in via the libc, not via the application pulling it in directly. (So if the relevant 4lib libraries were compiled to use normal libc, or got the important bits of libucb linked in directly, then wouldn't that resolve the main concern here?) - Garrett Peter Tribble wrote: > On Thu, Oct 8, 2009 at 3:14 PM, Garrett D'Amore wrote: > >> Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x >> *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you get the >> libraries in /usr/4lib, using the a.out exec module. I don't think you wind >> up using any of the ELF stuff in /usr/ucblib. >> > > % ldd /usr/4lib/libc.so.1.9 > libucb.so.1 => /usr/ucblib/libucb.so.1 > libc.so.1 => /lib/libc.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > libsocket.so.1 => /lib/libsocket.so.1 > libelf.so.1 => /lib/libelf.so.1 > libmp.so.2 => /lib/libmp.so.2 > libmd.so.1 => /lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libgen.so.1 => /lib/libgen.so.1 > libm.so.2 => /lib/libm.so.2 > /platform/SUNW,T5140/lib/libc_psr.so.1 > /platform/SUNW,T5140/lib/libmd_psr.so.1 > > % dump -Lv /usr/4lib/libc.so.1.9 > > /usr/4lib/libc.so.1.9: > > **** DYNAMIC SECTION INFORMATION **** > .dynamic: > [INDEX] Tag Value > [1] NEEDED libucb.so.1 > [2] NEEDED libc.so.1 > [3] NEEDED libnsl.so.1 > [4] NEEDED libsocket.so.1 > [5] INIT 0x42f7c > [6] FINI 0x42f90 > [7] SONAME libc.so.1.9 > [8] RUNPATH /usr/ucblib > [9] RPATH /usr/ucblib > ... > > It's definitely pulling libucb in. > > From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Oct 8 07:55:07 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98Et7S1011345 for ; Thu, 8 Oct 2009 07:55:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n98Et7Fe049121 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 08:55:07 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700227ARVJ700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 08:55:07 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LWGAQIIL35@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 08:54:19 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98EmD1q006310 for ; Thu, 08 Oct 2009 14:54:18 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-3137400 for PSARC-ext@Sun.COM; Thu, 08 Oct 2009 14:54:13 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-22983664 for PSARC-ext@Sun.COM; Thu, 08 Oct 2009 14:53:40 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay4i.sun.com with ESMTP id BT-MMP-13540018 for PSARC-ext@Sun.COM; Thu, 08 Oct 2009 14:53:39 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 344866F0556; Thu, 08 Oct 2009 16:53:38 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 832E26F054C; Thu, 08 Oct 2009 16:53:36 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n98Erbom011970; Thu, 08 Oct 2009 16:53:37 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 08 Oct 2009 16:53:37 +0200 Date: Thu, 08 Oct 2009 16:52:08 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACDF9E5.7010801@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: peter.tribble@gmail.com, gdamore@sun.com Cc: PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4acdfc98.ZjJxJmc99IhSHUhv%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 1.456sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> <4ACDF9E5.7010801@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 08 Oct 2009 14:53:37.0023 (UTC) FILETIME=[1D8DB0F0:01CA4827] Status: RO Content-Length: 798 "Garrett D'Amore" wrote: > Okay, corrected I stand. Although I *suspect* this problem could be > corrected too. The library is coming in via the libc, not via the > application pulling it in directly. (So if the relevant 4lib libraries > were compiled to use normal libc, or got the important bits of libucb > linked in directly, then wouldn't that resolve the main concern here?) You then break at least stdio and readdir() that uses different physical structure layout. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From gdamore@sun.com Thu Oct 8 08:25:28 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98FPS7s011961 for ; Thu, 8 Oct 2009 08:25:28 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98FPQVC023969 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 16:25:27 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700L0HC6EYC00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 08:25:26 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700B6PC6DEOF0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 08:25:25 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98FPPR9001699 for ; Thu, 08 Oct 2009 08:25:25 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700700BUXZI00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 08:25:25 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR7004KNC61A240@fe-sfbay-10.sun.com>; Thu, 08 Oct 2009 08:25:14 -0700 (PDT) Date: Thu, 08 Oct 2009 08:25:13 -0700 From: "Garrett D'Amore" Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4acdfc98.ZjJxJmc99IhSHUhv%Joerg.Schilling@fokus.fraunhofer.de> Sender: Garrett.Damore@sun.com To: Joerg Schilling Cc: peter.tribble@gmail.com, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4ACE0459.1030806@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> <4ACDF9E5.7010801@sun.com> <4acdfc98.ZjJxJmc99IhSHUhv%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1683 Joerg Schilling wrote: > "Garrett D'Amore" wrote: > > >> Okay, corrected I stand. Although I *suspect* this problem could be >> corrected too. The library is coming in via the libc, not via the >> application pulling it in directly. (So if the relevant 4lib libraries >> were compiled to use normal libc, or got the important bits of libucb >> linked in directly, then wouldn't that resolve the main concern here?) >> > > You then break at least stdio and readdir() that uses different physical > structure layout. > No, they still use the 4lib version of libc. Today the dependency tree looks like "app" --> 4lib/libc -+-> ucblib/libucb -->lib/libc | ^ +---------------+ What I'm proposing is that the ucblib/libucb component could be collapsed into 4lib/libc. So that you'd just have: "app" --> 4lib/libc --> lib/libc This would allow true 4.x a.out binaries to just keep working, while removing the external ucblib/ components. (The way to achieve this would just to be to statically link libucb into 4lib/libc.) It's quite possible that this is all just a vain effort to tilt at windmills, but I at least wanted to have the *discussion*. This seemed like a rare opportunity to have such a discussion. If we deliver Solaris.next with these components, then its likely that another opportunity to discuss it might not come along for a *long* time. If the end result is a denial of this case, I won't be seeking an appeal, but at least we'll have recent case history stating *why* we have to keep these bits around ~forever more. -- Garrett From casper@holland.sun.com Thu Oct 8 08:30:45 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98FUjMj012062 for ; Thu, 8 Oct 2009 08:30:45 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n98FUgSW010875; Thu, 8 Oct 2009 09:30:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700H0DCF83300@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 08:30:44 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700AY8CF6YFC0@nwk-avmta-2.sfbay.sun.com>; Thu, 08 Oct 2009 08:30:43 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98FUeVd011851; Thu, 08 Oct 2009 16:30:40 +0100 (BST) Date: Thu, 08 Oct 2009 17:30:36 +0200 From: Casper.Dik@sun.com Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACE0459.1030806@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: Joerg Schilling , peter.tribble@gmail.com, PSARC-ext@sun.com, gd78059@sac.sfbay.sun.com Message-id: <200910081530.n98FUeVd011851@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> <4ACDF9E5.7010801@sun.com> <4acdfc98.ZjJxJmc99IhSHUhv%Joerg.Schilling@fokus.fraunhofer.de> <4ACE0459.1030806@sun.com> Status: RO Content-Length: 534 >It's quite possible that this is all just a vain effort to tilt at >windmills, but I at least wanted to have the *discussion*. This seemed >like a rare opportunity to have such a discussion. If we deliver >Solaris.next with these components, then its likely that another >opportunity to discuss it might not come along for a *long* time. True; certainly I think that we should minimally remove the symbolic links and the headers. I think we've added most of the stuff missing in libc finally (alphasort, scandir) Casper From peter.tribble@gmail.com Thu Oct 8 08:38:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98FcgOP012130 for ; Thu, 8 Oct 2009 08:38:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98FccOe002911; Thu, 8 Oct 2009 16:38:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700007CSE9Z00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Oct 2009 08:38:38 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700BXMCSEEKE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 08 Oct 2009 08:38:38 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n98FUkC3002305; Thu, 08 Oct 2009 15:38:38 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-457729; Thu, 08 Oct 2009 15:38:38 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-67230768; Thu, 08 Oct 2009 15:38:37 +0000 (Z) Received: from mail-yx0-f203.google.com ([209.85.210.203] [209.85.210.203]) by relay1i.sun.com with ESMTP id BT-MMP-4591067; Thu, 08 Oct 2009 15:38:37 +0000 (Z) Received: by yxe41 with SMTP id 41so12554938yxe.30 for ; Thu, 08 Oct 2009 08:38:33 -0700 (PDT) Received: by 10.100.235.4 with SMTP id i4mr1524452anh.101.1255016313883; Thu, 08 Oct 2009 08:38:33 -0700 (PDT) Date: Thu, 08 Oct 2009 16:38:33 +0100 From: Peter Tribble Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACDF9E5.7010801@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aGXg5qdy6RPBLdrLWCw/K+la9p6+hOq9Y28/qAb/cOc=; b=s78Z1rjPME9hYtDBiibFXYp96uxgDlvLy4AHl+/Q+Lc3JBT3sL0JrmSzIfzKjtdfIw h1BWlHgx2O7N5b/JM5Pv24ptJM0MmCyTxmmHefaSZx3vFvpzgpPs4EWhkLgYiQHZC+uR 64LZALWzk5loJNDaieibkQ+355gCpL7t89UxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i1CB0h1p9qDPlDPFvYUD5BgaFxnWVbOipn53FtwkXBQB20FRE3JdbFEDz3WtsVXgKL IhVSlSMNRldGgdmkuK4PbG03DhqBObkoBExGMVfMWve1gVYCkwsykO1ofA7ID7JxcFEZ rl86y6wlPVY7uhV5Mmvmr9SS5dkBeVg0suMgA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> <4ACDF9E5.7010801@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n98FcgOP012130 Status: RO Content-Length: 2980 On Thu, Oct 8, 2009 at 3:40 PM, Garrett D'Amore wrote: > Okay, corrected I stand.  Although I *suspect* this problem could be > corrected too.  The library is coming in via the libc, not via the > application pulling it in directly.  (So if the relevant 4lib libraries were > compiled to use normal libc, or got the important bits of libucb linked in > directly, then wouldn't that resolve the main concern here?) Well, it would split the /usr/ucblib issue from the SunOS 4 binary compatibility issue. Which would at least clarify the aim of this case. You would then be happy to keep the binary compatibility for SunOS 4 in, while breaking compatibility for SunOS 5.x apps? However, investigations on the systems I have access to indicates that the problem is actually more widespread than I initially imagined. I am seeing use of /usr/ucblib/libtermcap.so.1 and /usr/ucblib/libucb.so.1 on x86, and given that this location has only ever seen Solaris 10 on x86 that must have been due to software built recently. (Not by myself, either, so I may have to track it down.) On sparc, I can see usage of all the libraries in /usr/ucblib that isn't due to binary compatibility. (More recent than /usr/4lib, in other words.) > Peter Tribble wrote: >> >> On Thu, Oct 8, 2009 at 3:14 PM, Garrett D'Amore wrote: >> >>> >>> Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x >>> *binaries*.  I.e. if you have a SunOS 4.x binary, it looks like you get >>> the >>> libraries in /usr/4lib, using the a.out exec module.  I don't think you >>> wind >>> up using any of the ELF stuff in /usr/ucblib. >>> >> >> % ldd /usr/4lib/libc.so.1.9 >>        libucb.so.1 =>   /usr/ucblib/libucb.so.1 >>        libc.so.1 =>     /lib/libc.so.1 >>        libnsl.so.1 =>   /lib/libnsl.so.1 >>        libsocket.so.1 =>        /lib/libsocket.so.1 >>        libelf.so.1 =>   /lib/libelf.so.1 >>        libmp.so.2 =>    /lib/libmp.so.2 >>        libmd.so.1 =>    /lib/libmd.so.1 >>        libscf.so.1 =>   /lib/libscf.so.1 >>        libdoor.so.1 =>  /lib/libdoor.so.1 >>        libuutil.so.1 =>         /lib/libuutil.so.1 >>        libgen.so.1 =>   /lib/libgen.so.1 >>        libm.so.2 =>     /lib/libm.so.2 >>        /platform/SUNW,T5140/lib/libc_psr.so.1 >>        /platform/SUNW,T5140/lib/libmd_psr.so.1 >> >> % dump -Lv /usr/4lib/libc.so.1.9 >> >> /usr/4lib/libc.so.1.9: >> >>  **** DYNAMIC SECTION INFORMATION **** >> .dynamic: >> [INDEX] Tag         Value >> [1]     NEEDED          libucb.so.1 >> [2]     NEEDED          libc.so.1 >> [3]     NEEDED          libnsl.so.1 >> [4]     NEEDED          libsocket.so.1 >> [5]     INIT            0x42f7c >> [6]     FINI            0x42f90 >> [7]     SONAME          libc.so.1.9 >> [8]     RUNPATH         /usr/ucblib >> [9]     RPATH           /usr/ucblib >> ... >> >> It's definitely pulling libucb in. >> >> > > -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From gdamore@sun.com Thu Oct 8 08:55:46 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98FtjLC012549 for ; Thu, 8 Oct 2009 08:55:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n98FtgEO028275 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 09:55:45 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70080PDKWB400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 09:55:44 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LGYDKVIRD5@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 09:55:43 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98Fth9t016255 for ; Thu, 08 Oct 2009 08:55:43 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700700D9K2P00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 08:55:43 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR700LELDKEV3B0@fe-sfbay-09.sun.com>; Thu, 08 Oct 2009 08:55:27 -0700 (PDT) Date: Thu, 08 Oct 2009 08:55:26 -0700 From: "Garrett D'Amore" Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: Sender: Garrett.Damore@sun.com To: Peter Tribble Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4ACE0B6E.1080605@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> <4ACDF9E5.7010801@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4283 Peter Tribble wrote: > On Thu, Oct 8, 2009 at 3:40 PM, Garrett D'Amore wrote: > >> Okay, corrected I stand. Although I *suspect* this problem could be >> corrected too. The library is coming in via the libc, not via the >> application pulling it in directly. (So if the relevant 4lib libraries were >> compiled to use normal libc, or got the important bits of libucb linked in >> directly, then wouldn't that resolve the main concern here?) >> > > Well, it would split the /usr/ucblib issue from the SunOS 4 binary > compatibility issue. > Which would at least clarify the aim of this case. You would then be > happy to keep > the binary compatibility for SunOS 4 in, while breaking compatibility > for SunOS 5.x > apps? > Only for SunOS 5.x apps that used this legacy compatibility library. These libraries were never intended to be used with "new" source code. They were only intended for use with /usr/ucb/cc. But that compiler is *gone*. We already have broken the source compatibility, therefore. It really shouldn't be such a big deal. > However, investigations on the systems I have access to indicates that > the problem > is actually more widespread than I initially imagined. > > I am seeing use of /usr/ucblib/libtermcap.so.1 and > /usr/ucblib/libucb.so.1 on x86, > and given that this location has only ever seen Solaris 10 on x86 that must have > been due to software built recently. (Not by myself, either, so I may > have to track > it down.) > Wow. That's really unfortunate. I can only imagine this is fallout from /usr/ucb/cc being in people's paths. This is a the main reason I've always advised against having /usr/ucb on your path at all, but only at the *end* if you absolutely must have it. These libraries have significant limitations, which is why they shouldn't be used. (For example, they aren't thread safe. The signal() implementation is not standard conforming. Etc.) > On sparc, I can see usage of all the libraries in /usr/ucblib that isn't due to > binary compatibility. (More recent than /usr/4lib, in other words.) > Can you help us identify some of the culprits? Are these locally compiled open source applications? Commercial applications? Or home grown software? Would any of these applications be seriously impaired by a requirement to either recompile "with the right flags", or to use S10 containers? Its possible that if this problem is as widespread as you claim, then this case cannot go forward. - Garrett > >> Peter Tribble wrote: >> >>> On Thu, Oct 8, 2009 at 3:14 PM, Garrett D'Amore wrote: >>> >>> >>>> Actually, looking at the code, I don't see how /usr/ucblib is used by 4.x >>>> *binaries*. I.e. if you have a SunOS 4.x binary, it looks like you get >>>> the >>>> libraries in /usr/4lib, using the a.out exec module. I don't think you >>>> wind >>>> up using any of the ELF stuff in /usr/ucblib. >>>> >>>> >>> % ldd /usr/4lib/libc.so.1.9 >>> libucb.so.1 => /usr/ucblib/libucb.so.1 >>> libc.so.1 => /lib/libc.so.1 >>> libnsl.so.1 => /lib/libnsl.so.1 >>> libsocket.so.1 => /lib/libsocket.so.1 >>> libelf.so.1 => /lib/libelf.so.1 >>> libmp.so.2 => /lib/libmp.so.2 >>> libmd.so.1 => /lib/libmd.so.1 >>> libscf.so.1 => /lib/libscf.so.1 >>> libdoor.so.1 => /lib/libdoor.so.1 >>> libuutil.so.1 => /lib/libuutil.so.1 >>> libgen.so.1 => /lib/libgen.so.1 >>> libm.so.2 => /lib/libm.so.2 >>> /platform/SUNW,T5140/lib/libc_psr.so.1 >>> /platform/SUNW,T5140/lib/libmd_psr.so.1 >>> >>> % dump -Lv /usr/4lib/libc.so.1.9 >>> >>> /usr/4lib/libc.so.1.9: >>> >>> **** DYNAMIC SECTION INFORMATION **** >>> .dynamic: >>> [INDEX] Tag Value >>> [1] NEEDED libucb.so.1 >>> [2] NEEDED libc.so.1 >>> [3] NEEDED libnsl.so.1 >>> [4] NEEDED libsocket.so.1 >>> [5] INIT 0x42f7c >>> [6] FINI 0x42f90 >>> [7] SONAME libc.so.1.9 >>> [8] RUNPATH /usr/ucblib >>> [9] RPATH /usr/ucblib >>> ... >>> >>> It's definitely pulling libucb in. >>> >>> >>> >> > > > > From gdamore@Sun.COM Thu Oct 8 11:28:03 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98IS2gl016452 for ; Thu, 8 Oct 2009 11:28:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n98IRZ3R006971 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 9 Oct 2009 02:28:02 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70000FKMPAV00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 12:28:01 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LAUKMOIMO5@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 12:28:00 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98IS0si006663 for ; Thu, 08 Oct 2009 11:28:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700500KBW3L00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 11:28:00 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR700BXSKMKXHC0@fe-sfbay-10.sun.com>; Thu, 08 Oct 2009 11:27:57 -0700 (PDT) Date: Thu, 08 Oct 2009 11:27:56 -0700 From: "Garrett D'Amore" Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACE0BE4.1060201@sun.com> Sender: Garrett.Damore@Sun.COM To: PSARC-ext Cc: "Garrett D'Amore - sun microsystems" Message-id: <4ACE2F2C.9040602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACE0975.7090507@Sun.COM> <4ACE0BE4.1060201@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7545 Btw, I just finished an analysis of what is in libucb. (I've not check the other libraries, most especially termcap, yet.) My findings show that there is a lot there that could simply trivially be eliminated. Here's the detailed analysis: First I started by comparing differences between libc and libucb implementations: Differences in libucb implementation ------------------------------------ psignal() - UCB flushes stderr first then calls libc version. The libc version uses an unbuffered write() to stderr (2). Note that the UCB flushing behavior is not documented. bcmp() - UCB Just calls stock _memcmp. No functional difference otherwise. Could be eliminated. bcopy() - UCB calls _memmove, if len > 0. Stock calls memmove unconditionally. Should not have any functional difference, and hence can be eliminated. ftime() - UCB asks gettimeofday for the local timezone, and uses it. libc optimizes by using local values within libc and a "guranteed to succeed" _ltzset(). Otherwise no functional difference. Could be eliminated. getwd() - Identical implementations. Could be eliminated. index() - UCB has local implementation, but libc just calls strchr. Could be eliminated. rindex() - UCB has local implementation, but libc just calls strrchr. Could be eliminated. nice() - UCB has local implementation based around setpriority() and getpriority(). libc uses a system call, and is hence less prone to races and faster. Calling semantics are identical, could probably be eliminated. nlist() - UCB has local implementation supporting COFF (a.out). This one we would have to continue to provide for legacy apps. rand() - Both use the same polynomial PRNG, but UCB returns the full result, whereas libc discards the lower 16 bits provides just 15 bits of randomness. (UCB returns 31 bits, although the lower bits are particularly random.) This difference could be enough to break poorly written applications, so this has to continue to be supplied. readdir() - Different implementations, but apparently identical semantics and structures. Could probably be eliminated. re_comp() re_exec() - These are backed by nearly identical sources, with just some stylistic and lint fixes (e.g. substituting 0 for NULL and casting). Could be eliminated. scandir() alphasort() - Nearly identical implementations, and identical semantics. Could be eliminated. setbuffer() setlinebuf() - UCB mucks in internals of libc stdio (urk!) libc just uses setvbuf(). This should almost certainly be eliminated, as nothing should be mucking around inside the internals of libc stdio structures. Semantically identical. (Note UCB version seems to have inlined copy of setvbuf code.) sys_siglist - UCB has this. libc has _sys_siglist. They are almost identical, except some of the strings are slightly different. Could probably be made an alias in UCB for _sys_siglist. statfs() fstatfs() - UCB implements on top of statvfs/fstatvfs. libc uses a syscall. Same semantics, could probably be eliminated. statfs64() fstatfs64() - Whoa?!? 64-bit versions of these calls, only provided by libucb. Not sure why, since no applications should ever use them. This looks like it was integrated at the time of the original 64-bit port, without ever making it available in any public API. These could probably safely be eliminated as they have never been documented. times() - Difference is value returned. UCB returns 0 on success, libc returns a tick count. Cannot be eliminated. wait4() - UCB returns EINVAL if options contains WCONTINUED, whereas libc allows (XPG4.2.) Otherwise they are identical. I think this could safely be eliminated. If not, it could be replaced with a thin wrapper which calls the libc version after checking for WCONTINUED in the options arg. wait3() - Both are just simple wrappers around wait3. Can be eliminated. flock() - Only UCB has it, as a thin wrapper around fcntl(). Perhaps we should provide it in libc as well? In the mean time we have to leave it. getdtablesize() - Identical implementations, could be removed. gethostid() - Functionally equivalent implementations. The libc version is slightly more efficient. The UCB version could be eliminated. gethostname() - Functionally identical, could be eliminated. sethostname() - Nearly identical, except UCB first checks to make sure uid == 0 and returns EPERM if not. (Same errno returned by syscall btw.) (Not RBAC compliant.) UCB version could be eliminated. getpagesize() - Identical implementations. Could be removed. killpg() - identical, except libc version takes pid_t instead of int for pgrp. However, binary they are identical, so UCB version could be eliminated. mctl() - UCB supplies thin wrapper around memcntl. Could be supplied in libc as well. Needs to stay otherwise. reboot() - both just call uadmin, after processing args. libc adds support for RB_DUMP that UCB lacks. libc also passes through boot arguments, whereas UCB suppresses them. Note however, that no applications are likely to be bothered by this difference. We could probably safely just eliminate the UCB wrapper. setpgrp() - Different calling conventions, we have to retain it. The UCB version is a trivial wrapper around setpgid. _doprnt() _getarg() _mkarglst() - These are private to internal libc STDIO. We should not need to export them. fopen() - UCB is functionally and semantically equivalent to libc. Could be removed. freopen() - Identical, except for libc XPG6 semantics that *might* be applied, optionally (and not relevant to legacy apps.) Also, libc is thread safe. UCB version could be removed. fopen64() - Huh? Another weird 64-bitified API that should never have happened and was never publicised. It should be safe to remove this. fprintf() printf() vfprintf() vprintf() - These are standards-conformat APIs. They should just work. The libc versions benefit from being MT async safe. The main other difference bewing that the libc version has some support for additional format specifiers. ("ll", "Q", "hh"). libc can also support wide characters. We can probably safely remove the UCB versions. vsprintf() sprintf() - Semantically identical, the UCB version can be removed. Summary: -------- Only the following functions are still required in libucb, as far as I can tell: nlist() rand() times() flock() (unless we provide one in libc) mctl() (unless we provide one in libc) reboot() (maybe, see comments above) setpgrp() Additionally, we'll have to have a linker alias for sys_siglist to point to libc's _sys_siglist. At this point, I think libucb becomes quite small indeed. From Andrew.Gabriel@sun.com Thu Oct 8 11:47:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98IkxEU017117 for ; Thu, 8 Oct 2009 11:47:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IkwLX013665 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 19:46:59 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70021DLIA6000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 12:46:58 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700L7JLI9IRS5@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 12:46:57 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98Ikujw007380 for ; Thu, 08 Oct 2009 18:46:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KR700E00LDQ7D00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 19:46:44 +0100 (BST) Received: from [81.187.162.109] ([unknown] [81.187.162.109]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KR700H5QLHW8T90@fe-emea-10.sun.com>; Thu, 08 Oct 2009 19:46:44 +0100 (BST) Date: Thu, 08 Oct 2009 19:47:22 +0100 From: Andrew Gabriel Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACE2F2C.9040602@sun.com> Sender: Andrew.Gabriel@sun.com To: "Garrett D'Amore" Cc: PSARC-ext , "Garrett D'Amore - sun microsystems" Message-id: <4ACE33BA.8090408@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACE0975.7090507@Sun.COM> <4ACE0BE4.1060201@sun.com> <4ACE2F2C.9040602@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1161 Garrett D'Amore wrote: > Btw, I just finished an analysis of what is in libucb. (I've not check > the other libraries, most especially termcap, yet.) My findings show > that there is a lot there that could simply trivially be eliminated. > Here's the detailed analysis: > > First I started by comparing differences between libc and libucb > implementations: > > Differences in libucb implementation > ------------------------------------ > statfs64() > fstatfs64() - Whoa?!? 64-bit versions of these calls, only provided > by libucb. Not sure why, since no applications should ever > use them. This looks like it was integrated at the time > of the original 64-bit port, without ever making it available > in any public API. These could probably safely be > eliminated as they have never been documented. They're invoked by stdio.h (transparently to the app) for 64 bit apps and LARGEFILE-aware 32 bit apps. > fopen64() - Huh? Another weird 64-bitified API that should never > have happened and was never publicised. It should be safe > to remove this. ditto. -- Andrew From casper@holland.sun.com Thu Oct 8 11:57:56 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98Ivubu017650 for ; Thu, 8 Oct 2009 11:57:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n98IvqNa029972; Thu, 8 Oct 2009 11:57:56 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70030HM0KAR00@brm-avmta-1.central.sun.com>; Thu, 08 Oct 2009 12:57:56 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LD7M0JILS5@brm-avmta-1.central.sun.com>; Thu, 08 Oct 2009 12:57:55 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98IvrGZ003798; Thu, 08 Oct 2009 19:57:53 +0100 (BST) Date: Thu, 08 Oct 2009 20:57:53 +0200 From: Casper.Dik@sun.com Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACE2F2C.9040602@sun.com> Sender: casper@holland.sun.com To: "Garrett D'Amore" Cc: PSARC-ext , "Garrett D'Amore - sun microsystems" Message-id: <200910081857.n98IvrGZ003798@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACE0975.7090507@Sun.COM> <4ACE0BE4.1060201@sun.com> <4ACE2F2C.9040602@sun.com> Status: RO Content-Length: 784 >readdir() - Different implementations, but apparently identical > semantics and structures. Could probably be eliminated. Nope, /usr/ucbinclude/sys/dir.h vs >re_comp() >re_exec() - These are backed by nearly identical sources, with just > some stylistic and lint fixes (e.g. substituting 0 for NULL > and casting). Could be eliminated. > >scandir() >alphasort() - Nearly identical implementations, and identical semantics. > Could be eliminated. See readdir. You're missing signal (different semantics) Issues with alloc (worst problem to debug at the time was that SunOS malloc uses the "buddy allocator" and it was very forgiving. Standard Solaris wasn't so forgiving. (But we have much better tools now) Casper From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Oct 8 12:31:09 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98JV76M019214 for ; Thu, 8 Oct 2009 12:31:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98JUw3i013677 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 20:31:07 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR70060BNJSMS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 13:31:04 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700L1NNJQIIL5@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 13:31:03 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n98JUvHR026009 for ; Thu, 08 Oct 2009 19:31:02 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay43i.sun.com with ESMTP id BT-MMP-3164060 for PSARC-ext@Sun.COM; Thu, 08 Oct 2009 19:30:57 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-49882332 for PSARC-ext@Sun.COM; Thu, 08 Oct 2009 19:30:56 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay4i.sun.com with ESMTP id BT-MMP-4391961 for PSARC-ext@Sun.COM; Thu, 08 Oct 2009 19:30:53 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 724B516008D; Thu, 08 Oct 2009 21:09:57 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 72FB816008D; Thu, 08 Oct 2009 21:09:53 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n98J9rKL017604; Thu, 08 Oct 2009 21:09:53 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 08 Oct 2009 21:09:53 +0200 Date: Thu, 08 Oct 2009 21:08:29 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACE2F2C.9040602@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: PSARC-ext@sun.com, gdamore@sun.com Cc: gd78059@sac.sfbay.sun.com Message-id: <4ace38ad.C8LeS5gtxrWrfEu6%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-1.1/5.0, scanned in 1.393sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACE0975.7090507@Sun.COM> <4ACE0BE4.1060201@sun.com> <4ACE2F2C.9040602@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 08 Oct 2009 19:09:53.0088 (UTC) FILETIME=[EA670400:01CA484A] Status: RO Content-Length: 1658 "Garrett D'Amore" wrote: > Differences in libucb implementation > ------------------------------------ > > nlist() - UCB has local implementation supporting COFF (a.out). This > one we would have to continue to provide for legacy apps. Note: COFF is not a.out. > readdir() - Different implementations, but apparently identical > semantics and structures. Could probably be eliminated. You can elimitate the UCB version only if you do the same as has been done on *BSD: include d_namelen in the syscall and fill it from kernel VFS level. USB struct dirent has d_namelen that is missing in the POSIX version. Otherwise, you need to at least call strlen(d_name) to set up d_namelen. > scandir() > alphasort() - Nearly identical implementations, and identical semantics. > Could be eliminated. See above: struct dirent differs > setbuffer() > setlinebuf() - UCB mucks in internals of libc stdio (urk!) libc just > uses > setvbuf(). This should almost certainly be eliminated, as > nothing should be mucking around inside the internals of > libc stdio structures. Semantically identical. (Note > UCB version seems to have inlined copy of setvbuf code.) This may be a result from a different sprintf() implementation to allow to get the buffer string. > wait3() - Both are just simple wrappers around wait3. Can > be eliminated. They did differ for SunOS-5.0 > setpgrp() - Different calling conventions, we have to retain it. The > UCB version is a trivial wrapper around setpgid. Don't forget getpgrp() From bsh/bshconf.h: Status: RO Content-Length: 2223 * BSD: * * getpgrp(pid) -> pgid for pid * setpgrp(pid, pgid) -> set pgid of pid * * POSIX: * * getpgid(pid) -> pgid for pid * setpgid(pid, pgid) -> set pgid of pid * getpgrp(void) -> pgid for $$ * setpgrp(void) -> setpgid(0,0) * * 4.4-BSD: * * getpgid(pid) -> is missing! * setpgid(pid, pgid) -> set pgid of pid * getpgrp(void) -> ???? * setpgrp(pid, pgid) -> set pgid of pid > fopen() - UCB is functionally and semantically equivalent to libc. > Could be removed. Except for probably different FILE *, did you check this? > freopen() - Identical, except for libc XPG6 semantics that *might* be > applied, optionally (and not relevant to legacy apps.) > Also, libc is thread safe. UCB version could be removed. > > fopen64() - Huh? Another weird 64-bitified API that should never > have happened and was never publicised. It should be safe > to remove this. Maybe a Sun UCB utility has been made large file aware? > fprintf() > printf() > vfprintf() > vprintf() - These are standards-conformat APIs. They should just work. > The libc versions benefit from being MT async safe. The > main other difference bewing that the libc version has some > support for additional format specifiers. ("ll", "Q", > "hh"). libc can also support wide characters. > We can probably safely remove the UCB versions. > > vsprintf() > sprintf() - Semantically identical, the UCB version can be removed. Be careful, David Korn ans I do not have own printf() iplementations to grant 100% portability. There may be problems if you let a UCB program use the POSIX implementation. Note: UCB sprintf() returns char * instead of int. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Thu Oct 8 12:38:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98JcocO019260 for ; Thu, 8 Oct 2009 12:38:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98Jcgpq018117 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 8 Oct 2009 20:38:49 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700803NWNTL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 12:38:47 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700748NWMOA10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 08 Oct 2009 12:38:46 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n98Jcjto014607 for ; Thu, 08 Oct 2009 19:38:45 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-3674217 for PSARC-ext@sun.com; Thu, 08 Oct 2009 19:38:45 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-65054268 for PSARC-ext@sun.com; Thu, 08 Oct 2009 19:38:45 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-36517614 for PSARC-ext@sun.com; Thu, 08 Oct 2009 19:38:44 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 581DF6F0512; Thu, 08 Oct 2009 21:38:43 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 22B2A6F047D; Thu, 08 Oct 2009 21:38:42 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n98JcgC7018000; Thu, 08 Oct 2009 21:38:42 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 08 Oct 2009 21:38:42 +0200 Date: Thu, 08 Oct 2009 21:37:16 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ace38ad.C8LeS5gtxrWrfEu6%Joerg.Schilling@fokus.fraunhofer.de> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: PSARC-ext@sun.com, gdamore@sun.com Cc: gd78059@sac.sfbay.sun.com Message-id: <4ace3f6c.OoleLxtRvhLyXvOR%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACE0975.7090507@Sun.COM> <4ACE0BE4.1060201@sun.com> <4ACE2F2C.9040602@sun.com> <4ace38ad.C8LeS5gtxrWrfEu6%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 08 Oct 2009 19:38:42.0079 (UTC) FILETIME=[F0F61AF0:01CA484E] Status: RO Content-Length: 619 Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote: > Be careful, David Korn ans I do not have own printf() iplementations to grant > 100% portability. There may be problems if you let a UCB program use the POSIX > implementation. > Sorry for the typo: "David Korn and I do have own printf() iplementations.." Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Rod.Evans@sun.com Thu Oct 8 14:37:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n98LbQ5v023618 for ; Thu, 8 Oct 2009 14:37:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n98LbNZo008455; Thu, 8 Oct 2009 22:37:24 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR700J03TEBOG00@brm-avmta-1.central.sun.com>; Thu, 08 Oct 2009 15:37:23 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700LQ3TEAIN26@brm-avmta-1.central.sun.com>; Thu, 08 Oct 2009 15:37:23 -0600 (MDT) Received: from [129.146.228.120] (chaz.SFBay.Sun.COM [129.146.228.120]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n98LbMKO871313; Thu, 08 Oct 2009 14:37:22 -0700 (PDT) Date: Thu, 08 Oct 2009 14:40:26 -0700 From: Rod Evans Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] To: PSARC-ext@sun.com, gdamore@sun.com Reply-to: Rod.Evans@sun.com Message-id: <4ACE5C4A.5040704@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 2275 There is a large body of code, and a bunch of vectoring through tables, within ld.so.1 that support the loading/relocation and symbol lookup of 4.x applications. There's AOUT processing in exec() and mmapobj() too. And we've had oodles of fun massaging the Unified Process Model into being able to cope with two lib's within the same process (required to support sbcp's dependencies and the 4.x app). I've wanted to nuke the ld.so.1 4.x stuff a number of times, and as recently as the mmapobj() project, visited the subject again. Yes, we had to do extra work in mmpobj to make sure 4.x objects could be mapped - was it worth the effort? It's always been interesting to learn that 4.x binaries still exist. Some live in the bin directories of those watching this alias (you know who you are :-). And it wasn't so long ago that we relied on them internally (the netinstall "addclient" I recall?). Which has always made us wonder, if *we're* still using 4.x binaries then might our customers be using them too? The result is that I always backed down and left the 4.x stuff (at least in ld.so.1) as it was. I like the idea of a branded zone. I don't have a concrete opinion on the 4.x support. If there was a time for its removal, now seems as good as any. And it would certainly simplify some of my life. The counter argument is that it works (to some degree - there are only a handful of binaries I know of that I ever use to verify it's functionality), and that some customer might still be using it. The trouble is that we think it needs no more support, ie. the code's done, but mmapobj() proved we had to go do extra work to keep supporting it. I'd really like to not have to visit 4.x again. One question I've always had is why do we keep building the libraries etc? For example, to support 4.x we have /usr/lib/ld.so, which is a 4.x binary (which we probably couldn't rebuild again if we tried, the last 4.x machine I know of got taken off the net long ago), so why couldn't we package up the 4.x components and simply not build them again. We haven't changed them in years, have we? If a customer wanted them we could point them at the package, but beyond that, they're done, and they'd be out of our source base. Just thinking out loud. -- Rod. From peter.tribble@gmail.com Tue Oct 13 13:11:06 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9DKB42D008546 for ; Tue, 13 Oct 2009 13:11:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9DKB1K3026000; Tue, 13 Oct 2009 21:11:02 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRG00K05YQDIS00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Oct 2009 13:11:01 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRG0082JYQD1490@nwk-avmta-1.sfbay.Sun.COM>; Tue, 13 Oct 2009 13:11:01 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9DK5RSw005339; Tue, 13 Oct 2009 20:11:00 +0000 (GMT) Received: from mmp41es.mmp.us.syntegra.com ([160.41.221.10] [160.41.221.10]) by relay41i.sun.com with ESMTP id BT-MMP-832570; Tue, 13 Oct 2009 20:11:00 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mmp41es.mmp.us.syntegra.com with ESMTP id BT-MMP-616610; Tue, 13 Oct 2009 20:10:55 +0000 (Z) Received: from mail-yw0-f199.google.com ([209.85.211.199] [209.85.211.199]) by relay4i.sun.com with ESMTP id BT-MMP-2745519; Tue, 13 Oct 2009 20:10:55 +0000 (Z) Received: by ywh37 with SMTP id 37so10515745ywh.17 for ; Tue, 13 Oct 2009 13:09:42 -0700 (PDT) Received: by 10.100.55.18 with SMTP id d18mr6469035ana.80.1255464582552; Tue, 13 Oct 2009 13:09:42 -0700 (PDT) Date: Tue, 13 Oct 2009 21:09:42 +0100 From: Peter Tribble Subject: Re: EOF of libucb [PSARC/2009/541 OnePager] In-reply-to: <4ACE0B6E.1080605@sun.com> To: "Garrett D'Amore" Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5qkBZ4t1jza085OZYY/t4MYXXmouMC7pt0QhfkOKeu8=; b=w59sjr5Qxze+WzJlhbKK6NSWbyPWRdYxtZCXvrTxGyDAQYqp6ODE1iV4YvwUOpL1Bu 9GNEda/kwIUPgDGDBlJ3fdnIf50o1AZsOSZ9TVSfNscupKoTCNSvD8c16do4/jZVhhcn ZKHnEE5/3yuyaFjwu4YBaHX2diCaVY54a1De4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wLUUYx/C0FK1t5va35liDCd4naRy43yJhfUudrYNHWyE8cEV1lHvNetRbuYczCKQUK eT+YondyliFxRSNtYD8ApOQt+7g7eXlhcD3LWrgil46Unl2IbG5ka9IAsPbIZHFZFXwy OHy72q/yV9TfKzcVqWzf1VU+OryIr2DNsKBes= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-0.7/5.0, scanned in 3.868sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910080724.n987OBne002203@sac.sfbay.sun.com> <4ACDEC9C.9040204@sun.com> <4ACDF3C9.7030207@sun.com> <4ACDF9E5.7010801@sun.com> <4ACE0B6E.1080605@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n9DKB42D008546 Status: RO Content-Length: 2694 On Thu, Oct 8, 2009 at 4:55 PM, Garrett D'Amore wrote: > Peter Tribble wrote: > >> I am seeing use of  /usr/ucblib/libtermcap.so.1 and >> /usr/ucblib/libucb.so.1 on x86, >> and given that this location has only ever seen Solaris 10 on x86 that >> must have >> been due to software built recently. (Not by myself, either, so I may >> have to track >> it down.) >> > > Wow.  That's really unfortunate.  I can only imagine this is fallout from > /usr/ucb/cc being in people's paths.  This is a the main reason I've always > advised against having /usr/ucb on your path at all, but only at the *end* > if you absolutely must have it. Unfortunately, that's not so. I've removed cc/lint/ld from /usr/ucb during installation on any system I've used for many years; no user would have logged into a system here and been able to build software using /usr/ucb/cc because it plain doesn't exist. Something must be explicitly linking against it rather than accidentally getting it via /usr/ucb/cc. >> On sparc, I can see usage of all the libraries in /usr/ucblib that isn't >> due to >> binary compatibility. (More recent than /usr/4lib, in other words.) >> > > Can you help us identify some of the culprits?  Are these locally compiled > open source applications?  Commercial applications?  Or home grown software? I can try. On the systems I'm currently evaluating for migration onto something more modern, it's mostly commercial applications by the looks of it. Almost nothing locally compiled or home grown, although there may be some stuff imported from elsewhere. If I have anything I'm allowed to share I'll follow up; I'm still doing a preliminary audit. > Would any of these applications be seriously impaired by a requirement to > either recompile "with the right flags", or to use S10 containers? No source, so no recompile, in many cases. Sometimes it's just been lost. Not everything runs in containers. Take clearcase as an example; you need a certain patch level to run it on S10 in the global zone; you need to go further to run it in a native zone; branded zones are out. And sometimes you have to run multiple applications together. Sometimes you have to co-locate an NFS server. (It's a shame you can't apply a brand to a process: that would be a very neat way to get linux apps to run alongside normal apps; and would provide an elegant way to get compatibility for certain applications without prejudicing the entire OS.) > Its possible that if this problem is as widespread as you claim, then this > case cannot go forward. It's more widespread than I feared, at any rate. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/