Message ID | 20231123180246.750674-1-dimitri.ledkov@canonical.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:ce62:0:b0:403:3b70:6f57 with SMTP id o2csp620742vqx; Thu, 23 Nov 2023 10:03:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IH8k1PhHWKegKyftzdn4A1pGPxU3O94tusLJ2em9dYsysOJtGFL64V3SIaaISOBgIHLYCjj X-Received: by 2002:a05:6820:80a:b0:587:992d:48b with SMTP id bg10-20020a056820080a00b00587992d048bmr336351oob.1.1700762597031; Thu, 23 Nov 2023 10:03:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700762597; cv=none; d=google.com; s=arc-20160816; b=n/QQbKf9qBpGqd++rAEsms/1NPCrp3eSwpR3fuQuv2X1W4g26GII+66Flk3vQG+wvE r6KSUjintFVyuQduBqSKjt8IwBRBVksNBZuR/N0iq7oXzpXCPNYyyd6aCVBLVOn4vJ5E 7T+n3yjCdc2It0tzl41sBGbUvTkoLvgG+9RLOzZgfpkSB7c+ZH+Jp7ZhXzrMgRR5Uy8c CEmcI8tr1r+oN4RVddlmBwC5R3JzB3AKQhe/lTKKhZWGLd/SIND0P28xqIrzCcCtbgIL NxCZ33r5iRpW/b2D1/N30arDe/bwYs2rV/7uXQ/7EvgjuBthEXrV95Qtr/kdCmRmOe2W oh4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=WP2gJh9IkDa2VdWPrUfJ2njFac/+S8Z+9AfzFJLFWoY=; fh=Ko90S6CcquqsKV5pBC25n2aB8JM02zepEUn8C/ehD7Y=; b=U7qM11t7YsTv53xHkFDZYwq2IkwaS8K7HpePRxGXkL8m9SD9V3ChLqoIAkYghqvK/4 uCT2LPhpW8dcG0uNk//P4E1KK30zSeQPY557nvqHrIkG2pn0pRwaAltencDc/JeQio4R nfpPWWO3Ve58OZaxzNaWa788HcVH0Fj+FwlW/Wg/bkX7KfKoZDxpB6qVg6mIt7QatvGJ l9vHnj5oCmTpsTP4GWru+dIFlssMZtProLK4RgzyRJ2rrGrt4kGoExO0DBtPGf+5PeSQ r/g+CHl3Lc9ZCZPkbAMEX4KApF44/y1szOZThndUiocXwUuQUt+W7l8azZ9FJY09+S6h REZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=f5Ldjv9p; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id h19-20020a4a6f13000000b00581dedb92a3si570725ooc.28.2023.11.23.10.03.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 10:03:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; dkim=pass header.i=@canonical.com header.s=20210705 header.b=f5Ldjv9p; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id EB46D80A144C; Thu, 23 Nov 2023 10:03:06 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230156AbjKWSC4 (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Thu, 23 Nov 2023 13:02:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229903AbjKWSCz (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 23 Nov 2023 13:02:55 -0500 Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A97AD41 for <linux-kernel@vger.kernel.org>; Thu, 23 Nov 2023 10:03:01 -0800 (PST) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 6D0DA40DB3 for <linux-kernel@vger.kernel.org>; Thu, 23 Nov 2023 18:02:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1700762579; bh=WP2gJh9IkDa2VdWPrUfJ2njFac/+S8Z+9AfzFJLFWoY=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=f5Ldjv9pUGqSgaGbA0bva+KuxN5R/wfZYGWZigFaI5BSBiBxH5oMVv05vSdDwbbGs mNaUtc1uuRJCKiYgpDsyQd/OoRMZ1QaIQ8omijKEgphE2HYNWknfB/lb7KqU9YKWUx LTRgA9iDA1Jbs37JEMpXifXhsrJhZiEYRBNrwjGuJd/QdiJtNUPtykA9Brsfp4beyE ewqFqJeEg6KZgHTj+O1O2lIEHv+Tqql/n/5+jrJ4INwwng/+PKAIh7XT7QzENIyD2h bxRq/hdl+oPi26s8TSnyTSRqTG/LdE5RrPo2RFDBrHSHjGOT5n2zlMh8A555wk2zPH 5WyGIAsIyw4tw== Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-40b310b5453so6026615e9.1 for <linux-kernel@vger.kernel.org>; Thu, 23 Nov 2023 10:02:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700762579; x=1701367379; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WP2gJh9IkDa2VdWPrUfJ2njFac/+S8Z+9AfzFJLFWoY=; b=GQKw/mYVJRHMP0aKKc04GR3Qj6Gyypc7yX74KtpBK98AueMB9hQejI9FMEINCsjRd/ EzPqjGTE0x+LaYNX8CpOJ4nV6bKkvj/qE0IBOSJgd/hdek6IJib3sG5TfoNengODCDtu BVkMAjJIVsYv3e7e/KUcTMlwHy8X7U+99hOoPBPepfb2uJE4Nsvf2GxslZykYtx1yL6V 0MzSG4qX8nUpEilyOv4dtREugWSEtCj0hbLsYX2nIx99ex3lNR00GlcJ4WSYkyUzedXD hd1reXix/rIc1UXgJQXZ63eRFjbyqTvTHJRB7gl/FbL7BpxcCraWVisLQi1HaI9Barkj zaLQ== X-Gm-Message-State: AOJu0Yz91RWp4mU8nTZiRfz4eik1SDI4GRiKc+8ClfsbjOPRXohMPDTt D0Z2dHAlndPWmvZoVZWuIvak/10Z/k6TzVmG8Yb20ys1AS+Mn2d18A/F2EZ0r2d4HJyqEVnj2s1 /1cIBDFYmE0MWCgE9aWdy1Xc7otUIOc4N7rviokGWSg== X-Received: by 2002:a5d:69cd:0:b0:332:c548:3ea4 with SMTP id s13-20020a5d69cd000000b00332c5483ea4mr141112wrw.49.1700762578974; Thu, 23 Nov 2023 10:02:58 -0800 (PST) X-Received: by 2002:a5d:69cd:0:b0:332:c548:3ea4 with SMTP id s13-20020a5d69cd000000b00332c5483ea4mr141097wrw.49.1700762578644; Thu, 23 Nov 2023 10:02:58 -0800 (PST) Received: from localhost ([2001:67c:1560:8007::aac:c15c]) by smtp.gmail.com with ESMTPSA id j14-20020adff54e000000b0032db8cccd3asm2302599wrp.114.2023.11.23.10.02.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Nov 2023 10:02:58 -0800 (PST) From: Dimitri John Ledkov <dimitri.ledkov@canonical.com> To: Richard Henderson <richard.henderson@linaro.org>, Ivan Kokshaysky <ink@jurassic.park.msu.ru>, Matt Turner <mattst88@gmail.com>, Geert Uytterhoeven <geert@linux-m68k.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, "H . Peter Anvin" <hpa@zytor.com> Cc: linux-alpha@vger.kernel.org, linux-m68k@lists.linux-m68k.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/5] remove the last bits of a.out support Date: Thu, 23 Nov 2023 18:02:40 +0000 Message-Id: <20231123180246.750674-1-dimitri.ledkov@canonical.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 23 Nov 2023 10:03:07 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783378841175289136 X-GMAIL-MSGID: 1783378841175289136 |
Series | remove the last bits of a.out support | |
Message
Dimitri John Ledkov
Nov. 23, 2023, 6:02 p.m. UTC
I was working on how linux-libc-dev headers are shipped in Ubuntu and stumbled upon seemingly unused and useless linux/a.out.h header. It seems like it is an accidental leftover at this point. Dimitri John Ledkov (5): alpha: remove a.out support from tools/objstrip alpha: stop shipping a.out.h uapi headers m68k: stop shipping a.out.h uapi headers x86: stop shipping a.out.h uapi headers uapi: remove a.out.h uapi header arch/alpha/boot/tools/objstrip.c | 52 +----- arch/alpha/include/uapi/asm/a.out.h | 92 ---------- arch/m68k/include/uapi/asm/a.out.h | 21 --- arch/x86/include/uapi/asm/a.out.h | 21 --- include/uapi/Kbuild | 4 - include/uapi/linux/a.out.h | 251 ---------------------------- 6 files changed, 6 insertions(+), 435 deletions(-) delete mode 100644 arch/alpha/include/uapi/asm/a.out.h delete mode 100644 arch/m68k/include/uapi/asm/a.out.h delete mode 100644 arch/x86/include/uapi/asm/a.out.h delete mode 100644 include/uapi/linux/a.out.h
Comments
Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes: > I was working on how linux-libc-dev headers are shipped in Ubuntu and > stumbled upon seemingly unused and useless linux/a.out.h header. It > seems like it is an accidental leftover at this point. How do you see that they are unused? Are they never exported to userspace? Are there any userspace programs that care? Performing a quick debian code search I see chromium, qt6, ruby-rogue, hurd, bazel_bootstrap, aboot, cde. I can imagine all kinds of reasons old code could be using headers for a historical format. Some of them are quite legitimate, and some of them are quite silly. If it is old code like aboot it may be that it is difficult to test any changes. If memory serves you have to flash your firmware to change/test aboot. Because showing userspace does not care about the definitions in a file is a completely different problem then showing the kernel does not care about the definitions I left them, last time I was working in this area. Keeping headers that will never change is not cost to the kernel so it doesn't hurt us to be nice to historical userspace. My quick debian code search suggests that there are pieces of userspace that still use linux/a.out.h. Are you seeing something I am not? Do all of those pieces of code compile just fine with a.out.h missing? Eric > Dimitri John Ledkov (5): > alpha: remove a.out support from tools/objstrip > alpha: stop shipping a.out.h uapi headers > m68k: stop shipping a.out.h uapi headers > x86: stop shipping a.out.h uapi headers > uapi: remove a.out.h uapi header > > arch/alpha/boot/tools/objstrip.c | 52 +----- > arch/alpha/include/uapi/asm/a.out.h | 92 ---------- > arch/m68k/include/uapi/asm/a.out.h | 21 --- > arch/x86/include/uapi/asm/a.out.h | 21 --- > include/uapi/Kbuild | 4 - > include/uapi/linux/a.out.h | 251 ---------------------------- > 6 files changed, 6 insertions(+), 435 deletions(-) > delete mode 100644 arch/alpha/include/uapi/asm/a.out.h > delete mode 100644 arch/m68k/include/uapi/asm/a.out.h > delete mode 100644 arch/x86/include/uapi/asm/a.out.h > delete mode 100644 include/uapi/linux/a.out.h
On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes: > > > I was working on how linux-libc-dev headers are shipped in Ubuntu and > > stumbled upon seemingly unused and useless linux/a.out.h header. It > > seems like it is an accidental leftover at this point. > > How do you see that they are unused? > > Are they never exported to userspace? > > Are there any userspace programs that care? > > Performing a quick debian code search I see chromium, qt6, ruby-rogue, hurd, > bazel_bootstrap, aboot, cde. > > I can imagine all kinds of reasons old code could be using headers for a > historical format. Some of them are quite legitimate, and some of them > are quite silly. If it is old code like aboot it may be that it is > difficult to test any changes. If memory serves you have to flash your > firmware to change/test aboot. > > Because showing userspace does not care about the definitions in a file > is a completely different problem then showing the kernel does not care > about the definitions I left them, last time I was working in this area. > Keeping headers that will never change is not cost to the kernel so it > doesn't hurt us to be nice to historical userspace. > > My quick debian code search suggests that there are pieces of userspace > that still use linux/a.out.h. Are you seeing something I am not? > Do all of those pieces of code compile just fine with a.out.h missing? > I will recheck the above mentioned things again, but as far as I could tell up to this point, is that things mostly use a.out.h provided by glibc. Separately, I can do this change in a test-rebuild of ubuntu archive of all packages on amd64,. as that's the only Ubuntu arch that ships linux/a.out.h. As far as I can tell, the legacy userspace access to linux/a.out.h can use glibc's a.out.h instead. But yes, it would be pain, if code changes are required to things. > Eric > > > > Dimitri John Ledkov (5): > > alpha: remove a.out support from tools/objstrip > > alpha: stop shipping a.out.h uapi headers > > m68k: stop shipping a.out.h uapi headers I think above three patches still can be merged in m68k & alpha trees. > > x86: stop shipping a.out.h uapi headers > > uapi: remove a.out.h uapi header > > And these two need further validation now, based on Eric's input. > > arch/alpha/boot/tools/objstrip.c | 52 +----- > > arch/alpha/include/uapi/asm/a.out.h | 92 ---------- > > arch/m68k/include/uapi/asm/a.out.h | 21 --- > > arch/x86/include/uapi/asm/a.out.h | 21 --- > > include/uapi/Kbuild | 4 - > > include/uapi/linux/a.out.h | 251 ---------------------------- > > 6 files changed, 6 insertions(+), 435 deletions(-) > > delete mode 100644 arch/alpha/include/uapi/asm/a.out.h > > delete mode 100644 arch/m68k/include/uapi/asm/a.out.h > > delete mode 100644 arch/x86/include/uapi/asm/a.out.h > > delete mode 100644 include/uapi/linux/a.out.h
On Fri, 24 Nov 2023 at 14:36, Dimitri John Ledkov <dimitri.ledkov@canonical.com> wrote: > > On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@xmission.com> wrote: > > > > Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes: > > > > > I was working on how linux-libc-dev headers are shipped in Ubuntu and > > > stumbled upon seemingly unused and useless linux/a.out.h header. It > > > seems like it is an accidental leftover at this point. > > > > How do you see that they are unused? When I did my code search the only and last remaining userspace code that imports linux/a.out.h it is the objtool that is patched in these patch series. It is also vendored as copy in aboot tool, which has been patched in many downstreams to use a.out.h instead of linux/a.out.h. > > > > Are they never exported to userspace? > > Yes it is exported for user-code to compile against. The question is if any of them import it, or use it. > > Are there any userspace programs that care? Just the alpha objstrip tool in these series. > > > > Performing a quick debian code search I see chromium, qt6, ruby-rogue, hurd, > > bazel_bootstrap, aboot, cde. > > chromium qt6 bazel cde - vendor a full linux source tree with manifests, to build actual linux kernel as offered by a vendored project or for bootstrapping toolchains. These are all unused by the resulting userspace. aboot - has the copy of arch/alpha/boot/tools/objstrip.c which is patched in these series, to support booting a.out based alpha which is gone. So self-referencing. ruby-rogue is syntax highlight for Syzlang which is kernel syscall fuzzing language, by definition it highlights things inside kernel, and thus will be unused highlight code for kernel sources that dropped a.out.h support and will do correctly syntax highlight for syszlang source code that targets a.out.h capable kernels. hurd - it is a pfinet server based on a vendored copy of linux source tree, with its own copy of linux/a.out.h and its own copy of affs_fs_i.h. It is based on the linux 2.2.12 partial tree. If they upgrade networking code to a newer linux copy, it will be gone there too. > > I can imagine all kinds of reasons old code could be using headers for a > > historical format. Some of them are quite legitimate, and some of them > > are quite silly. If it is old code like aboot it may be that it is > > difficult to test any changes. If memory serves you have to flash your > > firmware to change/test aboot. > > > > Because showing userspace does not care about the definitions in a file > > is a completely different problem then showing the kernel does not care > > about the definitions I left them, last time I was working in this area. > > Keeping headers that will never change is not cost to the kernel so it > > doesn't hurt us to be nice to historical userspace. > > > > My quick debian code search suggests that there are pieces of userspace > > that still use linux/a.out.h. Are you seeing something I am not? Was your search https://codesearch.debian.net/search?q=linux%2Fa.out.h&literal=1&perpkg=1 ? In which case none of them are header imports as compiled into any of the userspace code. They are all vendored copies of linux code, either unused or compiled as a kernel. > > Do all of those pieces of code compile just fine with a.out.h missing? > > Yes, as none of them import it =) with objstrip being the last one. > > I will recheck the above mentioned things again, but as far as I could > tell up to this point, is that things mostly use a.out.h provided by > glibc. > > Separately, I can do this change in a test-rebuild of ubuntu archive > of all packages on amd64,. as that's the only Ubuntu arch that ships > linux/a.out.h. > > As far as I can tell, the legacy userspace access to linux/a.out.h can > use glibc's a.out.h instead. But yes, it would be pain, if code > changes are required to things. > > > Eric > > > > > > > Dimitri John Ledkov (5): > > > alpha: remove a.out support from tools/objstrip > > > alpha: stop shipping a.out.h uapi headers > > > m68k: stop shipping a.out.h uapi headers > > I think above three patches still can be merged in m68k & alpha trees. > > > > x86: stop shipping a.out.h uapi headers > > > uapi: remove a.out.h uapi header > > > > > And these two need further validation now, based on Eric's input. I believe all examples Eric pointed out are false-positives of Linux source tree itself dating back to copies of 2.1.22. Thus this should all be merged. > > > > arch/alpha/boot/tools/objstrip.c | 52 +----- > > > arch/alpha/include/uapi/asm/a.out.h | 92 ---------- > > > arch/m68k/include/uapi/asm/a.out.h | 21 --- > > > arch/x86/include/uapi/asm/a.out.h | 21 --- > > > include/uapi/Kbuild | 4 - > > > include/uapi/linux/a.out.h | 251 ---------------------------- > > > 6 files changed, 6 insertions(+), 435 deletions(-) > > > delete mode 100644 arch/alpha/include/uapi/asm/a.out.h > > > delete mode 100644 arch/m68k/include/uapi/asm/a.out.h > > > delete mode 100644 arch/x86/include/uapi/asm/a.out.h > > > delete mode 100644 include/uapi/linux/a.out.h
On Fri, Nov 24, 2023 at 12:00:15AM -0600, Eric W. Biederman wrote: > Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes: > If it is old code like aboot it may be that it is > difficult to test any changes. If memory serves you have to flash your > firmware to change/test aboot. No, aboot is written to the first sectors of the boot disk. Yes, there is a special utilty in the aboot tools to write aboot to the boot sectors and make sure that there is no overlap with the first partition. Cheers Michael.
Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes: > On Fri, 24 Nov 2023 at 14:36, Dimitri John Ledkov > <dimitri.ledkov@canonical.com> wrote: >> >> On Fri, 24 Nov 2023 at 06:01, Eric W. Biederman <ebiederm@xmission.com> wrote: >> > >> > Dimitri John Ledkov <dimitri.ledkov@canonical.com> writes: >> > >> > > I was working on how linux-libc-dev headers are shipped in Ubuntu and >> > > stumbled upon seemingly unused and useless linux/a.out.h header. It >> > > seems like it is an accidental leftover at this point. >> > >> > How do you see that they are unused? > > When I did my code search the only and last remaining userspace code > that imports linux/a.out.h it is the objtool that is patched in these > patch series. > It is also vendored as copy in aboot tool, which has been patched in > many downstreams to use a.out.h instead of linux/a.out.h. It sounds like you have done your homework. Please just document (as you in your reply to me) in your cover letter or elsewhere in the changes so that it is clear that due diligence has been performed and userspace should not break with this change. [snip] > Was your search > https://codesearch.debian.net/search?q=linux%2Fa.out.h&literal=1&perpkg=1 > ? Pretty much. I didn't have the perpkg=1. Debian code search is the most comprehensive code search I am aware of so I took a quick look. Since it appears the only users are vendored versions of linux/a.out.h then it should be possible to make this change without breaking userspace. If it turns that is wrong the changes can be reverted. Eric