From owner-freebsd-arch@FreeBSD.ORG Tue Feb 22 00:12:48 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C539016A4CE; Tue, 22 Feb 2005 00:12:48 +0000 (GMT) Received: from 62-151-34-101.yaonline.ya.com (62-151-34-101.yaonline.ya.com [62.151.34.101]) by mx1.FreeBSD.org (Postfix) with SMTP id 2748943D39; Tue, 22 Feb 2005 00:11:11 +0000 (GMT) (envelope-from vrtauj@pobox.sk) Received: from 243.144.252.6 by 62.151.34.101; Mon, 21 Feb 2005 23:05:29 -0100 Message-ID: From: "Blanca Daugherty" To: freebsd-arch@freebsd.org, freebsd-sparc@freebsd.org, re@freebsd.org, freebsd-ppc@freebsd.org Date: Tue, 22 Feb 2005 02:05:29 +0200 MIME-Version: 1.0 X-AntiAbuse: Send msg to 2a_mullion@exitomy.com w/ "COMPLAINT" in subject Content-Type: text/plain; Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Hard as a rock X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Blanca Daugherty List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 00:12:48 -0000 New ph_armac_y on the block -- Cheap gene_rics for E.D., anxiety, pain, & more: http://2aenglewood.vereylongviagra.info/in.php?aid=3D117 http://2aenglewood.vereylongviagra.info/in.php?aid=3D117 http://2aenglewood.vereylongviagra.info/in.php?aid=3D117 http://2aenglewood.vereylongviagra.info/in.php?aid=3D117 http://2aenglewood.vereylongviagra.info/in.php?aid=3D117 http://2aenglewood.vereylongviagra.info/in.php?aid=3D117 combustible minus locust eagan determinate hinduism electret peruse clang crime valerie monocular believe carruthers curt cruise ultra asymptote darwin vocate belgrade exquisite lackey blake Get 0ff 0f this Llst: http://2aenglewood.vereylongviagra.info/fgh.php From owner-freebsd-arch@FreeBSD.ORG Tue Feb 22 21:32:44 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E460616A4CE for ; Tue, 22 Feb 2005 21:32:44 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E700A43D2F for ; Tue, 22 Feb 2005 21:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j1MLWUlP015564 for ; Tue, 22 Feb 2005 14:32:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 22 Feb 2005 14:32:30 -0700 (MST) Message-Id: <20050222.143230.41648746.imp@bsdimp.com> To: arch@freebsd.org From: Warner Losh X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 21:32:45 -0000 Greetings, >From time to time, the concept of a binary driver has been floated. The idea would be that a vendor could put out a binary driver disk when there were bugs in the drivers for a specific release so that users impacted by those bugs could still, for example, install that specific release. However, most of the drivers in the base system do not allow this to happen because they return 0. At the same time, we have a number of generic drivers in the tree that have been using ad-hoc values to make sure that the right driver gets attached (see for example pci and acpi pci, and friends). We also have some drivers that overlap ranges of devices (eg, ncr and sym drivers). So, I'd like to standardize on some names, and thought I'd post here my first cut at the names. Let's not get too far off in the weeds, since names is a prime bike-shed topic[*]. I'll likely ignore most of that part of the discussion, and focus on the more technical and/or political side of things. If possible, I'd like to have this wrapped up in time for 5.4, but I do understand that time is extremely short for that. /** * Some convenience defines for probe routines to return. These are * just suggested values, and there's nothing magical about them. * BUS_PROBE_SPECIFIC is for devices that cannot be reprobed, and that * no possible other driver may exist (typically legacy drivers who * don't fallow all the rules, or special needs drivers). BUS_PROBE_VENDOR * is the suggested value that vendor supplied drivers use. This is * for source or binary drivers that are not yet integrated into the FreeBSD * tree. Its use in the base OS is prohibited. BUS_PROBE_DEFAULT is * the normal return value for drivers to use. It is intended that nearly * all of the drivers in the tree should return this value. * BUS_PROBE_LOW_PRIORITY are for drivers that have special requirements * like when there are two drivers that support overlapping series of * hardware devices. In this case the one that supports the older part * of the line would return this value, while the one that supports the newer * ones would return BUS_PROBE_DEFAULT. BUS_PROBE_GENERIC is for drivers * that wish to have a generic form and a specialized form, like is done * with the pci bus and that acpi pci bus. BUS_PROBE_HOOVER is for those * busses that implement a generic device placeholder for devices on the * bus that have no more specific driver for them (aka ugen). */ #define BUS_PROBE_SPECIFIC 0 /* Only I can use this device */ #define BUS_PROBE_VEDNOR (-10) /* Vendor supplied driver */ #define BUS_PROBE_DEFAULT (-20) /* Base OS default driver */ #define BUS_PROBE_LOW_PRIORITY (-40) /* Older, less desirable drivers */ #define BUS_PROBE_GENERIC (-100) /* generic driver for dev */ #define BUS_PROBE_HOOVER (-500) /* Generic dev for all devs on bus */ Comments? Warner [*] And I really don't like the idea of there being a 20 message sub-thread on HOOVER vs VACUUM vs KIRBEE or is that KIRBE, and it was really so and so that invented the vacuum, etc. Please disappoint me by not having one :-) From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 14:31:33 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C19E616A4CE for ; Wed, 23 Feb 2005 14:31:33 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69DFA43D5E for ; Wed, 23 Feb 2005 14:31:32 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.13.3/8.13.3) with ESMTP id j1NEVT03023855 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 23 Feb 2005 15:31:29 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.3/8.13.3/Submit) id j1NEVTaV023854 for arch@freebsd.org; Wed, 23 Feb 2005 15:31:29 +0100 (CET) Date: Wed, 23 Feb 2005 15:31:29 +0100 From: Divacky Roman To: arch@freebsd.org Message-ID: <20050223143129.GA23805@stud.fit.vutbr.cz> References: <20050222.143230.41648746.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050222.143230.41648746.imp@bsdimp.com> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 14:31:33 -0000 On Tue, Feb 22, 2005 at 02:32:30PM -0700, Warner Losh wrote: > Greetings, > > >From time to time, the concept of a binary driver has been floated. > The idea would be that a vendor could put out a binary driver disk > when there were bugs in the drivers for a specific release so that > users impacted by those bugs could still, for example, install that > specific release. > > However, most of the drivers in the base system do not allow this to > happen because they return 0. > > At the same time, we have a number of generic drivers in the tree that > have been using ad-hoc values to make sure that the right driver gets > attached (see for example pci and acpi pci, and friends). We also > have some drivers that overlap ranges of devices (eg, ncr and sym > drivers). > > So, I'd like to standardize on some names, and thought I'd post here > my first cut at the names. Let's not get too far off in the weeds, > since names is a prime bike-shed topic[*]. I'll likely ignore most of > that part of the discussion, and focus on the more technical and/or > political side of things. If possible, I'd like to have this wrapped > up in time for 5.4, but I do understand that time is extremely short > for that. > > /** > * Some convenience defines for probe routines to return. These are > * just suggested values, and there's nothing magical about them. > * BUS_PROBE_SPECIFIC is for devices that cannot be reprobed, and that > * no possible other driver may exist (typically legacy drivers who > * don't fallow all the rules, or special needs drivers). BUS_PROBE_VENDOR > * is the suggested value that vendor supplied drivers use. This is > * for source or binary drivers that are not yet integrated into the FreeBSD > * tree. Its use in the base OS is prohibited. BUS_PROBE_DEFAULT is > * the normal return value for drivers to use. It is intended that nearly > * all of the drivers in the tree should return this value. > * BUS_PROBE_LOW_PRIORITY are for drivers that have special requirements > * like when there are two drivers that support overlapping series of > * hardware devices. In this case the one that supports the older part > * of the line would return this value, while the one that supports the newer > * ones would return BUS_PROBE_DEFAULT. BUS_PROBE_GENERIC is for drivers > * that wish to have a generic form and a specialized form, like is done > * with the pci bus and that acpi pci bus. BUS_PROBE_HOOVER is for those > * busses that implement a generic device placeholder for devices on the > * bus that have no more specific driver for them (aka ugen). > */ > #define BUS_PROBE_SPECIFIC 0 /* Only I can use this device */ > #define BUS_PROBE_VEDNOR (-10) /* Vendor supplied driver */ ^^ typo... From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 18:09:51 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F17D16A4CE for ; Wed, 23 Feb 2005 18:09:51 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDDA743D48 for ; Wed, 23 Feb 2005 18:09:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24415 invoked from network); 23 Feb 2005 18:09:50 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 23 Feb 2005 18:09:49 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1NI9d82024140; Wed, 23 Feb 2005 13:09:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 23 Feb 2005 12:57:12 -0500 User-Agent: KMail/1.6.2 References: <20050222.143230.41648746.imp@bsdimp.com> In-Reply-To: <20050222.143230.41648746.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502231257.12798.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 18:09:51 -0000 On Tuesday 22 February 2005 04:32 pm, Warner Losh wrote: > Greetings, > > >From time to time, the concept of a binary driver has been floated. > > The idea would be that a vendor could put out a binary driver disk > when there were bugs in the drivers for a specific release so that > users impacted by those bugs could still, for example, install that > specific release. > > However, most of the drivers in the base system do not allow this to > happen because they return 0. > > At the same time, we have a number of generic drivers in the tree that > have been using ad-hoc values to make sure that the right driver gets > attached (see for example pci and acpi pci, and friends). We also > have some drivers that overlap ranges of devices (eg, ncr and sym > drivers). > > So, I'd like to standardize on some names, and thought I'd post here > my first cut at the names. Let's not get too far off in the weeds, > since names is a prime bike-shed topic[*]. I'll likely ignore most of > that part of the discussion, and focus on the more technical and/or > political side of things. If possible, I'd like to have this wrapped > up in time for 5.4, but I do understand that time is extremely short > for that. > > /** > * Some convenience defines for probe routines to return. These are > * just suggested values, and there's nothing magical about them. > * BUS_PROBE_SPECIFIC is for devices that cannot be reprobed, and that > * no possible other driver may exist (typically legacy drivers who > * don't fallow all the rules, or special needs drivers). BUS_PROBE_VENDOR > * is the suggested value that vendor supplied drivers use. This is > * for source or binary drivers that are not yet integrated into the > FreeBSD * tree. Its use in the base OS is prohibited. BUS_PROBE_DEFAULT > is * the normal return value for drivers to use. It is intended that > nearly * all of the drivers in the tree should return this value. > * BUS_PROBE_LOW_PRIORITY are for drivers that have special requirements > * like when there are two drivers that support overlapping series of > * hardware devices. In this case the one that supports the older part > * of the line would return this value, while the one that supports the > newer * ones would return BUS_PROBE_DEFAULT. BUS_PROBE_GENERIC is for > drivers * that wish to have a generic form and a specialized form, like is > done * with the pci bus and that acpi pci bus. BUS_PROBE_HOOVER is for > those * busses that implement a generic device placeholder for devices on > the * bus that have no more specific driver for them (aka ugen). > */ > #define BUS_PROBE_SPECIFIC 0 /* Only I can use this device */ > #define BUS_PROBE_VEDNOR (-10) /* Vendor supplied driver */ > #define BUS_PROBE_DEFAULT (-20) /* Base OS default driver */ > #define BUS_PROBE_LOW_PRIORITY (-40) /* Older, less desirable drivers */ > #define BUS_PROBE_GENERIC (-100) /* generic driver for dev */ > #define BUS_PROBE_HOOVER (-500) /* Generic dev for all devs on bus */ > > Comments? > > Warner > > [*] And I really don't like the idea of there being a 20 message > sub-thread on HOOVER vs VACUUM vs KIRBEE or is that KIRBE, and it was > really so and so that invented the vacuum, etc. Please disappoint me > by not having one :-) Several typos, but that's minor. Sounds ok to me. Note that I think BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers are actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, MPTable, and generic for example), but for more tricky cases we can still use numeric values. s/HOOVER/ROOBA/ :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 18:09:51 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76C7416A4CF for ; Wed, 23 Feb 2005 18:09:51 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDF0343D49 for ; Wed, 23 Feb 2005 18:09:50 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24415 invoked from network); 23 Feb 2005 18:09:50 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 23 Feb 2005 18:09:49 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1NI9d82024140; Wed, 23 Feb 2005 13:09:44 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Wed, 23 Feb 2005 12:57:12 -0500 User-Agent: KMail/1.6.2 References: <20050222.143230.41648746.imp@bsdimp.com> In-Reply-To: <20050222.143230.41648746.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502231257.12798.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 18:09:51 -0000 On Tuesday 22 February 2005 04:32 pm, Warner Losh wrote: > Greetings, > > >From time to time, the concept of a binary driver has been floated. > > The idea would be that a vendor could put out a binary driver disk > when there were bugs in the drivers for a specific release so that > users impacted by those bugs could still, for example, install that > specific release. > > However, most of the drivers in the base system do not allow this to > happen because they return 0. > > At the same time, we have a number of generic drivers in the tree that > have been using ad-hoc values to make sure that the right driver gets > attached (see for example pci and acpi pci, and friends). We also > have some drivers that overlap ranges of devices (eg, ncr and sym > drivers). > > So, I'd like to standardize on some names, and thought I'd post here > my first cut at the names. Let's not get too far off in the weeds, > since names is a prime bike-shed topic[*]. I'll likely ignore most of > that part of the discussion, and focus on the more technical and/or > political side of things. If possible, I'd like to have this wrapped > up in time for 5.4, but I do understand that time is extremely short > for that. > > /** > * Some convenience defines for probe routines to return. These are > * just suggested values, and there's nothing magical about them. > * BUS_PROBE_SPECIFIC is for devices that cannot be reprobed, and that > * no possible other driver may exist (typically legacy drivers who > * don't fallow all the rules, or special needs drivers). BUS_PROBE_VENDOR > * is the suggested value that vendor supplied drivers use. This is > * for source or binary drivers that are not yet integrated into the > FreeBSD * tree. Its use in the base OS is prohibited. BUS_PROBE_DEFAULT > is * the normal return value for drivers to use. It is intended that > nearly * all of the drivers in the tree should return this value. > * BUS_PROBE_LOW_PRIORITY are for drivers that have special requirements > * like when there are two drivers that support overlapping series of > * hardware devices. In this case the one that supports the older part > * of the line would return this value, while the one that supports the > newer * ones would return BUS_PROBE_DEFAULT. BUS_PROBE_GENERIC is for > drivers * that wish to have a generic form and a specialized form, like is > done * with the pci bus and that acpi pci bus. BUS_PROBE_HOOVER is for > those * busses that implement a generic device placeholder for devices on > the * bus that have no more specific driver for them (aka ugen). > */ > #define BUS_PROBE_SPECIFIC 0 /* Only I can use this device */ > #define BUS_PROBE_VEDNOR (-10) /* Vendor supplied driver */ > #define BUS_PROBE_DEFAULT (-20) /* Base OS default driver */ > #define BUS_PROBE_LOW_PRIORITY (-40) /* Older, less desirable drivers */ > #define BUS_PROBE_GENERIC (-100) /* generic driver for dev */ > #define BUS_PROBE_HOOVER (-500) /* Generic dev for all devs on bus */ > > Comments? > > Warner > > [*] And I really don't like the idea of there being a 20 message > sub-thread on HOOVER vs VACUUM vs KIRBEE or is that KIRBE, and it was > really so and so that invented the vacuum, etc. Please disappoint me > by not having one :-) Several typos, but that's minor. Sounds ok to me. Note that I think BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers are actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, MPTable, and generic for example), but for more tricky cases we can still use numeric values. s/HOOVER/ROOBA/ :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 20:51:04 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1672916A4CE; Wed, 23 Feb 2005 20:51:04 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 391D943D5C; Wed, 23 Feb 2005 20:51:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j1NKoH8h045182; Wed, 23 Feb 2005 13:50:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 23 Feb 2005 13:50:17 -0700 (MST) Message-Id: <20050223.135017.74708574.imp@bsdimp.com> To: jhb@FreeBSD.ORG From: Warner Losh In-Reply-To: <200502231257.12798.jhb@FreeBSD.org> References: <20050222.143230.41648746.imp@bsdimp.com> <200502231257.12798.jhb@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG cc: freebsd-arch@FreeBSD.ORG Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 20:51:04 -0000 > Several typos, but that's minor. Sounds ok to me. Note that I think > BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers are > actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, MPTable, > and generic for example), but for more tricky cases we can still use numeric > values. > Well, on x86 we have 3 different pci busses, but they aren't in any more complicated a heirarchy than 'generic' or something that replaces 'generic.' You won't have PCIBIOS and MPTable fighting for control of a system, will you? > s/HOOVER/ROOBA/ :) :-) Warner From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 20:51:04 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1672916A4CE; Wed, 23 Feb 2005 20:51:04 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 391D943D5C; Wed, 23 Feb 2005 20:51:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j1NKoH8h045182; Wed, 23 Feb 2005 13:50:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 23 Feb 2005 13:50:17 -0700 (MST) Message-Id: <20050223.135017.74708574.imp@bsdimp.com> To: jhb@FreeBSD.ORG From: Warner Losh In-Reply-To: <200502231257.12798.jhb@FreeBSD.org> References: <20050222.143230.41648746.imp@bsdimp.com> <200502231257.12798.jhb@FreeBSD.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG cc: freebsd-arch@FreeBSD.ORG Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 20:51:04 -0000 > Several typos, but that's minor. Sounds ok to me. Note that I think > BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers are > actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, MPTable, > and generic for example), but for more tricky cases we can still use numeric > values. > Well, on x86 we have 3 different pci busses, but they aren't in any more complicated a heirarchy than 'generic' or something that replaces 'generic.' You won't have PCIBIOS and MPTable fighting for control of a system, will you? > s/HOOVER/ROOBA/ :) :-) Warner From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 21:44:44 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E90D516A4CE for ; Wed, 23 Feb 2005 21:44:44 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84A2E43D58 for ; Wed, 23 Feb 2005 21:44:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 319 invoked from network); 23 Feb 2005 21:44:44 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 23 Feb 2005 21:44:43 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1NLibD5025453; Wed, 23 Feb 2005 16:44:38 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Warner Losh Date: Wed, 23 Feb 2005 16:38:46 -0500 User-Agent: KMail/1.6.2 References: <20050222.143230.41648746.imp@bsdimp.com> <200502231257.12798.jhb@FreeBSD.org> <20050223.135017.74708574.imp@bsdimp.com> In-Reply-To: <20050223.135017.74708574.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502231638.46128.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 21:44:45 -0000 On Wednesday 23 February 2005 03:50 pm, Warner Losh wrote: > > Several typos, but that's minor. Sounds ok to me. Note that I think > > BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers > > are actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, > > MPTable, and generic for example), but for more tricky cases we can still > > use numeric values. > > Well, on x86 we have 3 different pci busses, but they aren't in any > more complicated a heirarchy than 'generic' or something that replaces > 'generic.' You won't have PCIBIOS and MPTable fighting for control of > a system, will you? Yes, you do. MPTable is just preferred to PCIBIOS, and ACPI is preferred to PCIBIOS. MPTable probably should be preferred to ACPI though (since MPTable's probe is only going to succeed if we are using the MPTable to enumerate APICs, in which case we can't trust ACPI's interrupt routing) though I might have this one wrong. All three are preferred over the generic bridge driver. Actually, the ACPI vs. MPTable case is probably a bit more muddy than that. It's probably wrong now. We shouldn't ever use those two together, but I'm not sure how best to do that. I don't think that is currently an issue though because I don't know of any machines that include an MP Table and ACPI but don't include an MADT table in ACPI. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Feb 23 21:44:45 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F011916A4CF for ; Wed, 23 Feb 2005 21:44:44 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 848CF43D54 for ; Wed, 23 Feb 2005 21:44:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 319 invoked from network); 23 Feb 2005 21:44:44 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 23 Feb 2005 21:44:43 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1NLibD5025453; Wed, 23 Feb 2005 16:44:38 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Warner Losh Date: Wed, 23 Feb 2005 16:38:46 -0500 User-Agent: KMail/1.6.2 References: <20050222.143230.41648746.imp@bsdimp.com> <200502231257.12798.jhb@FreeBSD.org> <20050223.135017.74708574.imp@bsdimp.com> In-Reply-To: <20050223.135017.74708574.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502231638.46128.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: arch@FreeBSD.org cc: freebsd-arch@FreeBSD.org Subject: Re: Better device probe values X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 21:44:45 -0000 On Wednesday 23 February 2005 03:50 pm, Warner Losh wrote: > > Several typos, but that's minor. Sounds ok to me. Note that I think > > BUS_PROBE_GENERIC might not really be enough though (PCI bridge drivers > > are actually somewhat tricky, on x86 for PCI-PCI you have ACPI, PCIBIOS, > > MPTable, and generic for example), but for more tricky cases we can still > > use numeric values. > > Well, on x86 we have 3 different pci busses, but they aren't in any > more complicated a heirarchy than 'generic' or something that replaces > 'generic.' You won't have PCIBIOS and MPTable fighting for control of > a system, will you? Yes, you do. MPTable is just preferred to PCIBIOS, and ACPI is preferred to PCIBIOS. MPTable probably should be preferred to ACPI though (since MPTable's probe is only going to succeed if we are using the MPTable to enumerate APICs, in which case we can't trust ACPI's interrupt routing) though I might have this one wrong. All three are preferred over the generic bridge driver. Actually, the ACPI vs. MPTable case is probably a bit more muddy than that. It's probably wrong now. We shouldn't ever use those two together, but I'm not sure how best to do that. I don't think that is currently an issue though because I don't know of any machines that include an MP Table and ACPI but don't include an MADT table in ACPI. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Thu Feb 24 06:24:59 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C6916A4CE; Thu, 24 Feb 2005 06:24:58 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39FB543D41; Thu, 24 Feb 2005 06:24:58 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j1O6Oo95015511; Thu, 24 Feb 2005 01:24:50 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> Date: Thu, 24 Feb 2005 01:24:49 -0500 To: freebsd-arch@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) cc: Maxim Sobolev cc: "David G. Lawrence" Subject: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 06:24:59 -0000 Sometimes it's the simplest little changes which can suck the life out of you... I am aware that this is a trivial issue, but now that I've figured out what is really going on, I am not sure what the "best" fix would be. To recap some history: a) In Jan 2000, someone sent in a PR that perl documentation (including the famous "Camel" book from O'Reilly) claims that users can start a script with the line: #!/bin/sh -- # -*- perl -*- -p to avoid a variety of issues when writing cross-platform scripts. Ignore the question of "but why?" for the moment, it *is* documented by perl (and in books on some other scripting languages). He proposed a fix, and that was committed to src/sys/kern/imgact_shell.c as revision 1.21 back in Feb 15 2000 (predating 4.0-release). It was MFC'ed into release 3.5 on March 20, 2000. The PR is: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16393 NOTE: People *do* use this "feature". Counter: This feature doesn't actually work on recent releases of Redhat Linux. I don't know about other linuxes. b) In 2002, some other user updated that PR saying that the new behavior wasn't quite right either. I assume nothing much was done at the time, but he spent time to collect a lot of details (which will be given below). c) In 2004, after 5.3-release, the issue came up again. I assume that is in another PR, but I haven't checked. In any case, kern/imgact_shell.c was changed to remove that special processing for '#, after discussion in -current. The change was committed to HEAD (6.x) on October 31st as revision 1.27. It was MFC'ed to 5.3-stable on November 8th. This broke scripts which depended on the special-handling of '#', but the conclusion in -current was that /bin/sh should handle such processing (if it wanted to), and not execve(). d) In January I was finally bitten by this running 6.x-current, and a friend of mine happened to get hit by it at the same time running 5.3-stable. So I wrote up a quick fix and did some minimal testing. I posted that to -current on Jan 31st, but I didn't want to commit it until I did more testing, which I wanted to do *after* I brought my systems up-to-date. e) On January 29th, sobomax committed an "unrelated" fix to kern/imgact_shell.c, except that it just happened to bring back the special '#' processing which had been removed in October... f) I update my systems, do extensive testing of my patch, and I committed it once I was confident it worked in all situations. However, I didn't notice that the shell was no longer even *seeing* the parameters after '#' (I had tested that part back in #d), so it turns out the key loop I that had added was never actually getting triggered. I committed it to 6.x-current last week. g) On Monday I get ready to MFC the change to 5.3 (ahead of the rush to beat the code-freeze!). But... the damn thing does NOT work right in some common situations!! WTF?!? So, I figure out all the above history, and I locally modify kern/imgact_shell.c to again remove the special '#'-processing. I go to fix my patch to /bin/sh, and I realize... There is no simple, "make everyone happy" fix for it. Sigh. The problem is in the way the execve() system call passes all arguments to the shell. Given a shell named /tmp/list_args.pl, which starts out as: #!/bin/sh -x -- # -*- perl -*- -p and is executed via: /tmp/list_args.pl aaa bbb What /bin/sh sees for arguments are: arg[0] == '-x' arg[1] == '--' arg[2] == '#' arg[3] == '-*-' arg[4] == 'perl' arg[5] == '-*-' arg[6] == '-p' arg[7] == '/tmp/list_args.pl' arg[8] == 'aaa' arg[9] == 'bbb' The problem is that /bin/sh has no way of knowing where the "shebang-line options" end, and the "command-line options" start. (or does it? I couldn't think of any reliable way, given that the '#' could be followed by any totally arbitrary strings). Going back to the follow-up to PR 16393, part of the challenge with fixing this is that many other OS's do *not* break up the options on the shebang line the way FreeBSD does. From the PR: Given a file called '/tmp/x2' with shebang line: #!/tmp/interp -a -b -c #dee eee If /tmp/x2 is exec'd, the operating system runs /tmp/interp with the following arguments: Solaris 8: args: "/tmp/interp" "-a" "/tmp/x2" Tru64 4.0: args: "interp" "-a -b -c #dee eee" "/tmp/x2" FreeBSD 2.2.7: args: "/tmp/interp" "-a" "-b" "-c" "#dee" "eee" "/tmp/x2" FreeBSD 4.0: args: "/tmp/interp" "-a" "-b" "-c" "/tmp/x2" Linux 2.4.12: args: "/tmp/interp" "-a -b -c #dee eee" "/tmp/x2" Linux 2.2.19: args: "interp" "-a -b -c #dee eee" "/tmp/x2" Irix 6.5: args: "/tmp/interp" "-a -b -c #dee eee" "/tmp/x2" HPUX 11.00: args: "/tmp/x2" "-a -b -c #dee eee" "/tmp/x2" AIX 4.3: args: "interp" "-a -b -c #dee eee" "/tmp/x2" Mac OX X: args: "interp" "-a -b -c #dee eee" "/tmp/x2" The most common behavior is: argv[0]: full path of interpreter argv[1]: all remaining args, coalesced into one string argv[2]: The file file exec'd. The change committed back in 2000 made the comment: "This complies to POSIX 1003.2, in that Posix says the implementation is free to choose whatever it likes.". I actually like the idea that FreeBSD splits up the arguments from the shebang-line, but that leaves us with the problem of figuring out shebang-options from user-specified options given on the command-line. As I see it, we have the following choices to fix this: 1) MFC the January 31st change to kern/imgact_shell.c to 5.3-stable, as it is. This means we haven't fixed the problem that people complained about in 2002 and again in 2004. And I still think it is "not appropriate" for the execve() system to be deciding what '#' means on that line. The biggest advantage is that this means 5.4-release will behave exactly the same as 3.5 through 5.3-release have behaved. 2) Remove '#'-processing from kern/imgact_shell.c, and remove my change to bin/sh/options.c (which doesn't work right once we do that). This breaks shell-scripts which use the feature as documented by perl (and other scripting languages), and fixes the problem people complained about in 2002/2004. 3) Change kern/imgact_shell.c to process shebang options the same way other (non-BSD?) operating systems do. By that I mean: send the entire string as arg[1], and let the scripting language sort it out. This is an incompatible change from FreeBSD 5.3 to 5.4, but would put make us "more consistent" with other operating systems. 4) Provide some way for /bin/sh to find out where the shebang options end, and the user-specified options begin. This could make everyone happy, but it's more work and right now (this close to 5.4-release) that wouldn't make me particularly happy... Or we could do #1 for now, and plan to do #4 after 5.4-release. Or do #1 now in 5.3, and go with some incompatible change (#2 or #3) only in 6.x-current. What do people think? I know this is a mind-numbingly trivial issue to care about, but I figured that if I just went ahead with any particular solution, someone would be irritated with me and assume I must not have understood "the issues". They will then commit yet *another* change which undoes whatever I did, while they fix something they feel that I broke. And if nothing else, this is proof that one can't just blindly MFC some change, no matter now trivial it seems. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Thu Feb 24 10:29:26 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155E616A4CE; Thu, 24 Feb 2005 10:29:26 +0000 (GMT) Received: from dglawrence.com (dsl-230-156.ipns.com [209.210.230.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ADD243D31; Thu, 24 Feb 2005 10:29:23 +0000 (GMT) (envelope-from dg@dglawrence.com) Received: from opteron.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.13.3/8.13.1) with ESMTP id j1OATKlQ002505; Thu, 24 Feb 2005 02:29:20 -0800 (PST) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by opteron.dglawrence.com (8.13.3/8.13.1/Submit) id j1OATKgW002504; Thu, 24 Feb 2005 02:29:20 -0800 (PST) (envelope-from dg@dglawrence.com) Date: Thu, 24 Feb 2005 02:29:20 -0800 From: "David G. Lawrence" To: Garance A Drosihn Message-ID: <20050224102920.GD766@opteron.dglawrence.com> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: Maxim Sobolev cc: freebsd-arch@FreeBSD.ORG Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 10:29:26 -0000 > The change committed back in 2000 made the comment: "This complies > to POSIX 1003.2, in that Posix says the implementation is free to > choose whatever it likes.". I actually like the idea that FreeBSD > splits up the arguments from the shebang-line, but that leaves us > with the problem of figuring out shebang-options from user-specified > options given on the command-line. > > As I see it, we have the following choices to fix this: > > 1) MFC the January 31st change to kern/imgact_shell.c to 5.3-stable, > as it is. This means we haven't fixed the problem that people > complained about in 2002 and again in 2004. And I still think > it is "not appropriate" for the execve() system to be deciding > what '#' means on that line. The biggest advantage is that this > means 5.4-release will behave exactly the same as 3.5 through > 5.3-release have behaved. > > 2) Remove '#'-processing from kern/imgact_shell.c, and remove my > change to bin/sh/options.c (which doesn't work right once we > do that). This breaks shell-scripts which use the feature as > documented by perl (and other scripting languages), and fixes > the problem people complained about in 2002/2004. > > 3) Change kern/imgact_shell.c to process shebang options the same > way other (non-BSD?) operating systems do. By that I mean: > send the entire string as arg[1], and let the scripting > language sort it out. This is an incompatible change from > FreeBSD 5.3 to 5.4, but would put make us "more consistent" > with other operating systems. > > 4) Provide some way for /bin/sh to find out where the shebang > options end, and the user-specified options begin. This could > make everyone happy, but it's more work and right now (this > close to 5.4-release) that wouldn't make me particularly happy... Probably the best option is #3. That's actually how I wrote the code originally, but then changed it to parse out the arguments individually when I realized that any interpreter would have to be specially written to do its own argument processing otherwise - and that didn't seem right. I recall having a discussion with someone about it at the time, but it was so long ago (12 years!) that I can't remember how it went. I doubt that any standard component of FreeBSD will be affected by this, but of course that needs to be verified. Great job on the investigation, BTW. Well done!. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 24 11:00:32 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FC4516A4CF; Thu, 24 Feb 2005 11:00:32 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D02043D3F; Thu, 24 Feb 2005 11:00:31 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([192.168.2.2]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1OAXtGi082900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2005 11:33:56 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <421DAD8F.6000704@portaone.com> Date: Thu, 24 Feb 2005 12:33:51 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: Maxim Sobolev cc: "David G. Lawrence" cc: freebsd-arch@FreeBSD.ORG Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 11:00:32 -0000 Garance A Drosihn wrote: > Sometimes it's the simplest little changes which can suck the > life out of you... I am aware that this is a trivial issue, > but now that I've figured out what is really going on, I am > not sure what the "best" fix would be. > > To recap some history: > > a) In Jan 2000, someone sent in a PR that perl documentation > (including the famous "Camel" book from O'Reilly) claims > that users can start a script with the line: > > #!/bin/sh -- # -*- perl -*- -p > > to avoid a variety of issues when writing cross-platform > scripts. Ignore the question of "but why?" for the moment, > it *is* documented by perl (and in books on some other > scripting languages). He proposed a fix, and that was > committed to src/sys/kern/imgact_shell.c as revision 1.21 > back in Feb 15 2000 (predating 4.0-release). It was MFC'ed > into release 3.5 on March 20, 2000. > > The PR is: > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=16393 > > NOTE: People *do* use this "feature". > Counter: This feature doesn't actually work on recent > releases of Redhat Linux. I don't know about > other linuxes. > > b) In 2002, some other user updated that PR saying that the > new behavior wasn't quite right either. I assume nothing > much was done at the time, but he spent time to collect > a lot of details (which will be given below). > > c) In 2004, after 5.3-release, the issue came up again. I assume > that is in another PR, but I haven't checked. In any case, > kern/imgact_shell.c was changed to remove that special > processing for '#, after discussion in -current. The change > was committed to HEAD (6.x) on October 31st as revision 1.27. > It was MFC'ed to 5.3-stable on November 8th. > > This broke scripts which depended on the special-handling of > '#', but the conclusion in -current was that /bin/sh should > handle such processing (if it wanted to), and not execve(). > > d) In January I was finally bitten by this running 6.x-current, > and a friend of mine happened to get hit by it at the same > time running 5.3-stable. So I wrote up a quick fix and did > some minimal testing. I posted that to -current on Jan 31st, > but I didn't want to commit it until I did more testing, > which I wanted to do *after* I brought my systems up-to-date. > > e) On January 29th, sobomax committed an "unrelated" fix to > kern/imgact_shell.c, except that it just happened to bring back > the special '#' processing which had been removed in October... > > f) I update my systems, do extensive testing of my patch, and I > committed it once I was confident it worked in all situations. > However, I didn't notice that the shell was no longer even > *seeing* the parameters after '#' (I had tested that part > back in #d), so it turns out the key loop I that had added > was never actually getting triggered. > > I committed it to 6.x-current last week. > > g) On Monday I get ready to MFC the change to 5.3 (ahead of the > rush to beat the code-freeze!). But... the damn thing does > NOT work right in some common situations!! WTF?!? > > So, I figure out all the above history, and I locally modify > kern/imgact_shell.c to again remove the special '#'-processing. > I go to fix my patch to /bin/sh, and I realize... > > There is no simple, "make everyone happy" fix for it. Sigh. > > The problem is in the way the execve() system call passes all > arguments to the shell. Given a shell named /tmp/list_args.pl, > which starts out as: > #!/bin/sh -x -- # -*- perl -*- -p > > and is executed via: > /tmp/list_args.pl aaa bbb > > What /bin/sh sees for arguments are: > arg[0] == '-x' > arg[1] == '--' > arg[2] == '#' > arg[3] == '-*-' > arg[4] == 'perl' > arg[5] == '-*-' > arg[6] == '-p' > arg[7] == '/tmp/list_args.pl' > arg[8] == 'aaa' > arg[9] == 'bbb' > > The problem is that /bin/sh has no way of knowing where the > "shebang-line options" end, and the "command-line options" start. > (or does it? I couldn't think of any reliable way, given that > the '#' could be followed by any totally arbitrary strings). > > Going back to the follow-up to PR 16393, part of the challenge > with fixing this is that many other OS's do *not* break up the > options on the shebang line the way FreeBSD does. > From the PR: > > Given a file called '/tmp/x2' with shebang line: > #!/tmp/interp -a -b -c #dee eee > > If /tmp/x2 is exec'd, the operating system runs /tmp/interp > with the following arguments: > > Solaris 8: > args: "/tmp/interp" "-a" "/tmp/x2" > > Tru64 4.0: > args: "interp" "-a -b -c #dee eee" "/tmp/x2" > > FreeBSD 2.2.7: > args: "/tmp/interp" "-a" "-b" "-c" "#dee" "eee" "/tmp/x2" > > FreeBSD 4.0: > args: "/tmp/interp" "-a" "-b" "-c" "/tmp/x2" > > Linux 2.4.12: > args: "/tmp/interp" "-a -b -c #dee eee" "/tmp/x2" > > Linux 2.2.19: > args: "interp" "-a -b -c #dee eee" "/tmp/x2" > > Irix 6.5: > args: "/tmp/interp" "-a -b -c #dee eee" "/tmp/x2" > > HPUX 11.00: > args: "/tmp/x2" "-a -b -c #dee eee" "/tmp/x2" > > AIX 4.3: > args: "interp" "-a -b -c #dee eee" "/tmp/x2" > > Mac OX X: > args: "interp" "-a -b -c #dee eee" "/tmp/x2" > > The most common behavior is: > argv[0]: full path of interpreter > argv[1]: all remaining args, coalesced into one string > argv[2]: The file file exec'd. > > The change committed back in 2000 made the comment: "This complies > to POSIX 1003.2, in that Posix says the implementation is free to > choose whatever it likes.". I actually like the idea that FreeBSD > splits up the arguments from the shebang-line, but that leaves us > with the problem of figuring out shebang-options from user-specified > options given on the command-line. > > As I see it, we have the following choices to fix this: > > 1) MFC the January 31st change to kern/imgact_shell.c to 5.3-stable, > as it is. This means we haven't fixed the problem that people > complained about in 2002 and again in 2004. And I still think > it is "not appropriate" for the execve() system to be deciding > what '#' means on that line. The biggest advantage is that this > means 5.4-release will behave exactly the same as 3.5 through > 5.3-release have behaved. > > 2) Remove '#'-processing from kern/imgact_shell.c, and remove my > change to bin/sh/options.c (which doesn't work right once we > do that). This breaks shell-scripts which use the feature as > documented by perl (and other scripting languages), and fixes > the problem people complained about in 2002/2004. > > 3) Change kern/imgact_shell.c to process shebang options the same > way other (non-BSD?) operating systems do. By that I mean: > send the entire string as arg[1], and let the scripting > language sort it out. This is an incompatible change from > FreeBSD 5.3 to 5.4, but would put make us "more consistent" > with other operating systems. > > 4) Provide some way for /bin/sh to find out where the shebang > options end, and the user-specified options begin. This could > make everyone happy, but it's more work and right now (this > close to 5.4-release) that wouldn't make me particularly happy... > > Or we could do #1 for now, and plan to do #4 after 5.4-release. > Or do #1 now in 5.3, and go with some incompatible change (#2 > or #3) only in 6.x-current. > > What do people think? I know this is a mind-numbingly trivial > issue to care about, but I figured that if I just went ahead > with any particular solution, someone would be irritated with me > and assume I must not have understood "the issues". They will > then commit yet *another* change which undoes whatever I did, > while they fix something they feel that I broke. > > And if nothing else, this is proof that one can't just blindly > MFC some change, no matter now trivial it seems. I would vote for making #3 and respective /bin/sh changes and MFCing them into 5.4. We don't have that many shell scripts that rely on the previus functionality - ones that in the base system (if any) can be easily fixed, while ones in /usr/ports can be conditionalized on OSVERSION. Removing yet another superfluous difference between FreeBSD and other systems out there is good thing especially considering that BSD-way creates serious problems that can't be resolved without changing semantics anyway. -Maxim From owner-freebsd-arch@FreeBSD.ORG Thu Feb 24 18:56:10 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAD9B16A4CE for ; Thu, 24 Feb 2005 18:56:10 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 306AB43D67 for ; Thu, 24 Feb 2005 18:56:10 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j1OIu5j6005011; Thu, 24 Feb 2005 13:56:05 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <421DAD8F.6000704@portaone.com> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> Date: Thu, 24 Feb 2005 13:56:04 -0500 To: Maxim Sobolev From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 cc: "David G. Lawrence" cc: freebsd-arch@freebsd.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 18:56:10 -0000 At 12:33 PM +0200 2/24/05, Maxim Sobolev wrote: >Garance A Drosihn wrote: >> >>Or we could do #1 for now, and plan to do #4 after 5.4-release. >>Or do #1 now in 5.3, and go with some incompatible change (#2 >>or #3) only in 6.x-current. >> >>What do people think? ... > >I would vote for making #3 and respective /bin/sh changes and >MFCing them into 5.4. Do you mean "in time for 5.4-release", or do you mean "into 5.4-stable, after 5.4-release is done"? (either way would be fine with me, but I would like to see your change to kern/imgact_shell.c MFC'ed before 5.4-release, even if we don't get #3 done and tested in time for that) >We don't have that many shell scripts that >rely on the previus functionality - ones that in the base system >(if any) can be easily fixed, while ones in /usr/ports can be >conditionalized on OSVERSION. Removing yet another superfluous >difference between FreeBSD and other systems out there is good >thing especially considering that BSD-way creates serious >problems that can't be resolved without changing semantics anyway. The more I think about it, the more I think this is the right idea. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Thu Feb 24 21:29:52 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE33416A4CE for ; Thu, 24 Feb 2005 21:29:52 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE4C743D67 for ; Thu, 24 Feb 2005 21:29:51 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] ([192.168.2.2]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j1OLTXwq082384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Feb 2005 22:29:35 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <421E4739.3060007@portaone.com> Date: Thu, 24 Feb 2005 23:29:29 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.80/685/Wed Jan 26 10:08:24 2005 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: "David G. Lawrence" cc: freebsd-arch@freebsd.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 21:29:53 -0000 Garance A Drosihn wrote: > At 12:33 PM +0200 2/24/05, Maxim Sobolev wrote: > >> Garance A Drosihn wrote: >> >>> >>> Or we could do #1 for now, and plan to do #4 after 5.4-release. >>> Or do #1 now in 5.3, and go with some incompatible change (#2 >>> or #3) only in 6.x-current. >>> >>> What do people think? ... >> >> >> I would vote for making #3 and respective /bin/sh changes and >> MFCing them into 5.4. > > > Do you mean "in time for 5.4-release", or > do you mean "into 5.4-stable, after 5.4-release is done"? In time for 5.4 if possible, since putting hype aside, 5.4 is going to be the first 5.x release which can be seriously recommended for a production deployment. Therefore, whatever 5.4 sets is likely to be de-facto standard in FreeBSD word during the next 1-2 years. > (either way would be fine with me, but I would like to see your > change to kern/imgact_shell.c MFC'ed before 5.4-release, even if > we don't get #3 done and tested in time for that) I'll consider that. >> We don't have that many shell scripts that >> rely on the previus functionality - ones that in the base system >> (if any) can be easily fixed, while ones in /usr/ports can be >> conditionalized on OSVERSION. Removing yet another superfluous >> difference between FreeBSD and other systems out there is good >> thing especially considering that BSD-way creates serious >> problems that can't be resolved without changing semantics anyway. > > > The more I think about it, the more I think this is the right idea. -Maxim From owner-freebsd-arch@FreeBSD.ORG Thu Feb 24 22:04:03 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AF1F16A4CE for ; Thu, 24 Feb 2005 22:04:03 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id E554B43D1D for ; Thu, 24 Feb 2005 22:04:01 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4947 invoked from network); 24 Feb 2005 22:03:56 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 24 Feb 2005 22:03:55 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j1OM3cAU033721; Thu, 24 Feb 2005 17:03:40 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 24 Feb 2005 12:59:29 -0500 User-Agent: KMail/1.6.2 References: <200410020349.i923nG8v021675@northstar.hetzel.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200502241259.29303.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Maxim Sobolev cc: Garance A Drosihn cc: "David G. Lawrence" Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2005 22:04:03 -0000 On Thursday 24 February 2005 01:24 am, Garance A Drosihn wrote: > 3) Change kern/imgact_shell.c to process shebang options the same > way other (non-BSD?) operating systems do. By that I mean: > send the entire string as arg[1], and let the scripting > language sort it out. This is an incompatible change from > FreeBSD 5.3 to 5.4, but would put make us "more consistent" > with other operating systems. I vote for 3). Good testing of your MFC before doing it. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Feb 25 21:04:32 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37AD716A4CE; Fri, 25 Feb 2005 21:04:32 +0000 (GMT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFC5D43D1F; Fri, 25 Feb 2005 21:04:31 +0000 (GMT) (envelope-from gordon@tetlows.org) Received: from [64.37.153.164] (ip-153-164.station.sony.com [64.37.153.164]) (authenticated bits=0) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id j1PL49uO065253; Fri, 25 Feb 2005 13:04:12 -0800 (PST) (envelope-from gordon@tetlows.org) Message-ID: <421F92BC.3030904@tetlows.org> Date: Fri, 25 Feb 2005 13:03:56 -0800 From: Gordon Tetlow User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> In-Reply-To: X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to http://www.habeas.com/report/. Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67D23C2E3443A407BBB95CCA" cc: Maxim Sobolev cc: "David G. Lawrence" cc: freebsd-arch@freebsd.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2005 21:04:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67D23C2E3443A407BBB95CCA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Garance A Drosihn wrote: > As I see it, we have the following choices to fix this: > > 1) MFC the January 31st change to kern/imgact_shell.c to 5.3-stable, > as it is. This means we haven't fixed the problem that people > complained about in 2002 and again in 2004. And I still think > it is "not appropriate" for the execve() system to be deciding > what '#' means on that line. The biggest advantage is that this > means 5.4-release will behave exactly the same as 3.5 through > 5.3-release have behaved. > > 2) Remove '#'-processing from kern/imgact_shell.c, and remove my > change to bin/sh/options.c (which doesn't work right once we > do that). This breaks shell-scripts which use the feature as > documented by perl (and other scripting languages), and fixes > the problem people complained about in 2002/2004. > > 3) Change kern/imgact_shell.c to process shebang options the same > way other (non-BSD?) operating systems do. By that I mean: > send the entire string as arg[1], and let the scripting > language sort it out. This is an incompatible change from > FreeBSD 5.3 to 5.4, but would put make us "more consistent" > with other operating systems. > > 4) Provide some way for /bin/sh to find out where the shebang > options end, and the user-specified options begin. This could > make everyone happy, but it's more work and right now (this > close to 5.4-release) that wouldn't make me particularly happy... > > Or we could do #1 for now, and plan to do #4 after 5.4-release. > Or do #1 now in 5.3, and go with some incompatible change (#2 > or #3) only in 6.x-current. I would say we should stick with #1 for the 5.x release and use #3 for 6.x and further. We have already frozen APIs and ABIs. For people that might have scripts that use this syntax to have problems between minor releases is unacceptable. -gordon --------------enig67D23C2E3443A407BBB95CCA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCH5LDRu2t9DV9ZfsRAowrAJ9QzrezkSYlktdWKjXburHbhYCK2QCglbDF D7f3gXXqoeFSGWdKhxVnKgg= =AxjF -----END PGP SIGNATURE----- --------------enig67D23C2E3443A407BBB95CCA-- From owner-freebsd-arch@FreeBSD.ORG Fri Feb 25 22:36:48 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D3916A4CE; Fri, 25 Feb 2005 22:36:48 +0000 (GMT) Received: from smtp1.server.rpi.edu (smtp1.server.rpi.edu [128.113.2.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F374B43D64; Fri, 25 Feb 2005 22:36:47 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp1.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j1PMadhd006837; Fri, 25 Feb 2005 17:36:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <421F92BC.3030904@tetlows.org> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421F92BC.3030904@tetlows.org> Date: Fri, 25 Feb 2005 17:36:38 -0500 To: Gordon Tetlow From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.1 cc: Maxim Sobolev cc: "David G. Lawrence" cc: freebsd-arch@freebsd.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2005 22:36:48 -0000 At 1:03 PM -0800 2/25/05, Gordon Tetlow wrote: >Garance A Drosihn wrote: > > > > 3) Change kern/imgact_shell.c to process shebang options the same >> way other (non-BSD?) operating systems do. By that I mean: >> send the entire string as arg[1], and let the scripting >> language sort it out. This is an incompatible change from >> FreeBSD 5.3 to 5.4, but would put make us "more consistent" > > with other operating systems. Additional data point: It seems that both OpenBSD and NetBSD do it the same way the other OS's do. Which is to say, I don't think there is any OS which matches FreeBSD's present behavior. > > Or we could do #1 for now, and plan to do #4 after 5.4-release. >> Or do #1 now in 5.3, and go with some incompatible change (#2 >> or #3) only in 6.x-current. > >I would say we should stick with #1 for the 5.x release and >use #3 for 6.x and further. We have already frozen APIs and >ABIs. For people that might have scripts that use this syntax >to have problems between minor releases is unacceptable. The more I look at this, the more I think we can do #3 without breaking much of anything. But I am not confident that I could get it done and have it tested-enough in time for 5.4-release. I need to write an update to kern/imgact_shell.c and bin/sh, and I have to at least check what this means for /usr/bin/env (since many scripts use that as the "interpreter" on `!#' lines). Other than that, what else in the base system is even *used* as an interpreter in this fashion? Would `awk' be? Anything else? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu