From owner-freebsd-arch Sun May 5 0:35: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by hub.freebsd.org (Postfix) with ESMTP id 9056E37B41B for ; Sun, 5 May 2002 00:35:05 -0700 (PDT) Received: from free.fr (nas-cbv-6-62-147-149-16.dial.proxad.net [62.147.149.16]) by postfix3-2.free.fr (Postfix) with ESMTP id 084D61821E for ; Sun, 5 May 2002 09:35:04 +0200 (CEST) Received: (from nsouch@localhost) by free.fr (8.11.6/8.9.3) id g457kDo30800 for freebsd-arch@freebsd.org; Sun, 5 May 2002 09:46:13 +0200 (CEST) (envelope-from nsouch) Date: Sun, 5 May 2002 09:46:13 +0200 From: Nicolas Souchu To: freebsd-arch@freebsd.org Subject: syscons and graphic Message-ID: <20020505094613.B30639@armor.fastether> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, Argh, majordomo must have removed the forwarded message... Could one of you (console gurus) give me an overview of syscons abstraction regarding underlying video adapters? I noticed two files scvgarndr.c and scgfbrndr.c which seem to do the job. How all this interacts with dev/fb code, if it does? Is it sufficient to implement a new scxxxrdnr.c file to use a different underlying interface which would propose the same functionnalities? Is scgfbrndr.c usable with an i386 machine? How? Nicholas -- Nicholas Souchu - nsouch@free.fr - nsouch@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun May 5 1:11:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by hub.freebsd.org (Postfix) with ESMTP id C7E5637B41C; Sun, 5 May 2002 01:11:02 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 25B4128D3C; Sun, 5 May 2002 15:10:48 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 16A9128A60; Sun, 5 May 2002 15:10:48 +0700 (ALMST) Date: Sun, 5 May 2002 15:10:47 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: Peter Wemm , Wes Peters , John Baldwin , Terry Lambert , arch@FreeBSD.ORG Subject: Re: savcore dump names? In-Reply-To: <37980.1020534509@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 4 May 2002, Poul-Henning Kamp wrote: > >This is not quite the same thing as userconfig. [...] > > You make this sound like resurrecting things from CVS is impossible, > something both you, I and everybody else know is just plain wrong. > > I actually think it is quite the same as USERCONFIG. The whole thread is not about complexity of savecore or ability to extract things from CVS. The whole thread is about your development style varying from replacing old and working code with incomplete implementations (and even saying "hey, I don't have time to finish it, do it for me...") and not respecting concept of maintainer (Bill Paul's reply outline this). Poul, please - do not turn every your step to a war. Look how other people work together, how they solve issues. It is not that hard. And, you're working for voluntary project. Yes, you're directly paid for work on FreeBSD, but may peoples are not. Please, do not ruing things out. Thanks in advance. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 6 18: 5:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5049337B401; Mon, 6 May 2002 18:05:49 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g4715lO8170530; Mon, 6 May 2002 21:05:47 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <33534.1020505495@critter.freebsd.dk> References: <33534.1020505495@critter.freebsd.dk> Date: Mon, 6 May 2002 21:05:46 -0400 To: Poul-Henning Kamp , Robert Watson From: Garance A Drosihn Subject: Re: syscall changes to deal with 32->64 changes. Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:44 AM +0200 5/4/02, Poul-Henning Kamp wrote: >I think a realistic plan might look something like this: > >1. Change the in-kernel types to 64 bits > for each entity to change size: > a) rewrite syscall entries to translate sizes. > b) change size in kernel, but retain old size > in userland > >2. Add new syscall API > a) write syscalls implementations. > >3. Change userland over. > a) Add #ifdef NEWAPI all over the includes so people > can select which API to use. > b) Create new major-revv libc which uses new API > c) Leave people time to find bugs in ports etc. > d) Throw the switch for good. > >Earliest realistic dates would be 3c on july 1st and 3d >a month later. > >Is that too late for 5.0-R ? If that timetable is doable, then I think it's reasonable to do. The alternate question is that if we did NOT go with a new syscall vector, then how much work will it be to get these 32->64bit changes done before 5.0? I assume the variable would be something more distinctive than "NEWAPI"... At 3:41 AM -0400 5/4/02, Robert Watson wrote: >John Baldwin and I have thrown this idea around a number >of times, as we keep bumping into things that would change >the ABI. What things would those be? Might as well get them listed, and see how many of them (if any...) could be included in this new vector without hurting the timetable. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 6 19:23:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 146BC37B403; Mon, 6 May 2002 19:23:35 -0700 (PDT) Received: from pool0679.cvx21-bradley.dialup.earthlink.net ([209.179.194.169] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 174udD-0005fP-00; Mon, 06 May 2002 19:23:11 -0700 Message-ID: <3CD73A71.BF0AF3A@mindspring.com> Date: Mon, 06 May 2002 19:22:41 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Poul-Henning Kamp , Robert Watson , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <33534.1020505495@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > At 3:41 AM -0400 5/4/02, Robert Watson wrote: > >John Baldwin and I have thrown this idea around a number > >of times, as we keep bumping into things that would change > >the ABI. > > What things would those be? Might as well get them listed, > and see how many of them (if any...) could be included in > this new vector without hurting the timetable. Apart from the obvious "stat" values and time_t, there's also nlink_t, dev_t, etc.... and if we're really clever, a version number for the stat structure, as the first element. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon May 6 22:11: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1A50737B408; Mon, 6 May 2002 22:11:04 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g475ANQ4081863; Tue, 7 May 2002 07:10:29 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Terry Lambert Cc: Garance A Drosihn , Robert Watson , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Your message of "Mon, 06 May 2002 19:22:41 PDT." <3CD73A71.BF0AF3A@mindspring.com> Date: Tue, 07 May 2002 07:10:23 +0200 Message-ID: <81862.1020748223@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <3CD73A71.BF0AF3A@mindspring.com>, Terry Lambert writes: >Garance A Drosihn wrote: >> At 3:41 AM -0400 5/4/02, Robert Watson wrote: >> >John Baldwin and I have thrown this idea around a number >> >of times, as we keep bumping into things that would change >> >the ABI. >> >> What things would those be? Might as well get them listed, >> and see how many of them (if any...) could be included in >> this new vector without hurting the timetable. > >Apart from the obvious "stat" values and time_t, there's also >nlink_t, dev_t, etc.... and if we're really clever, a version >number for the stat structure, as the first element. Can I officially move that Terry be banned from posting to arch@ ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 0: 9:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 48A8137B40B; Tue, 7 May 2002 00:09:24 -0700 (PDT) Received: from pool0102.cvx21-bradley.dialup.earthlink.net ([209.179.192.102] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 174z67-0003H1-00; Tue, 07 May 2002 00:09:19 -0700 Message-ID: <3CD77D81.1B6A7327@mindspring.com> Date: Tue, 07 May 2002 00:08:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , Robert Watson , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <81862.1020748223@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message <3CD73A71.BF0AF3A@mindspring.com>, Terry Lambert writes: > >Garance A Drosihn wrote: > >> At 3:41 AM -0400 5/4/02, Robert Watson wrote: > >> >John Baldwin and I have thrown this idea around a number > >> >of times, as we keep bumping into things that would change > >> >the ABI. > >> > >> What things would those be? Might as well get them listed, > >> and see how many of them (if any...) could be included in > >> this new vector without hurting the timetable. > > > >Apart from the obvious "stat" values and time_t, there's also > >nlink_t, dev_t, etc.... and if we're really clever, a version > >number for the stat structure, as the first element. > > Can I officially move that Terry be banned from posting to arch@ ? Can I officially move that PHK answer Garance Droshin's original question, in the context of the UFS2 project, which Poul has already suggested will need the data structure changes which spurred the current thread on the system call API (and thus ABI) changing? It's been 4 days since the question was asked, and his only comment has been a request to squelch discussion of the list of things which will have to change. I would prefer that such a list be as complete as possible, to avoid additional changes being required as a result of future work by others. Thanks, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 1:15:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3448537B401; Tue, 7 May 2002 01:15:49 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g478Fn180961; Tue, 7 May 2002 01:15:49 -0700 (PDT) (envelope-from dillon) Date: Tue, 7 May 2002 01:15:49 -0700 (PDT) From: Matthew Dillon Message-Id: <200205070815.g478Fn180961@apollo.backplane.com> To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <13810.1020419033@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As a person who has already spent several days playing with 64 bit time_t's and associated syscalls I would say that creating a new syscall vector for FreeBSD 5.0 (and leaving the existing one intact for compatibility) is the correct solution. I tried to add new syscalls to the existing vector but so many syscalls had to be changed to support 64 bit time_t's that it became a huge mess... so much so that I would expect the other BSD's to cry foul on us if we tried to do it with the existing vector. It will be far, far cleaner to simply implement an entirely new syscall vector / ELF identifier. In regards to other things that may need to change size: A complete audit will have to be performed. I would be happy to take a run through. Getting it right the first time is extremely important. A bunch of things starting leaking out of the woodwork as I was playing around with 64 bit time_t's. At the very least I would pad the structures to handle things like 64 bit dev_t, ino_t, and file flags, and I would even consider padding now 96 bit structures like timespec (on IA32 with 64 bit time_t's + nanoseconds long = 96 bits) to 128 bits across the board. It might also be worthwhile to make uid_t, gid_t, and pid_t 64 bits to support probable future work in those areas. In regards to the 5.0R question that comes up later in the thread... I just don't know. I will say that creating a new syscall vector cannot be done piecemeal... you have to get it *all* in from the get-go or you create huge issues with things like bootstrapping new systems and general compatibility and useability, etc.. -Matt :We have some 32 to 64 bit changes outstanding, which are necessary :to complete the UFS2 DARPA project. :... : :1. Are there anything else that needs to change size while we're : at it ? : :2. Is this a good occation to create a new syscall vector for : FreeBSD 5.0 rather than embellish the existing one with even : more variations ? : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 4:41:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 776CD37B408 for ; Tue, 7 May 2002 04:41:52 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g47Baib5075584; Tue, 7 May 2002 07:36:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 7 May 2002 07:36:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Terry Lambert Cc: Garance A Drosihn , Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <3CD73A71.BF0AF3A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 6 May 2002, Terry Lambert wrote: > Garance A Drosihn wrote: > > At 3:41 AM -0400 5/4/02, Robert Watson wrote: > > >John Baldwin and I have thrown this idea around a number > > >of times, as we keep bumping into things that would change > > >the ABI. > > > > What things would those be? Might as well get them listed, > > and see how many of them (if any...) could be included in > > this new vector without hurting the timetable. > > Apart from the obvious "stat" values and time_t, there's also nlink_t, > dev_t, etc.... and if we're really clever, a version number for the stat > structure, as the first element. I have a few in my queue that don't relate to UFS2, and that includes updating the ipcperm structure to use uid_t and gid_t rather than u_short. This breaks the ABI for most of the sysv calls, if not all of them, unfortunately. I have some increasingly dated patches that begin to seperate user and kernel structures for the sysvipc code, and probably ought to update, complete, and commit them sometime. This makes the ABI change easier to handle. There are already ofoo() calls for sysvipc, and an interesting question is how long we have to wait before we can remove those (that was from when someone updated u_short to pid_t, I think, but didn't do the rest). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 5:16:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 115D637B40A for ; Tue, 7 May 2002 05:16:54 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g47CGJQ4086516; Tue, 7 May 2002 14:16:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Your message of "Tue, 07 May 2002 01:15:49 PDT." <200205070815.g478Fn180961@apollo.backplane.com> Date: Tue, 07 May 2002 14:16:19 +0200 Message-ID: <86515.1020773779@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200205070815.g478Fn180961@apollo.backplane.com>, Matthew Dillon wri tes: > In regards to other things that may need to change size: A complete > audit will have to be performed. I would be happy to take a run through. No need to, I'm already busy doing that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 6:47:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 3033337B405; Tue, 7 May 2002 06:47:23 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g47Dkvb5076683; Tue, 7 May 2002 09:46:57 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 7 May 2002 09:46:56 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Matthew Dillon Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <200205070815.g478Fn180961@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 7 May 2002, Matthew Dillon wrote: > I tried to add new syscalls to the existing vector but so many > syscalls had to be changed to support 64 bit time_t's that it > became a huge mess... so much so that I would expect the other > BSD's to cry foul on us if we tried to do it with the existing > vector. It will be far, far cleaner to simply implement an > entirely new syscall vector / ELF identifier. Sounds like we actually have relatively firm concensus on this point [thus far]. The only concern really has been level of effort and chances of completeness in a reasonable time. > In regards to other things that may need to change size: A complete > audit will have to be performed. I would be happy to take a run through. > Getting it right the first time is extremely important. A bunch of > things starting leaking out of the woodwork as I was playing around > with 64 bit time_t's. At the very least I would pad the structures > to handle things like 64 bit dev_t, ino_t, and file flags, and I would > even consider padding now 96 bit structures like timespec (on IA32 with > 64 bit time_t's + nanoseconds long = 96 bits) to 128 bits across the > board. It might also be worthwhile to make uid_t, gid_t, and pid_t > 64 bits to support probable future work in those areas. It's certainly worth talking about, in that it would be a good breaking point for any of these. One thing to keep in mind is how much inode growth is acceptable -- we get some as part of the natural process of moving to 64-bit block pointers, but we shouldn't let it get out of control or risk serious reduction in cached inode information for the same memory footprint. My understanding from talking with Kirk and Poul-Henning is that ino_t is definitely on the list already, as are a number of the others at the file system image layer (such as block pointers, et al). They should already have much of this underway, and the temptation is to allow them to do the grunt work if they're already doing it :-). dev_t I don't really have an opinion about. For file flags, last I checked, the current leaning was to actually add a new flags field to the inode for internal system use, and possibly breaking out the current field into two fields. All of this is at the fs image level however. This would allow moving the snapshot flag out of the normal fields range and reducing the level of hard-to-read flag masking in the UFS2 code. The system flags would also allow for some EA information caching, improving performance for ACLs and related things. No opinion on the time type stuff, but I'm sure phk has an opinion :-). WRT uid_t and gid_t: I'm not sure if there's enough benefit here. The temptation is certainly there, but unlike things like ino_t, this stuff tends to get mixed up in data files a lot. Same with time type stuff. This is more likely to cause problems with persistent application state -- for example, password databases. > In regards to the 5.0R question that comes up later in the thread... > I just don't know. I will say that creating a new syscall vector > cannot be done piecemeal... you have to get it *all* in from the > get-go or you create huge issues with things like bootstrapping new > systems and general compatibility and useability, etc.. Well, I think it's possible to start doing back-end stuff in the kernel and just "cast down", but I haven't given it too much think-through yet. Where we'll really need a flag day is with the default compiled ABI for user binaries. It depends how we handle the change to some of the types, I suppose -- whether we use "holding types" during a changeover, etc. One of the reasons I mentioned the "one week" figure in my earlier responses it that when we do the cut-over, we need to do it decisively and without a lot of lag in getting stuff working. At the filesystem level, introducing new types doesn't hurt us too much (ufs_ino_t, ufs2_ino_t, et al), but at the system call layer it could be that would hurt too much. I guess the one opinion I haven't heard yet, and am a little surprised not to have heard is: No, we shouldn't do this on architectural grounds. We've heard "yes" in various flavors, including moderated "yes if we can manage it by the release". Not to invite a bikeshed, but if there's going to be a strong argument against such a change, it would be nice to hear it sooner. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 7:33:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 641E737B404 for ; Tue, 7 May 2002 07:33:29 -0700 (PDT) Received: (qmail 32155 invoked from network); 7 May 2002 14:33:28 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 May 2002 14:33:28 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g47EXRF29010; Tue, 7 May 2002 10:33:27 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200205070815.g478Fn180961@apollo.backplane.com> Date: Tue, 07 May 2002 10:33:20 -0400 (EDT) From: John Baldwin To: Matthew Dillon Subject: Re: syscall changes to deal with 32->64 changes. Cc: arch@FreeBSD.ORG, Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 07-May-2002 Matthew Dillon wrote: > As a person who has already spent several days playing with > 64 bit time_t's and associated syscalls I would say that > creating a new syscall vector for FreeBSD 5.0 (and leaving the > existing one intact for compatibility) is the correct solution. I agree completely. > I tried to add new syscalls to the existing vector but so many > syscalls had to be changed to support 64 bit time_t's that it > became a huge mess... so much so that I would expect the other > BSD's to cry foul on us if we tried to do it with the existing > vector. It will be far, far cleaner to simply implement an > entirely new syscall vector / ELF identifier. Right. I would like to use the ELF_ABI_OSVERSION thingie, but according to O'Brien it violates the ELF spec to use any value other than 0. But then why does it exist if we can't use it? :( One idea being thrown about is that for the new ABI (It would be FreeBSD ABI 2) there would be a syscall at syscall 0 that would never change that could be used to select what "minor" version of the ABI you wanted to use, so if we wanted to add a new ABI at some point in the future we could stick that syscall in crt.c (or whatever the proper startup file is) to change to ABI 2.1 or 2.2 or something. However, for the current change, I think bumping the ELF OS version and adding a new ABI front-end for ABI 2 is the way to go. Another advantage of this is that if our tools handle the OS version bit properly, we can actually not have to worry about much of a flag day. Instead we can gradually add the new ABI and support for it and then just quietly throw the switch to change the default ABI in current one day. Old binaries would still run fine. The only tricky part is for libc.so since you would really need two version of it (unless we also bumped to libc.so.6 for this..) and we would need to make sure we linked to the right OSVERSION of the lib when doing runtime linking, whcih could get ugly. > In regards to other things that may need to change size: A complete > audit will have to be performed. I would be happy to take a run through. > Getting it right the first time is extremely important. A bunch of > things starting leaking out of the woodwork as I was playing around > with 64 bit time_t's. At the very least I would pad the structures > to handle things like 64 bit dev_t, ino_t, and file flags, and I would > even consider padding now 96 bit structures like timespec (on IA32 with > 64 bit time_t's + nanoseconds long = 96 bits) to 128 bits across the > board. It might also be worthwhile to make uid_t, gid_t, and pid_t > 64 bits to support probable future work in those areas. I agree, here, too. > In regards to the 5.0R question that comes up later in the thread... > I just don't know. I will say that creating a new syscall vector > cannot be done piecemeal... you have to get it *all* in from the > get-go or you create huge issues with things like bootstrapping new > systems and general compatibility and useability, etc.. I think we can gradually overhaul it internally in the kernel before we throw the switch to turn it on by default since all we would be breaking would be test binaries and not "real" ones. Once the new ABI is golden, then we would throw the switch to change the default. I'm also not sure if we shouldn't wait to do this until 6.0. > -Matt > >:We have some 32 to 64 bit changes outstanding, which are necessary >:to complete the UFS2 DARPA project. >:... >: >:1. Are there anything else that needs to change size while we're >: at it ? >: >:2. Is this a good occation to create a new syscall vector for >: FreeBSD 5.0 rather than embellish the existing one with even >: more variations ? >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 8:17:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dove.ethz.ch (dove.ethz.ch [129.132.28.93]) by hub.freebsd.org (Postfix) with ESMTP id 4628437B408 for ; Tue, 7 May 2002 08:17:14 -0700 (PDT) Received: from rail.ethz.ch (rail [129.132.28.100]) by dove.ethz.ch (8.11.2/8.11.0) with ESMTP id g47FHAp20138 for ; Tue, 7 May 2002 17:17:10 +0200 (MST) Received: (from gabism@localhost) by rail.ethz.ch (8.8.8+Sun/8.8.8) id RAA12740 for freebsd-arch@freebsd.org; Tue, 7 May 2002 17:17:10 +0200 (MET DST) Date: Tue, 7 May 2002 17:17:10 +0200 (MET DST) From: Matsim Member Message-Id: <200205071517.RAA12740@rail.ethz.ch> Content-Type: text To: undisclosed-recipients:; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does FreeBSD respects standard IEEE 754? Thanks, Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 8:22: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dove.ethz.ch (dove.ethz.ch [129.132.28.93]) by hub.freebsd.org (Postfix) with ESMTP id EDB7B37B42C for ; Tue, 7 May 2002 08:21:41 -0700 (PDT) Received: from rail.ethz.ch (rail [129.132.28.100]) by dove.ethz.ch (8.11.2/8.11.0) with ESMTP id g47FLep20250 for ; Tue, 7 May 2002 17:21:40 +0200 (MST) Received: (from gabism@localhost) by rail.ethz.ch (8.8.8+Sun/8.8.8) id RAA12780 for freebsd-arch@freebsd.org; Tue, 7 May 2002 17:21:39 +0200 (MET DST) Date: Tue, 7 May 2002 17:21:39 +0200 (MET DST) From: Matsim Member Message-Id: <200205071521.RAA12780@rail.ethz.ch> Content-Type: text To: undisclosed-recipients:; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Does FreeBSD respect standard IEEE 754? Thanks, Jack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 8:29: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2EBF737B407; Tue, 7 May 2002 08:28:46 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g47FSQb5078642; Tue, 7 May 2002 11:28:26 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 7 May 2002 11:28:26 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.org, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 7 May 2002, John Baldwin wrote: > Right. I would like to use the ELF_ABI_OSVERSION thingie, but according > to O'Brien it violates the ELF spec to use any value other than 0. But > then why does it exist if we can't use it? :( One idea being thrown > about is that for the new ABI (It would be FreeBSD ABI 2) there would be > a syscall at syscall 0 that would never change that could be used to > select what "minor" version of the ABI you wanted to use, so if we > wanted to add a new ABI at some point in the future we could stick that > syscall in crt.c (or whatever the proper startup file is) to change to > ABI 2.1 or 2.2 or something. However, for the current change, I think > bumping the ELF OS version and adding a new ABI front-end for ABI 2 is > the way to go. > > Another advantage of this is that if our tools handle the OS version bit > properly, we can actually not have to worry about much of a flag day. > Instead we can gradually add the new ABI and support for it and then > just quietly throw the switch to change the default ABI in current one > day. Old binaries would still run fine. The only tricky part is for > libc.so since you would really need two version of it (unless we also > bumped to libc.so.6 for this..) and we would need to make sure we > linked to the right OSVERSION of the lib when doing runtime linking, > whcih could get ugly. My feeling on a strategy resembles the one phk proposed... (1) Someone does a first pass. Since Kirk and Poul-Henning are doing some of this anyway, they'd be good candidates. They do what they need, but don't get carried away. (2) They commit this, but it does not become the default. How to handle #includes is an interesting question, perhaps using some new_foo_t until the switchover is done. Or foo64_t or the like. Throwing a date at this is a good idea. phk's dates looked good -- perhaps mid-June or late June. (3) We have a window where other developers now take care of the things they care about in the new ABI. For example, I'd be happy to pick up the sysvipc work to switch to uid_t and gid_t. Depending on our definition of "get carried away" above, this might be a good time to update the time-related types. (4) The switch is thrown. This is the second date of interest. We don't want to let this get beyond the end of July, so we can cut DP3 (which would be inevitable with a new ABI) with the new ABI and get decent testing. > I think we can gradually overhaul it internally in the kernel before we > throw the switch to turn it on by default since all we would be breaking > would be test binaries and not "real" ones. Once the new ABI is golden, > then we would throw the switch to change the default. Yeah, if we can do that, would be good. BTW, since this is -current, I'm not sure we need to be too careful with shared library versions, but it does raise the question how we have all this co-exist. Will oldabi and newabi live together in /usr/lib, or should we be considering something like /usr/lib/aout? > I'm also not sure if we shouldn't wait to do this until 6.0. Well, that's the big question, really. If we can do it in the time frame, why wait, as they say :-). If we can't, then it's a 6.0 thing. 5.0 is a nice breaking point -- we're ripping up so much anyway, and we'd like to get the ABI changes for UFS2 in. But if the schedule isn't realistic, then we can't -- slipping 5.0-release any further isn't something I want to let happen. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 8:34:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rhodium.cix.co.uk (rhodium.cix.co.uk [194.153.21.68]) by hub.freebsd.org (Postfix) with ESMTP id 79DD737B403; Tue, 7 May 2002 08:34:04 -0700 (PDT) Received: from ctek-uk.com (126.234.35.212.in-addr.arpa.ip-pool.cix.co.uk [212.35.234.126]) by rhodium.cix.co.uk (8.9.3+Sun/8.9.3) with SMTP id JAA03626; Tue, 7 May 2002 09:06:07 +0100 (BST) X-Envelope-From: alex@ctek-uk.com Message-Id: <200205070806.JAA03626@rhodium.cix.co.uk> From: "Alex" To: Subject: PC for sale Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 7 May 2002 09:06:39 +0100 Reply-To: "Alex" Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, We have a limited number of IBM Desktop PC's for sale: Pentium 166 MMX, 2.5 Gb Hard Drive, 64 Mb RAM, 3.5" Floppy, 52x CD-Rom drive, 15" SVGA Monitor, Keyboard and Mouse, with Windows 98 and Office XP PRO pre-installed, all for £200. For more info, visit us at www.ctek-uk.com/pc, email us at info@ctek-uk.com or call 0870 742 7816. Thanks, Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 8:38: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 5BC0837B404; Tue, 7 May 2002 08:37:51 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g47FbGQ4089018; Tue, 7 May 2002 17:37:17 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Your message of "Tue, 07 May 2002 10:33:20 EDT." Date: Tue, 07 May 2002 17:37:16 +0200 Message-ID: <89017.1020785836@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, seems like some sort of concensus is building. Now for a bit of radical thinking. The FreeBSD kernel is already a multi-API kernel, we have freebsd syscalls, including various old compat stuff, we have NetBSD compat, we have BSDI compat, Linuxolator, IBCS2, and we will probably have Solaris compat on the sparc64 platform. We cannot easily compile for two native APIs if we cannot have two different set of 'sys/*' and 'machine/*' files since a lot of the types we want to change size on are defined in these files. I would therefore like to propose that we do something like the following: Repocopy src/sys/sys/* to src/sys/include Repocopy src/sys/sys/* to src/sys/abi4 Remove src/sys/sys/* In src/sys/include we remove everything which deals with syscall parameters, but retain kernel internal data structures. Stuff like vnodes, and similar lives here. In src/sys/abi4 we remove everything that we leave behind in src/sys/include. (A similar split should be done for src/sys/$arch/include into a src/sys/$arch/abi4 directory) In .c land we repocopy the relevant sys/kern/*.c files into sys/abi4 and remove everything but the syscall entry points and add explicit conversions to arguments as needed. We now have a clean split between the stuff which defines what goes on in the kernel and the stuff which defines the ABI to userland. Adding a new ABI is now a matter of creating the relevant directories (src/sys/abi5) and populating with files which does it right. I see many advantages to this way of doing things: We can remove practically all "#ifdef _KERNEL" from the .h files we install in /usr/include/sys and we can get a fair bit closer to whatever the standard-du-jour dictates that we put there. Conversely we can clean the kernel side of things (src/sys/include) for things we don't want people to use in the kernel, but which standards or compatibility demand we put in . We also get a clear kernel / userland split on C types, we may find it convenient to operate on a 64 bit foo_t in the kernel but leave it 32 bit in userland and this lets us trivially do so. This should put a good bit of infrastructure in to make current and future API/ABI implementations simpler and more structured. I guess a way to sum this up is that it will put all API/ABI's on equal footing. With this change none of them will be any more "native" than any other API/ABI. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 9:18:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from trantor.utsl.org (cvg-65-27-234-192.cinci.rr.com [65.27.234.192]) by hub.freebsd.org (Postfix) with ESMTP id 1A9F537B409; Tue, 7 May 2002 09:18:33 -0700 (PDT) Received: from hotrod.utsl.org ([10.10.57.3] helo=quic.net) by trantor.utsl.org with esmtp (Exim 3.35 #1 (Debian)) id 1757fb-0000yv-00; Tue, 07 May 2002 12:18:31 -0400 Message-ID: <3CD7FE57.1000508@quic.net> Date: Tue, 07 May 2002 12:18:31 -0400 From: Nathan Hawkins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020502 Debian/1.0rc1-3 MIME-Version: 1.0 To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: >Right. I would like to use the ELF_ABI_OSVERSION thingie, but according to >O'Brien it violates the ELF spec to use any value other than 0. But then >why does it exist if we can't use it? :( One idea being thrown about is >that for the new ABI (It would be FreeBSD ABI 2) there would be a syscall >at syscall 0 that would never change that could be used to select what "minor" >version of the ABI you wanted to use, so if we wanted to add a new ABI at >some point in the future we could stick that syscall in crt.c (or whatever >the proper startup file is) to change to ABI 2.1 or 2.2 or something. However, >for the current change, I think bumping the ELF OS version and adding a new >ABI front-end for ABI 2 is the way to go. > > I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle the binary OS type/versioning. I know that at least NetBSD, Linux and Hurd do it this way, and I think most others do too. It looks like gcc is already inserting them, (run readelf -S, and you should see it) so it'd be a matter of adding to the binary emulation selector to check .note.ABI-tag. For your new ABI, set a version number in the tag. I believe the tag gcc is putting in already has a field for that. This also has the benefit of making emulations work more transparently, as it should obsolete brandelf. >Another advantage of this is that if our tools handle the OS version bit >properly, we can actually not have to worry about much of a flag day. Instead >we can gradually add the new ABI and support for it and then just quietly >throw the switch to change the default ABI in current one day. Old binaries >would still run fine. The only tricky part is for libc.so since you would >really need two version of it (unless we also bumped to libc.so.6 for this..) >and we would need to make sure we linked to the right OSVERSION of the lib when >doing runtime linking, whcih could get ugly. > This would be about the same for the above suggestion. I think bumping libc version would be good. It solves things neatly. ---Nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 9:51:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.dmnstech.net (phoenix.dmnstech.net [194.19.34.94]) by hub.freebsd.org (Postfix) with SMTP id 56C9E37B406; Tue, 7 May 2002 09:51:30 -0700 (PDT) Received: (from eivind@localhost) by phoenix.dmnstech.net (8.12.2/8.11.6) id g47GpJeK015538; Tue, 7 May 2002 18:51:19 +0200 (CEST) (envelope-from eivind) Date: Tue, 7 May 2002 18:51:19 +0200 From: Eivind Eklund To: Robert Watson Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507185119.C11452@phoenix.dmnstech.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@FreeBSD.ORG on Tue, May 07, 2002 at 11:28:26AM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 11:28:26AM -0400, Robert Watson wrote: > My feeling on a strategy resembles the one phk proposed... > > (1) Someone does a first pass. Since Kirk and Poul-Henning are doing some > of this anyway, they'd be good candidates. They do what they need, > but don't get carried away. > > (2) They commit this, but it does not become the default. How to handle > #includes is an interesting question, perhaps using some new_foo_t > until the switchover is done. Or foo64_t or the like. Throwing a > date at this is a good idea. phk's dates looked good -- perhaps > mid-June or late June. > > (3) We have a window where other developers now take care of the things > they care about in the new ABI. For example, I'd be happy to pick up > the sysvipc work to switch to uid_t and gid_t. Depending on our > definition of "get carried away" above, this might be a good time to > update the time-related types. > > (4) The switch is thrown. This is the second date of interest. We don't > want to let this get beyond the end of July, so we can cut DP3 (which > would be inevitable with a new ABI) with the new ABI and get decent > testing. Somewhere between 0 and 3.5 we should have an X) Write a list of proposed changes to the syscalls by just going through the syscalls list and adding proposed changes, based on public discussion. I think the right thing to do might be to just make a copy of syscalls.master and let people commit suggested improvements, and then post it to arch for discussion after a while (e.g, 3 weeks.) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 10:49:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id E7CD137B40E; Tue, 7 May 2002 10:49:37 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g47HnIev023652; Tue, 7 May 2002 10:49:18 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g47HnIAa023651; Tue, 7 May 2002 10:49:18 -0700 (PDT) Date: Tue, 7 May 2002 10:49:18 -0700 From: "David O'Brien" To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.org, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507104918.C23330@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org Mail-Followup-To: David O'Brien , John Baldwin , Matthew Dillon , arch@FreeBSD.ORG, Poul-Henning Kamp References: <200205070815.g478Fn180961@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, May 07, 2002 at 10:33:20AM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 10:33:20AM -0400, John Baldwin wrote: > Right. I would like to use the ELF_ABI_OSVERSION thingie, but according to > O'Brien it violates the ELF spec to use any value other than 0. Not quite. We cannot touch EI_VERSION (this is the ELF spec version). We are able to play with EI_ABIVERSION since we also play with EI_OSABI. EI_ABIVERSION Byte e_ident[EI_ABIVERSION] identifies the the version of the ABI to which the object is targeted. This field is used to distinguish among incompatible versions of an ABI. The interpretation of this version number is dependent on the ABI identified by the EI_OSABI field. Applications conforming to this specification use the value 0 Well, it is a minor violation to use a non-0 value. But what that really means is that given a non-0 value, a generic ELF program manipulating the binary cannot make general assumptions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 10:54: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 24A0D37B408; Tue, 7 May 2002 10:53:56 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.3/8.12.3) with SMTP id g47HrZb5083637; Tue, 7 May 2002 13:53:35 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 7 May 2002 13:53:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Eivind Eklund Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <20020507185119.C11452@phoenix.dmnstech.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 7 May 2002, Eivind Eklund wrote: > Somewhere between 0 and 3.5 we should have an > > X) Write a list of proposed changes to the syscalls by just going > through the syscalls list and adding proposed changes, based on public > discussion. > > I think the right thing to do might be to just make a copy of > syscalls.master and let people commit suggested improvements, and then > post it to arch for discussion after a while (e.g, 3 weeks.) Probably close to the right strategy -- unfortunately most of the more interesting changes are in the supporting structs (struct stat, struct ipcperm, ...), which does complicate things. Also, many of the changes have to do with changing a type -- ino_t, or the like, rather than changing the arguments to the system call. This breaks the ABI, but maintains source-level compatibility as visible in syscalls.master :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 10:56: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 80B3B37B404; Tue, 7 May 2002 10:56:00 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g47HtRev023713; Tue, 7 May 2002 10:55:27 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g47HtQd3023712; Tue, 7 May 2002 10:55:26 -0700 (PDT) Date: Tue, 7 May 2002 10:55:26 -0700 From: "David O'Brien" To: Poul-Henning Kamp Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507105526.E23330@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org Mail-Followup-To: David O'Brien , Poul-Henning Kamp , John Baldwin , Matthew Dillon , arch@FreeBSD.org References: <89017.1020785836@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <89017.1020785836@critter.freebsd.dk>; from phk@critter.freebsd.dk on Tue, May 07, 2002 at 05:37:16PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 05:37:16PM +0200, Poul-Henning Kamp wrote: > I would therefore like to propose that we do something like > the following: > > Repocopy src/sys/sys/* to src/sys/include > Repocopy src/sys/sys/* to src/sys/abi4 This is actually the FreeBSD 3.0 ABI, not an ABI introduced with 4.0. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 11: 1:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 8100037B407 for ; Tue, 7 May 2002 11:01:19 -0700 (PDT) Received: (qmail 32488 invoked from network); 7 May 2002 18:01:18 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 May 2002 18:01:18 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g47I1GF29661; Tue, 7 May 2002 14:01:16 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020507105526.E23330@dragon.nuxi.com> Date: Tue, 07 May 2002 14:01:10 -0400 (EDT) From: John Baldwin To: "David O'Brien" Subject: Re: syscall changes to deal with 32->64 changes. Cc: arch@FreeBSD.org, Matthew Dillon , Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 07-May-2002 David O'Brien wrote: > On Tue, May 07, 2002 at 05:37:16PM +0200, Poul-Henning Kamp wrote: >> I would therefore like to propose that we do something like >> the following: >> >> Repocopy src/sys/sys/* to src/sys/include >> Repocopy src/sys/sys/* to src/sys/abi4 > > This is actually the FreeBSD 3.0 ABI, not an ABI introduced with 4.0. I prefer a suggestion I think you had where the ABI isn't actually linked to freebsd versions, but instead our current ABI is ABI 1 (or 0) and the new ABI would be ABI 2 (or 1). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 11: 9:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 740A237B404 for ; Tue, 7 May 2002 11:09:21 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g47I92ev023922; Tue, 7 May 2002 11:09:02 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g47I91TM023921; Tue, 7 May 2002 11:09:01 -0700 (PDT) Date: Tue, 7 May 2002 11:09:01 -0700 From: "David O'Brien" To: Nathan Hawkins Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507110901.F23330@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG Mail-Followup-To: arch@freebsd.org References: <3CD7FE57.1000508@quic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CD7FE57.1000508@quic.net>; from utsl@quic.net on Tue, May 07, 2002 at 12:18:31PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 12:18:31PM -0400, Nathan Hawkins wrote: > I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle > the binary OS type/versioning. I know that at least NetBSD, Linux and > Hurd do it this way, and I think most others do too. Why? Just to follow the NIH herd? The EI_OSABI and EI_ABIVERSION fields were in the gABI spec before anyone started using .note sections for this. If .note.ABI-tag is the end all and be all, then why did the ELF spec authors even create EI_OSABI and EI_ABIVERSION?? And why did they put things in the ELF header such that things are very easy to parse just by reading a small amount of a binary? A LOT of the things in an ELF header could have been put in .note sections. But they weren't because it is so much easier to read fixed structures. That said, run readelf on any FreeBSD binary, you will find a .note.ABI-tag section. I just never got around to adding support for it to imgact_elf. > It looks like gcc is already inserting them, (run readelf -S, and you No, the section comes from crt1.o actually. > should see it) so it'd be a matter of adding to the binary emulation > selector to check .note.ABI-tag. > For your new ABI, set a version number in the tag. I > believe the tag gcc is putting in already has a field for that. We already put the value of __FreeBSD_version into .note.ABI-tag. (see src/lib/csu/common/crtbrand.c) -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 11:58:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from trantor.utsl.org (cvg-65-27-234-192.cinci.rr.com [65.27.234.192]) by hub.freebsd.org (Postfix) with ESMTP id 5555437B403 for ; Tue, 7 May 2002 11:58:50 -0700 (PDT) Received: from hotrod.utsl.org ([10.10.57.3] helo=quic.net) by trantor.utsl.org with esmtp (Exim 3.35 #1 (Debian)) id 175AAj-00011J-00 for ; Tue, 07 May 2002 14:58:49 -0400 Message-ID: <3CD823E8.2010809@quic.net> Date: Tue, 07 May 2002 14:58:48 -0400 From: Nathan Hawkins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020502 Debian/1.0rc1-3 MIME-Version: 1.0 To: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <3CD7FE57.1000508@quic.net> <20020507110901.F23330@dragon.nuxi.com> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: >On Tue, May 07, 2002 at 12:18:31PM -0400, Nathan Hawkins wrote: > > >>I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle >>the binary OS type/versioning. I know that at least NetBSD, Linux and >>Hurd do it this way, and I think most others do too. >> >> > >Why? Just to follow the NIH herd? The EI_OSABI and EI_ABIVERSION fields >were in the gABI spec before anyone started using .note sections for >this. > > Because AFAICS, it's a defacto, unwritten standard. Even if it violates spec. NIH is a matter of perspective. FreeBSD could be considered to be in NIH mode, because the other ELF based systems use a different method. >If .note.ABI-tag is the end all and be all, then why did the ELF spec >authors even create EI_OSABI and EI_ABIVERSION?? And why did they put >things in the ELF header such that things are very easy to parse just by >reading a small amount of a binary? A LOT of the things in an ELF header >could have been put in .note sections. But they weren't because it is so >much easier to read fixed structures. > I have no axe to grind here. I don't consider the .note.ABI-tag to be a beautiful way to do things. You're right, it should be faster to get this from a field in the ELF header. But you also use the .interp section in the emulation selector code. I think that the .note.ABI-tag would be a better choice. >That said, run readelf on any FreeBSD binary, you will find a >.note.ABI-tag section. I just never got around to adding support for it >to imgact_elf. > Yes, I can see that. I've looked at adding support to imgact_elf. I haven't had time to try yet. ---Nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 12:31:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 762A137B40A; Tue, 7 May 2002 12:31:13 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g47JVDh84057; Tue, 7 May 2002 12:31:13 -0700 (PDT) (envelope-from dillon) Date: Tue, 7 May 2002 12:31:13 -0700 (PDT) From: Matthew Dillon Message-Id: <200205071931.g47JVDh84057@apollo.backplane.com> To: Robert Watson Cc: John Baldwin , arch@FreeBSD.org, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :> I'm also not sure if we shouldn't wait to do this until 6.0. : :Well, that's the big question, really. If we can do it in the time frame, :why wait, as they say :-). If we can't, then it's a 6.0 thing. 5.0 is a :nice breaking point -- we're ripping up so much anyway, and we'd like to :get the ABI changes for UFS2 in. But if the schedule isn't realistic, :then we can't -- slipping 5.0-release any further isn't something I want :to let happen. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project I think the one big advantage with having a new syscall vector is precisely the fact that the new ABI can be worked on without effecting the existing system. Internal system support that is still 32 bits winds up being straight-up in the old syscall vector and extended out in the new, and internal system support that has been changed to 64 bits winds up being truncated in the old syscall vector and straight up in the new. Either way we are able to maintain ABI compatibility for both syscall vectors even if it takes months to convert all the kernel subsystems to the new sizes. This seems to infer that the work will not directly interfere with 5.0R, even if it is not 100% complete by the release. That would make the work 'a go' in my book. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 12:40:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DC98B37B403; Tue, 7 May 2002 12:40:43 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g47Jehl84130; Tue, 7 May 2002 12:40:43 -0700 (PDT) (envelope-from dillon) Date: Tue, 7 May 2002 12:40:43 -0700 (PDT) From: Matthew Dillon Message-Id: <200205071940.g47Jehl84130@apollo.backplane.com> To: John Baldwin Cc: "David O'Brien" , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :On 07-May-2002 David O'Brien wrote: :> On Tue, May 07, 2002 at 05:37:16PM +0200, Poul-Henning Kamp wrote: :>> I would therefore like to propose that we do something like :>> the following: :>> :>> Repocopy src/sys/sys/* to src/sys/include :>> Repocopy src/sys/sys/* to src/sys/abi4 :> :> This is actually the FreeBSD 3.0 ABI, not an ABI introduced with 4.0. : :I prefer a suggestion I think you had where the ABI isn't actually :linked to freebsd versions, but instead our current ABI is ABI 1 (or 0) :and the new ABI would be ABI 2 (or 1). : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ Hmm. I think this may be a little too confusing. Remember that we have serious issues with mainline files in /usr/src/include (aka /usr/include), not just /usr/src/sys/sys. We also have issues with /usr/lib, etc. Why not do something like this: /usr/src/include/ Contains architecture and ABI independant files /usr/src/include/ABIx/ /usr/src/include/ABIy/ /usr/src/include/ABIz/ Contains ABI specific files. For example, /usr/src/include/ABIx/sys (mirrored in /usr/include, aka /usr/include/, /usr/include/ABI/) Then we simply change the default compiler -I path from: /usr/include to /usr/include:/usr/include/ABIxxx where the ABI may be chosen at compile time with an option to cc, and the default is set to whatever the appropriate default is. This makes the 'switch' easy to throw. The compiler/linker is going to need knowledge of the ABI being used anyway since it has to set the ELF parameter, we might as well leverage that for the includes as well. We will need ABI specific libraries as well. e.g. /usr/lib, /usr/lib/ABIx, etc... I really think this is the cleanest, safest way to do it, and it also paves the way for us to allow natively compiled multi-architectural support. e.g. consider this: cc -ABI4 ... cc -ABI5 ... cc -ABILinux ... cc -ABIOpenBSD ... You see what I am getting at? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 13:13:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id EA7D737B408 for ; Tue, 7 May 2002 13:13:15 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g47KDFev029682; Tue, 7 May 2002 13:13:15 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g47KDEvv029681; Tue, 7 May 2002 13:13:14 -0700 (PDT) Date: Tue, 7 May 2002 13:13:14 -0700 From: "David O'Brien" To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507131314.B29014@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG Mail-Followup-To: arch@freebsd.org References: <200205071940.g47Jehl84130@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205071940.g47Jehl84130@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, May 07, 2002 at 12:40:43PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 12:40:43PM -0700, Matthew Dillon wrote: > the way for us to allow natively compiled multi-architectural support. > e.g. consider this: > > cc -ABI4 ... > cc -ABI5 ... > cc -ABILinux ... > cc -ABIOpenBSD ... Honestly, why do we have this need? It seems to fall into the "it would be nice"; but seldomly used. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 14: 0: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 2AD9437B405 for ; Tue, 7 May 2002 13:59:58 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g47Kxvev030099; Tue, 7 May 2002 13:59:57 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g47KxvtY030098; Tue, 7 May 2002 13:59:57 -0700 (PDT) Date: Tue, 7 May 2002 13:59:57 -0700 From: "David O'Brien" To: Nathan Hawkins Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507135957.A30027@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG Mail-Followup-To: David O'Brien , Nathan Hawkins , arch@FreeBSD.ORG References: <3CD7FE57.1000508@quic.net> <20020507110901.F23330@dragon.nuxi.com> <3CD823E8.2010809@quic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CD823E8.2010809@quic.net>; from utsl@quic.net on Tue, May 07, 2002 at 02:58:48PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 02:58:48PM -0400, Nathan Hawkins wrote: > >>I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle > >>the binary OS type/versioning. I know that at least NetBSD, Linux and > >>Hurd do it this way, and I think most others do too. > > > >Why? Just to follow the NIH herd? The EI_OSABI and EI_ABIVERSION fields > >were in the gABI spec before anyone started using .note sections for > >this. > > > Because AFAICS, it's a defacto, unwritten standard. Even if it violates > spec. Your response is mostly content free. But I honestly interested in your response. Could you reread what I said and address it? What is the defacto, unwritten standard? I assume you mean .note sections. > Even if it violates spec. What is "it" and how does it violate the gABI spec? > NIH is a matter of perspective. FreeBSD could be considered to be in NIH > mode, because the other ELF based systems use a different method. FreeBSD was the first to have a need to "brand" binaries. So there was nothing to follow, so no NIH. [The need was to be able to run static Linux binaries. Note that if Linux was strictly gABI compliant there would (1) be no static binaries; and (2) we could not use the dynamic linker's name as a key to know the binary is a Linux one.] > this from a field in the ELF header. But you also use the .interp > section in the emulation selector code. Not really. We do, but that is because few are strictly compliant with the psABI's. For i386 FreeBSD and Linux should be using "/usr/lib/libc.so.1". For Alpha "/usr/lib/ld.so", and for Sparc64 "/usr/libexec/ld-elf.so.1". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 14: 7: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A98637B401; Tue, 7 May 2002 14:07:00 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g47L6YgQ000380; Tue, 7 May 2002 14:06:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g47L6YuT000379; Tue, 7 May 2002 14:06:34 -0700 (PDT) Date: Tue, 7 May 2002 14:06:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200205072106.g47L6YuT000379@apollo.backplane.com> To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <200205071940.g47Jehl84130@apollo.backplane.com> <20020507131314.B29014@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Tue, May 07, 2002 at 12:40:43PM -0700, Matthew Dillon wrote: :> the way for us to allow natively compiled multi-architectural support. :> e.g. consider this: :> :> cc -ABI4 ... :> cc -ABI5 ... :> cc -ABILinux ... :> cc -ABIOpenBSD ... : :Honestly, why do we have this need? It seems to fall into the "it would :be nice"; but seldomly used. Well, how do you intend to test the new ABI vector? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 15:53:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id ED6D037B401; Tue, 7 May 2002 15:53:08 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g47Mr0ob131806; Tue, 7 May 2002 18:53:00 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Tue, 7 May 2002 18:52:59 -0400 To: Robert Watson , Matthew Dillon From: Garance A Drosihn Subject: Re: syscall changes to deal with 32->64 changes. Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:46 AM -0400 5/7/02, Robert Watson wrote: >On Tue, 7 May 2002, Matthew Dillon wrote: > > A bunch of things starting leaking out of the woodwork > > as I was playing around with 64 bit time_t's. At the > > very least I would pad the structures to handle things > > like 64 bit dev_t, ino_t, and file flags, and I would > > even consider padding now 96 bit structures like timespec > > to 128 bits across the board. It might also be worthwhile > > to make uid_t, gid_t, and pid_t 64 bits to support probable > > future work in those areas. > >My understanding from talking with Kirk and Poul-Henning is >that ino_t is definitely on the list already, as are a number >of the others at the file system image layer (such as block >pointers, et al). They should already have much of this >underway, and the temptation is to allow them to do the >grunt work if they're already doing it :-). Certainly we should try to talk them into doing as much of the work as we can convince them to do... :-) >dev_t I don't really have an opinion about. I would really really like to have the larger dev_t, but I expect everyone remembers my previous pleading on the topic. So, I will just add a "pretty please?" here as a reminder. I really think it's the right thing to do for OpenAFS, etc. >I guess the one opinion I haven't heard yet, and am a little >surprised not to have heard is: > > No, we shouldn't do this on architectural grounds. > >We've heard "yes" in various flavors, including moderated >"yes if we can manage it by the release". Not to invite a >bikeshed, but if there's going to be a strong argument >against such a change, it would be nice to hear it sooner. My vote is a pretty strong "yes" for at least the changes that Poul-Henning originally mentioned. I might want to change that vote if we're at mid-July and we can't seem to pull the changes together, but I think the new syscall vector is less painful than trying to do all the UFS2 work (which I *do* want in 5.0) via any other method. I would not mind if 5.0 slipped a month for that work. (not that I want it to slip, but I would not feel bad if we find out that it had to slip one month for this change). Where I start hemming and hawing is when it comes to how many other changes should be added. Basically I want "as many as we can do and still keep to the schedule". I would not want 5.0 to slip for other syscall-ish changes. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 16:17:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 349A037B413 for ; Tue, 7 May 2002 16:17:42 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g47NHUev031608; Tue, 7 May 2002 16:17:30 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g47NHUR7031607; Tue, 7 May 2002 16:17:30 -0700 (PDT) Date: Tue, 7 May 2002 16:17:30 -0700 From: "David O'Brien" To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020507161730.A31409@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG Mail-Followup-To: David O'Brien , Matthew Dillon , arch@FreeBSD.ORG References: <200205071940.g47Jehl84130@apollo.backplane.com> <20020507131314.B29014@dragon.nuxi.com> <200205072106.g47L6YuT000379@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200205072106.g47L6YuT000379@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, May 07, 2002 at 02:06:34PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 02:06:34PM -0700, Matthew Dillon wrote: > > : > :On Tue, May 07, 2002 at 12:40:43PM -0700, Matthew Dillon wrote: > :> the way for us to allow natively compiled multi-architectural support. > :> e.g. consider this: > :> > :> cc -ABI4 ... > :> cc -ABI5 ... > :> cc -ABILinux ... > :> cc -ABIOpenBSD ... > : > :Honestly, why do we have this need? It seems to fall into the "it would > :be nice"; but seldomly used. > > Well, how do you intend to test the new ABI vector? One moves forward and does not look back. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 16:35:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 29F2937B404; Tue, 7 May 2002 16:35:09 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g47NZ8hU001372; Tue, 7 May 2002 16:35:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g47NZ8FY001371; Tue, 7 May 2002 16:35:08 -0700 (PDT) Date: Tue, 7 May 2002 16:35:08 -0700 (PDT) From: Matthew Dillon Message-Id: <200205072335.g47NZ8FY001371@apollo.backplane.com> To: "David O'Brien" Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <200205071940.g47Jehl84130@apollo.backplane.com> <20020507131314.B29014@dragon.nuxi.com> <200205072106.g47L6YuT000379@apollo.backplane.com> <20020507161730.A31409@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Tue, May 07, 2002 at 02:06:34PM -0700, Matthew Dillon wrote: :> :> : :> :On Tue, May 07, 2002 at 12:40:43PM -0700, Matthew Dillon wrote: :> :> the way for us to allow natively compiled multi-architectural support. :> :> e.g. consider this: :> :> :> :> cc -ABI4 ... :> :> cc -ABI5 ... :> :> cc -ABILinux ... :> :> cc -ABIOpenBSD ... :> : :> :Honestly, why do we have this need? It seems to fall into the "it would :> :be nice"; but seldomly used. :> :> Well, how do you intend to test the new ABI vector? : :One moves forward and does not look back. Uh huh. Well, I have some experience with that when I tried changing one of my test boxes over to a 64 bit time_t. I wound up having to wipe the entire machine (raw dd from the backup partition). Twice. To be blunt, making incremental changes and still having a working system at the end of the day required extremely careful attention to detail, and I made two mistakes over the period of several days that I couldn't back out of. In otherwords, my considered opinion is that it would actually be *easier* to do the relatively modest amount of work required to generalize the ABI linkage in order to save a whole lot more work down the line when people actually try to test it. I will note that what I am suggesting is considerably less work then the more radical suggestion Poul had (note: I have no specific opinion on Poul's radical suggestion at this time). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 19:53:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by hub.freebsd.org (Postfix) with ESMTP id 2719837B400; Tue, 7 May 2002 19:53:33 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id 1437028CD6; Wed, 8 May 2002 09:53:29 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 03BC028CD5; Wed, 8 May 2002 09:53:28 +0700 (ALMST) Date: Wed, 8 May 2002 09:53:28 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <89017.1020785836@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 7 May 2002, Poul-Henning Kamp wrote: > We cannot easily compile for two native APIs if we cannot have two > different set of 'sys/*' and 'machine/*' files since a lot of the > types we want to change size on are defined in these files. Not exactly, because #ifdefs can handle this perfectly. Performing diffs on different files is a more simple task though. > I would therefore like to propose that we do something like > the following: > > Repocopy src/sys/sys/* to src/sys/include > Repocopy src/sys/sys/* to src/sys/abi4 > Remove src/sys/sys/* Sounds good, except #includes in various headers may look fuzzy after that, but this is acceptable. Although, this scheme doesn't account data parameters passed to VFS_MOUNT() call. Definitions of these structures lives in fs/*fs.h files. How do you plan to deal with it ? > This should put a good bit of infrastructure in to make current and > future API/ABI implementations simpler and more structured. > > I guess a way to sum this up is that it will put all API/ABI's on > equal footing. With this change none of them will be any more > "native" than any other API/ABI. Agreed. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 20: 0:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from trantor.utsl.org (cvg-65-27-234-192.cinci.rr.com [65.27.234.192]) by hub.freebsd.org (Postfix) with ESMTP id 841CB37B40A for ; Tue, 7 May 2002 20:00:45 -0700 (PDT) Received: from hotrod.utsl.org ([10.10.57.3] helo=quic.net) by trantor.utsl.org with esmtp (Exim 3.35 #1 (Debian)) id 175Hh5-00018U-00 for ; Tue, 07 May 2002 23:00:43 -0400 Message-ID: <3CD894DA.6060602@quic.net> Date: Tue, 07 May 2002 23:00:42 -0400 From: Nathan Hawkins User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020502 Debian/1.0rc1-3 MIME-Version: 1.0 To: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <3CD7FE57.1000508@quic.net> <20020507110901.F23330@dragon.nuxi.com> <3CD823E8.2010809@quic.net> <20020507135957.A30027@dragon.nuxi.com> X-Enigmail-Version: 0.49.5.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: >On Tue, May 07, 2002 at 02:58:48PM -0400, Nathan Hawkins wrote: > > >>>>I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle >>>>the binary OS type/versioning. I know that at least NetBSD, Linux and >>>>Hurd do it this way, and I think most others do too. >>>> >>>> >>>Why? Just to follow the NIH herd? The EI_OSABI and EI_ABIVERSION fields >>>were in the gABI spec before anyone started using .note sections for >>>this. >>> >>> >>> >>Because AFAICS, it's a defacto, unwritten standard. Even if it violates >>spec. >> >Your response is mostly content free. But I honestly interested in your >response. Could you reread what I said and address it? > > All right: 1. Why? How about being able to use stock binutils? The original subject was how to handle some proposed ABI changes. The .note.ABI-tag section has a version field, already in the binaries (since 4.1, I believe.) It looks pretty simple to add a field to Elf_Brandinfo that has the ABI version. exec_elf_imgact could then be altered to select the right sysvec based on OS and ABI version from the note. 2. The EI_OSABI and EI_ABIVERSION fields were in the gABI spec before anyone started using .note sections for this. But there has since been agreement to use the .note sections. One good reason is that it keeps OS specifics out of binutils, and makes it possible to cross compile for another OS on the same architecture. You'd have to alter binutils to change the default EI_ABIVERSION or EI_OSABI field. If you do, how do you compile for the old ABI? The ABI-tags method would allow binutils to support both ABI's, by linking with a different copy of /usr/lib/crt1.o. ---Nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 20: 4:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id A953F37B401; Tue, 7 May 2002 20:04:12 -0700 (PDT) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g4834BL42647; Tue, 7 May 2002 23:04:12 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200205080304.g4834BL42647@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "J. Mallett" Cc: "David O'Brien" , Garance A Drosihn , arch@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 In-Reply-To: Your message of "Wed, 08 May 2002 01:36:53 -0000." <20020508013651.GA28536@FreeBSD.ORG> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 May 2002 23:04:11 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "J. Mallett" wrote: > On Tue, May 07, 2002 at 06:27:50PM -0700, David O'Brien wrote: > > On Wed, May 08, 2002 at 12:59:58AM +0000, J. Mallett wrote: > > > > If a user can not be bothered to use '-I .blah' instead of > > > > '-i.blah', then they can continue to use perl for all I care. > > ... > > > I like your logic better than the logic I've been using. > > > If one or two more people will agree to this, I'll happily make > > > the necessary changes. > > > > I do not agree, I WILL not agree. I will commit -i[ext] later if anyone > > takes it away (or fails to add it). The ENTIRE PURPOSE HERE is to add > > "perl -i" functionality. NOT find how many different ways things can be > > proposed. > > But unless people will shut the hell up about allowing -i with no argument, > we cannot achieve that without adding another option one way or the other. > > [...] Trying to move this to arch: Another option would be to extend getopt(3) in what could simply be a very reasonable way. Here's my proposition for making a "clean" version that acts like Perl: Index: Makefile =================================================================== RCS file: /usr2/ncvs/src/usr.bin/sed/Makefile,v retrieving revision 1.4 diff -u -r1.4 Makefile --- Makefile 8 Feb 2002 23:07:35 -0000 1.4 +++ Makefile 8 May 2002 02:49:35 -0000 @@ -3,6 +3,7 @@ PROG= sed SRCS= compile.c main.c misc.c process.c +SRCS+= getopt.c .include Index: main.c =================================================================== RCS file: /usr2/ncvs/src/usr.bin/sed/main.c,v retrieving revision 1.19 diff -u -r1.19 main.c --- main.c 7 May 2002 23:33:44 -0000 1.19 +++ main.c 8 May 2002 02:58:58 -0000 @@ -124,7 +124,7 @@ fflag = 0; inplace = NULL; - while ((c = getopt(argc, argv, "Eae:f:i:n")) != -1) + while ((c = getopt(argc, argv, "Eae:f:i;n")) != -1) switch (c) { case 'E': rflags = REG_EXTENDED; @@ -146,6 +146,8 @@ break; case 'i': inplace = optarg; + if (inplace == NULL) + inplace = ""; break; case 'n': nflag = 1; @@ -182,8 +184,8 @@ usage() { (void)fprintf(stderr, "%s\n%s\n", - "usage: sed script [-Ean] [-i extension] [file ...]", - " sed [-an] [-i extension] [-e script] ... [-f script_file] ... [file ...]"); + "usage: sed script [-Ean] [-i[extension]] [file ...]", + " sed [-an] [-i[extension]] [-e script] ... [-f script_file] ... [file ...]"); exit(1); } @@ -434,20 +436,21 @@ if (*inplace == '\0') { char template[] = "/tmp/sed.XXXXXXXXXX"; - if (mktemp(template) == NULL) - err(1, "mktemp"); + output = mkstemp(template); + if (output == -1) + err(1, "mkstemp"); strlcpy(backup, template, MAXPATHLEN); } else { strlcpy(backup, *filename, MAXPATHLEN); strlcat(backup, inplace, MAXPATHLEN); + output = open(backup, O_WRONLY|O_CREAT); + if (output == -1) + err(1, "open(%s)", backup); } input = open(*filename, O_RDONLY); if (input == -1) err(1, "open(%s)", *filename); - output = open(backup, O_WRONLY|O_CREAT); - if (output == -1) - err(1, "open(%s)", backup); if (fchmod(output, orig.st_mode & ~S_IFMT) == -1) err(1, "chmod"); buffer = malloc(orig.st_size); --- ../../lib/libc/stdlib/getopt.c Thu Sep 6 02:47:20 2001 +++ getopt.c Tue May 7 22:49:22 2002 @@ -93,12 +93,8 @@ "%s: illegal option -- %c\n", __progname, optopt); return (BADCH); } - if (*++oli != ':') { /* don't need argument */ - optarg = NULL; - if (!*place) - ++optind; - } - else { /* need an argument */ + switch (*++oli) { + case ':': /* need an argument */ if (*place) /* no white space */ optarg = place; else if (nargc <= ++optind) { /* no arg */ @@ -115,6 +111,19 @@ optarg = nargv[optind]; place = EMSG; ++optind; + break; + case ';': /* argument optional */ + if (*place) + optarg = place; + else + optarg = NULL; + place = EMSG; + optind++; + break; + default: /* don't need argument */ + optarg = NULL; + if (!*place) + ++optind; } return (optopt); /* dump back option letter */ } -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 20:21:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BBF2237B401; Tue, 7 May 2002 20:21:18 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g483KrhU002221; Tue, 7 May 2002 20:20:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g483Kpc9002220; Tue, 7 May 2002 20:20:51 -0700 (PDT) Date: Tue, 7 May 2002 20:20:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200205080320.g483Kpc9002220@apollo.backplane.com> To: Boris Popov Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :On Tue, 7 May 2002, Poul-Henning Kamp wrote: : :> We cannot easily compile for two native APIs if we cannot have two :> different set of 'sys/*' and 'machine/*' files since a lot of the :> types we want to change size on are defined in these files. : : Not exactly, because #ifdefs can handle this perfectly. Performing :diffs on different files is a more simple task though. :... :Boris Popov :http://rbp.euro.ru #ifdef's are a bad idea for this case IMHO, at least in regards to being able to develop the new ABI without interfering with the release schedule. I think it is far less dangerous and far more advantageous to simply give each ABI it's own secondary include (-I) path (not to mention making the include files far more readable post-ABI-changes). There is absolutely no need to pollute the include files with #ifdefs. Also we should consider the fact that it may take considerably longer for many ports to become 64-bit time_t safe (not to mention uids, gids, and so forth). Doing the ABI properly with a compiler option and default setting would allow unsafe ports to be compiled to the old ABI on new systems. The power of this capability should not be underestimated. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 20:28:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.19.129.142]) by hub.freebsd.org (Postfix) with ESMTP id 8578737B411; Tue, 7 May 2002 20:28:11 -0700 (PDT) Received: by relay.butya.kz (Postfix, from userid 1000) id D6C5028CD6; Wed, 8 May 2002 10:28:08 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id C5F1C28CD5; Wed, 8 May 2002 10:28:08 +0700 (ALMST) Date: Wed, 8 May 2002 10:28:08 +0700 (ALMST) From: Boris Popov To: Matthew Dillon Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <200205080320.g483Kpc9002220@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 7 May 2002, Matthew Dillon wrote: > #ifdef's are a bad idea for this case IMHO, at least in regards to > being able to develop the new ABI without interfering with the > release schedule. I think it is far less dangerous and far more > advantageous to simply give each ABI it's own secondary include > (-I) path (not to mention making the include files far more readable > post-ABI-changes). There is absolutely no need to pollute the include > files with #ifdefs. Yes, this is what I'm expressed in the "performing diffs" phrase :) > Also we should consider the fact that it may take considerably longer > for many ports to become 64-bit time_t safe (not to mention uids, gids, > and so forth). Doing the ABI properly with a compiler option and default > setting would allow unsafe ports to be compiled to the old ABI on > new systems. The power of this capability should not be underestimated. Heh, different ABI in the different ports is the real fun of it. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 23: 6:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id 60C5737B407 for ; Tue, 7 May 2002 23:06:37 -0700 (PDT) Received: from pool0728.cvx21-bradley.dialup.earthlink.net ([209.179.194.218] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 175Kay-0002Ux-00; Tue, 07 May 2002 23:06:36 -0700 Message-ID: <3CD8C04E.A62999D9@mindspring.com> Date: Tue, 07 May 2002 23:06:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: arch@FreeBSD.ORG Cc: Nathan Hawkins Subject: Re: syscall changes to deal with 32->64 changes. References: <3CD7FE57.1000508@quic.net> <20020507110901.F23330@dragon.nuxi.com> <3CD823E8.2010809@quic.net> <20020507135957.A30027@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > Even if it violates spec. > What is "it" and how does it violate the gABI spec? I think he means a non-zero EI_OSABI and/or EI_ABIVERSION. Basically, you are supposed to go through the standards process to define values other than 0. It's like defining a new "MIME type". > > NIH is a matter of perspective. FreeBSD could be considered to be in NIH > > mode, because the other ELF based systems use a different method. > > FreeBSD was the first to have a need to "brand" binaries. So there was > nothing to follow, so no NIH. > > [The need was to be able to run static Linux binaries. Note that if > Linux was strictly gABI compliant there would (1) be no static > binaries; and (2) we could not use the dynamic linker's name as a key > to know the binary is a Linux one.] FreeBSD has static binaries, too. I almost suggested "branding" the images, but that's really ridiculous. The closest thing I have seen to a real answer is the ABI command line argument to the compiler, and I think that's a really bad idea, too, though you have to wonder how a commercial vendor will get the old ABI. If I were a commercial vendor offering a binary, I would target the binary to the lowest common denominator, which would mean I would target the oldest ABI that could support the necessary functions to make the program work. The NetWare ABI has this same problem, with people targetting oder ABI's -- mostly because they can, since NetWare maintains interfaces back to the 2.0a version (early 1980's), and ships them with the libraries in the SDK. If you want to have the largest possible audience/customer base, then you target the least common denominator. Actually... I'm not really aware of any installations which don't have the "bindery emulation" NLM loaded so that they can run older software on their Novell network. > > this from a field in the ELF header. But you also use the .interp > > section in the emulation selector code. > > Not really. We do, but that is because few are strictly compliant with > the psABI's. For i386 FreeBSD and Linux should be using > "/usr/lib/libc.so.1". For Alpha "/usr/lib/ld.so", and for Sparc64 > "/usr/libexec/ld-elf.so.1". Yep. The problem is that some of the system calls have been co-opt'ed, so binary compatability with the EABI spec and some commercial OS's isn't possible. Ideally, when Linux went and exceeded the scope of the Solaris ABI, and added binary incompatabilities (e.g. differences in manifest constant values, elimination of character devices, etc.), they should have used a different kernel entry vector. Even more ideally, they would have just conformed to the solaris EABI, and all the code would "just run". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 23:21:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 7F51D37B406; Tue, 7 May 2002 23:21:12 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g486LC431361; Tue, 7 May 2002 23:21:12 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 1EB7238FF; Tue, 7 May 2002 23:21:12 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: John Baldwin Cc: Matthew Dillon , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Date: Tue, 07 May 2002 23:21:12 -0700 From: Peter Wemm Message-Id: <20020508062112.1EB7238FF@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 07-May-2002 Matthew Dillon wrote: > > As a person who has already spent several days playing with > > 64 bit time_t's and associated syscalls I would say that > > creating a new syscall vector for FreeBSD 5.0 (and leaving the > > existing one intact for compatibility) is the correct solution. > > I agree completely. > > > I tried to add new syscalls to the existing vector but so many > > syscalls had to be changed to support 64 bit time_t's that it > > became a huge mess... so much so that I would expect the other > > BSD's to cry foul on us if we tried to do it with the existing > > vector. It will be far, far cleaner to simply implement an > > entirely new syscall vector / ELF identifier. > > Right. I would like to use the ELF_ABI_OSVERSION thingie, but according to > O'Brien it violates the ELF spec to use any value other than 0. But then > why does it exist if we can't use it? :( EI_OSABI (index 7) and EI_ABIVERSION (index 8) are *NOT* in the original ELF spec. They were added relatively recently, and a SVR4 ABI compliant binary must (by definition) have these at value zero since it doesn't exist on SVR4. #define EI_OSABI 7 /* Operating system / ABI identification */ #define EI_ABIVERSION 8 /* ABI version */ With EI_OSABI = 9 (ELFOSABI_FREEBSD), we are by definition not strictly SVR4 ELF ABI compliant. But so what? We hardly provide the SVR4 layout for 'struct stat' etc anyway.. With EI_OSABI == FreeBSD, then EI_ABIVERSION == ours to play with as we see fit. (EI_ABIVERSION being non-zero will be no more of a problem than EI_OSABI being non-zero since traditional ELF tools know about *neither* of them). Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 23:22:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 63DC437B407; Tue, 7 May 2002 23:22:42 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g486Mg431375; Tue, 7 May 2002 23:22:42 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id E209C38CC; Tue, 7 May 2002 23:22:41 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: obrien@FreeBSD.ORG Cc: Poul-Henning Kamp , John Baldwin , Matthew Dillon , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <20020507105526.E23330@dragon.nuxi.com> Date: Tue, 07 May 2002 23:22:41 -0700 From: Peter Wemm Message-Id: <20020508062241.E209C38CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "David O'Brien" wrote: > On Tue, May 07, 2002 at 05:37:16PM +0200, Poul-Henning Kamp wrote: > > I would therefore like to propose that we do something like > > the following: > > > > Repocopy src/sys/sys/* to src/sys/include > > Repocopy src/sys/sys/* to src/sys/abi4 > > This is actually the FreeBSD 3.0 ABI, not an ABI introduced with 4.0. Also note that we already have a 32-bit freebsd abi emulation in /sys/ia64/ia32.. The x86 syscalls are wrapperized and converted to 64 bit. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue May 7 23:28:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id B67B537B401 for ; Tue, 7 May 2002 23:28:37 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g486Sb431400 for ; Tue, 7 May 2002 23:28:37 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 696D738CC; Tue, 7 May 2002 23:28:37 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Nathan Hawkins Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <3CD823E8.2010809@quic.net> Date: Tue, 07 May 2002 23:28:37 -0700 From: Peter Wemm Message-Id: <20020508062837.696D738CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nathan Hawkins wrote: > David O'Brien wrote: > > >On Tue, May 07, 2002 at 12:18:31PM -0400, Nathan Hawkins wrote: > > > > > >>I'd like to see FreeBSD start using ELF .note.ABI-tag sections to handle > >>the binary OS type/versioning. I know that at least NetBSD, Linux and > >>Hurd do it this way, and I think most others do too. > >> > >> > > > >Why? Just to follow the NIH herd? The EI_OSABI and EI_ABIVERSION fields > >were in the gABI spec before anyone started using .note sections for > >this. > > > > > Because AFAICS, it's a defacto, unwritten standard. Even if it violates > spec. > > NIH is a matter of perspective. FreeBSD could be considered to be in NIH > mode, because the other ELF based systems use a different method. I seem to recall that NetBSD invented .note.ABI-tag and pushed it back to the binutils folks. In a later revision of ELF, the EI_OSABI stuff was added. .note.ABI-tag predated those additions. When FreeBSD first started dabbling with ELF, the NetBSD folks were tinkering with the .note (and PT_NOTE executable header) stuff, and Linux had a "personality" syscall. For linux, ELF executables started up in "SVR4 mode" and the personality syscall changed it to "linux". (SYS_personality was a syscall number that didn't exist on SVR4). We didn't do *anything* with note sections till much much later on. We still have an emulation stub for it.. see sys/compat/linux/linux_misc.c /* * UGH! This is just about the dumbest idea I've ever heard!! */ int linux_personality(struct thread *td, struct linux_personality_args *args) { #ifdef DEBUG if (ldebug(personality)) printf(ARGS(personality, "%d"), args->per); #endif #ifndef __alpha__ if (args->per != 0) return EINVAL; #endif /* Yes Jim, it's still a Linux... */ td->td_retval[0] = 0; return 0; } Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 0: 0:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 7714437B401; Wed, 8 May 2002 00:00:01 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g48701431474; Wed, 8 May 2002 00:00:01 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 1BF6F38FD; Wed, 8 May 2002 00:00:01 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <89017.1020785836@critter.freebsd.dk> Date: Wed, 08 May 2002 00:00:01 -0700 From: Peter Wemm Message-Id: <20020508070001.1BF6F38FD@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > Well, seems like some sort of concensus is building. > > Now for a bit of radical thinking. > > The FreeBSD kernel is already a multi-API kernel, we have freebsd > syscalls, including various old compat stuff, we have NetBSD compat, > we have BSDI compat, Linuxolator, IBCS2, and we will probably have > Solaris compat on the sparc64 platform. Also, dont forget x86-64 and ia64 which will now have 3, 4 or 5 syscall vectors to deal with. 1) 32 bit i386 a.out <= 4.x (yes, a.out is still supported) 2) 32 bit i386 ELF <= 4.x 3) 32 bit i386 ELF >= 5.x 4) 64 bit x86-64 ELF / 64 bit ia64 ELF 5) 32 bit IA64 ELF (you can compile in ILP32 mode) Personally, that's several too many already. :-( (and yes, I know that a.out and elf currently share the syscall vector part.. but not the executable loader.. they have different startup mechanisms and different kernel entry trap methods.) We're already having enough trouble copying around the MPSAFE tag in all those damn syscall.master's.. We dont need more. > We cannot easily compile for two native APIs if we cannot have two > different set of 'sys/*' and 'machine/*' files since a lot of the > types we want to change size on are defined in these files. > > I would therefore like to propose that we do something like > the following: > > Repocopy src/sys/sys/* to src/sys/include > Repocopy src/sys/sys/* to src/sys/abi4 > Remove src/sys/sys/* > > In src/sys/include we remove everything which deals with > syscall parameters, but retain kernel internal data structures. > Stuff like vnodes, and similar lives here. > > In src/sys/abi4 we remove everything that we leave behind > in src/sys/include. > > (A similar split should be done for src/sys/$arch/include > into a src/sys/$arch/abi4 directory) > > In .c land we repocopy the relevant sys/kern/*.c files > into sys/abi4 and remove everything but the syscall > entry points and add explicit conversions to arguments > as needed. > > We now have a clean split between the stuff which defines > what goes on in the kernel and the stuff which defines > the ABI to userland. > > Adding a new ABI is now a matter of creating the relevant > directories (src/sys/abi5) and populating with files which > does it right. > > I see many advantages to this way of doing things: > > We can remove practically all "#ifdef _KERNEL" from the .h files > we install in /usr/include/sys and we can get a fair bit closer to > whatever the standard-du-jour dictates that we put there. > > Conversely we can clean the kernel side of things (src/sys/include) > for things we don't want people to use in the kernel, but which > standards or compatibility demand we put in . > > We also get a clear kernel / userland split on C types, we may find > it convenient to operate on a 64 bit foo_t in the kernel but leave > it 32 bit in userland and this lets us trivially do so. > > This should put a good bit of infrastructure in to make current and > future API/ABI implementations simpler and more structured. > > I guess a way to sum this up is that it will put all API/ABI's on > equal footing. With this change none of them will be any more > "native" than any other API/ABI. Personally, I think this is *way* overkill. I think there is far more value to be had by divorcing the syscall interfaces from the code that implements them so we can do away with the damn stackgap stuff. eg: instead of open() doing the copyin *and* the body of the work, we should have sys_open (or abi4_open, linux_open, etc) which do the pathname copyin, any args massaging etc, and then call open() with the cleaned up arguments. open() shouldn't have to do copyin etc. The ia64 32 bit emulator already does the 32 bit time_t <-> 64 bit time_t conversions. There are quite a few that need translation, not the least of which are: struct rusage (all the wait* syscalls), struct statfs, things like setitimer etc which take timevals, select (timeval), gettimeofday(timeval), struct stat, utimes(time_t), adjtime(timeval), readv/writev/pread/pwrite etc and all the syscalls that use iovec's (there is a 'long' in there if you're thinking about making it all explicit sized as well). In fact, gettimeofday is a classic example, the following taken from the sys/ia64/ia32/ia32_misc.c code that we're using now: int ia32_gettimeofday(struct thread *td, struct ia32_gettimeofday_args *uap) { int error; caddr_t sg; struct timeval32 *p32, s32; struct timeval *p = NULL, s; p32 = SCARG(uap, tp); if (p32) { sg = stackgap_init(); p = stackgap_alloc(&sg, sizeof(struct timeval)); SCARG(uap, tp) = (struct timeval32 *)p; } error = gettimeofday(td, (struct gettimeofday_args *) uap); if (error) return (error); if (p32) { error = copyin(p, &s, sizeof(s)); if (error) return (error); CP(s, s32, tv_sec); CP(s, s32, tv_usec); error = copyout(&s32, p32, sizeof(s32)); if (error) return (error); } return (error); } Do you really want to impose all those copyin/outs etc on common paths for 4.x binaries? We need to spend more effort on things like having a seperate sys_gettimeofday(td, struct gettimeofday_args *uap) vs gettimeofday(td, struct timeval *tv); You then have: int gettimeofday(td, struct timeval *tv) { .. normal code but no copyout ... } int sys_gettimeofday(td, uap) /* native 5.x syscall */ { int error; struct timeval tv; /* native kernel timeval */ error = gettimeofday(td, &tv); if (error == 0 && uap->tp) error = copyout(&tv, uap->tp, sizeof(tv)); return error; } int sys_gettimeofday32(td, uap) /* 32 bit syscall interface */ { int error; struct timeval tv; struct timeval32 tv32; /* userland 32 bit timeval */ error = gettimeofday(td, &tv); convert_tv_to_tv32(&tv, &tv32); if (error == 0 && uap->tp) error = copyout(&tv32, uap->tp, sizeof(tv32)); return error; } and so on. Lots less bogus copyin/outs through the stackgap. You can use your local stack for temporary conversions, or even malloc etc. But trying to do it in userland because we dont cleanly divorce the syscall ABI implementation with the functionality just sucks. Finally, I really think the entire-new-syscall vector idea is sheer wasteful overkill. I'd much rather we had COMPAT_FREEBSD4 kernel compile options using the existing vector with new syscalls added in that we need to translate. What I saw on SVR4 was much cleaner. They dealt with different "struct stat"'s wit no trouble at all. You could even compile to the older interfaces. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 0:19:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 9D01437B400 for ; Wed, 8 May 2002 00:19:16 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g487IXJ81349; Wed, 8 May 2002 00:18:33 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3) with ESMTP id g487IXtu007620; Wed, 8 May 2002 00:18:33 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g487IXJ4007619; Wed, 8 May 2002 00:18:33 -0700 (PDT) Date: Wed, 8 May 2002 00:18:32 -0700 From: Marcel Moolenaar To: Peter Wemm Cc: Nathan Hawkins , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020508071832.GA7568@dhcp01.pn.xcllnt.net> References: <3CD823E8.2010809@quic.net> <20020508062837.696D738CC@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020508062837.696D738CC@overcee.wemm.org> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 11:28:37PM -0700, Peter Wemm wrote: > > > > > >Why? Just to follow the NIH herd? The EI_OSABI and EI_ABIVERSION fields > > >were in the gABI spec before anyone started using .note sections for > > >this. > > > > > > > > Because AFAICS, it's a defacto, unwritten standard. Even if it violates > > spec. > > > > NIH is a matter of perspective. FreeBSD could be considered to be in NIH > > mode, because the other ELF based systems use a different method. > > I seem to recall that NetBSD invented .note.ABI-tag and pushed it back > to the binutils folks. Interestingly, the LSB (Linux Standards Body) version 1.1.0 has it documented as Linux specific. My whole take on the ELF aspect is that we should use EI_OSABI and EI_ABIVERSION and stop trying to be more compliant than the standard allows. It's basicly a mess and nobody is truely compliant anyway. The new draft has EI_OSABI and EI_ABIVERSION documented for years, so I think we can speculatively use it. If our toolchain throws in a .note.ABI-tag section than so be it; we might as well give it sensible contents. I don't think we should use it as the primary means to select the ABI though. FWIW, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 0:58:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 39F8137B406; Wed, 8 May 2002 00:58:23 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g487wJhU003211; Wed, 8 May 2002 00:58:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g487wJtZ003208; Wed, 8 May 2002 00:58:19 -0700 (PDT) Date: Wed, 8 May 2002 00:58:19 -0700 (PDT) From: Matthew Dillon Message-Id: <200205080758.g487wJtZ003208@apollo.backplane.com> To: Peter Wemm Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. References: <20020508070001.1BF6F38FD@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Personally, I think this is *way* overkill. : :I think there is far more value to be had by divorcing the syscall :interfaces from the code that implements them so we can do away with the :damn stackgap stuff. : :eg: instead of open() doing the copyin *and* the body of the work, :we should have sys_open (or abi4_open, linux_open, etc) which do the pathname :copyin, any args massaging etc, and then call open() with the cleaned up :arguments. open() shouldn't have to do copyin etc. I would love to see this too. Just looking at the hell the linux syscall emulation code goes through is enough to convince me. (I don't agree with your argument against adding another syscall vector, however, because I see no other solution that is clean enough to be a reasonable replacement). :Finally, I really think the entire-new-syscall vector idea is sheer :wasteful overkill. I'd much rather we had COMPAT_FREEBSD4 kernel compile :options using the existing vector with new syscalls added in that we need :to translate. What I saw on SVR4 was much cleaner. They dealt with :different "struct stat"'s wit no trouble at all. You could even compile :to the older interfaces. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com :"All of this is for nothing if we don't go to the stars" - JMS/B5 This is what I tried to do when I was messing around with time_t and I came to regret it. There are just too many system calls that need to be changed to simply be able to add them to the existing vector. Take the 'stat' mess and multiply by about 20 and the result is the mess you would get if you tried to integrate the 64 bit calls into the existing vector. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 1:18:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by hub.freebsd.org (Postfix) with ESMTP id BE08037B404 for ; Wed, 8 May 2002 01:18:20 -0700 (PDT) Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 175MdE-0003Ov-00; Wed, 08 May 2002 09:17:04 +0100 Date: Wed, 8 May 2002 09:17:04 +0100 From: Christoph Hellwig To: Peter Wemm Cc: Nathan Hawkins , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020508091704.A12628@infradead.org> References: <3CD823E8.2010809@quic.net> <20020508062837.696D738CC@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020508062837.696D738CC@overcee.wemm.org>; from peter@wemm.org on Tue, May 07, 2002 at 11:28:37PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 11:28:37PM -0700, Peter Wemm wrote: > syscall. For linux, ELF executables started up in "SVR4 mode" and the > personality syscall changed it to "linux". That's wrong. On Linux ELF binaries start as normal linux processes. Depending on whether binary emulation is enabled and certain hints are found (SCO elfmark branding, different interpreter) they are forced to be foreign personalities. Also if binaries issues syscalls on foreign syscalls vectors (e.g. lcall27 for Solaris/ix86 or lcall7 for the i386 SVR3/SVR4 derivates.). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 1:38:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 8036F37B405; Wed, 8 May 2002 01:38:06 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g488c6431724; Wed, 8 May 2002 01:38:06 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 1EA9E38CC; Wed, 8 May 2002 01:38:06 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: Poul-Henning Kamp , John Baldwin , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <200205080758.g487wJtZ003208@apollo.backplane.com> Date: Wed, 08 May 2002 01:38:06 -0700 From: Peter Wemm Message-Id: <20020508083806.1EA9E38CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :Finally, I really think the entire-new-syscall vector idea is sheer > :wasteful overkill. I'd much rather we had COMPAT_FREEBSD4 kernel compile > :options using the existing vector with new syscalls added in that we need > :to translate. What I saw on SVR4 was much cleaner. They dealt with > :different "struct stat"'s wit no trouble at all. You could even compile > :to the older interfaces. > > This is what I tried to do when I was messing around with time_t and > I came to regret it. There are just too many system calls that need > to be changed to simply be able to add them to the existing vector. > Take the 'stat' mess and multiply by about 20 and the result is the > mess you would get if you tried to integrate the 64 bit calls into the > existing vector. struct stat is pretty easy. Have a look at what NetBSD did. It is quite simple. http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/syssrc/sys/sys/stat.h?rev=1.41&content-type=text/x-cvsweb-markup They define the different struct stat's and use a __RENAME() macro from cdefs.h. They can even trivially compile a binary that uses their 1.2 binary interface vs their current 1.3 interface. IMHO, 'struct stat' is hardly a reason for a new syscall vector when it can be solved other ways so easily. I would not be suprised if all the others couldn't be done pretty easily too. I'm not sure that a new syscall vector will gain us much at the end of the day other than an even bigger kernel with more tables to get out of sync... This is right up there with "Hey! lets reorder ASCII so that it is more sensible!". At the end of the day we now have *two* character sets and now have the difficulty of keeping track which is which. And the end user sees nothing new, he's still got all the same keys to type with... He's not going to care all that much if it is easier to memorize the 'new-ascii' code table. At face value it looks like a good idea, but I dont any real benefit except more work that people have to do. [Note, I am *not* suggesting that we keep time_t and other types small, I am just questioning the elaborate path to get there. A cynic might wonder if somebody was getting paid by the hour for this... ] Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 1:56:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wemm.org (12-232-135-171.client.attbi.com [12.232.135.171]) by hub.freebsd.org (Postfix) with ESMTP id 320DC37B403 for ; Wed, 8 May 2002 01:56:25 -0700 (PDT) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (8.11.6/8.11.6) with ESMTP id g488uP431765 for ; Wed, 8 May 2002 01:56:25 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id CE66B38CC; Wed, 8 May 2002 01:56:24 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Christoph Hellwig Cc: Nathan Hawkins , arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: <20020508091704.A12628@infradead.org> Date: Wed, 08 May 2002 01:56:24 -0700 From: Peter Wemm Message-Id: <20020508085624.CE66B38CC@overcee.wemm.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Christoph Hellwig wrote: > On Tue, May 07, 2002 at 11:28:37PM -0700, Peter Wemm wrote: > > syscall. For linux, ELF executables started up in "SVR4 mode" and the > > personality syscall changed it to "linux". > > That's wrong. On Linux ELF binaries start as normal linux processes. > Depending on whether binary emulation is enabled and certain hints are > found (SCO elfmark branding, different interpreter) they are forced to > be foreign personalities. Also if binaries issues syscalls on foreign > syscalls vectors (e.g. lcall27 for Solaris/ix86 or lcall7 for the > i386 SVR3/SVR4 derivates.). Bah, you are correct. The last I looked at the code was around 1.2 era, and looking again: if (strcmp(elf_interpreter,"/usr/lib/libc.so.1") == 0 || strcmp(elf_interpreter,"/usr/lib/ld.so.1") == 0) ibcs2_interpreter = 1; .. current->personality = (ibcs2_interpreter ? PER_SVR4 : PER_LINUX); Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 2: 9:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 9304137B406; Wed, 8 May 2002 02:09:34 -0700 (PDT) Received: from mailgate.nlsystems.com ([62.49.251.130] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 175NRv-0009XY-0W; Wed, 08 May 2002 10:09:27 +0100 Received: from herring.nlsystems.com (localhost [127.0.0.1]) by herring.nlsystems.com (8.12.3/8.11.2) with ESMTP id g4899OvN000939; Wed, 8 May 2002 10:09:24 +0100 (BST) (envelope-from dfr@herring.nlsystems.com) Received: (from dfr@localhost) by herring.nlsystems.com (8.12.3/8.12.3/Submit) id g4899Hx7000938; Wed, 8 May 2002 10:09:17 +0100 (BST) Content-Type: text/plain; charset="iso-8859-1" From: Doug Rabson To: Peter Wemm , obrien@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Date: Wed, 8 May 2002 10:09:17 +0100 User-Agent: KMail/1.4.1 Cc: Poul-Henning Kamp , John Baldwin , Matthew Dillon , arch@FreeBSD.ORG References: <20020508062241.E209C38CC@overcee.wemm.org> In-Reply-To: <20020508062241.E209C38CC@overcee.wemm.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200205081009.17244.dfr@nlsystems.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wednesday 08 May 2002 7:22 am, Peter Wemm wrote: > "David O'Brien" wrote: > > On Tue, May 07, 2002 at 05:37:16PM +0200, Poul-Henning Kamp wrote: > > > I would therefore like to propose that we do something like > > > the following: > > > > > > =09Repocopy src/sys/sys/* to src/sys/include > > > =09Repocopy src/sys/sys/* to src/sys/abi4 > > > > This is actually the FreeBSD 3.0 ABI, not an ABI introduced with 4.0. > > Also note that we already have a 32-bit freebsd abi emulation in > /sys/ia64/ia32.. The x86 syscalls are wrapperized and converted > to 64 bit. That place is not the final home for the thing either. I would like to be= able=20 to use the same code for all ilp32 process on lp64 kernel situations (e.g= =2E=20 sparc32 on sparc64, i386 on x86-64 etc.) --=20 Doug Rabson=09=09=09=09Mail: dfr@nlsystems.com =09=09=09=09=09Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 3:31:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 6AA3237B403 for ; Wed, 8 May 2002 03:31:09 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g48AUSHA006913; Wed, 8 May 2002 12:30:33 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. In-Reply-To: Your message of "Wed, 08 May 2002 00:00:01 PDT." <20020508070001.1BF6F38FD@overcee.wemm.org> Date: Wed, 08 May 2002 12:30:28 +0200 Message-ID: <6912.1020853828@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020508070001.1BF6F38FD@overcee.wemm.org>, Peter Wemm writes: >I think there is far more value to be had by divorcing the syscall >interfaces from the code that implements them so we can do away with the >damn stackgap stuff. Uhm, that was what I tried to express with my proposal. >eg: instead of open() doing the copyin *and* the body of the work, >we should have sys_open (or abi4_open, linux_open, etc) which do the pathname >copyin, any args massaging etc, and then call open() with the cleaned up >arguments. open() shouldn't have to do copyin etc. Exactly. And that means that we can ditch the MPSAFE thing in the syscall.master file, since the *_open() function will be MPSAFE nomatter what and if open() isn't MPSAFE, then open() will grab and release GIANT. >Finally, I really think the entire-new-syscall vector idea is sheer >wasteful overkill. Having looked at the number of syscalls we have to deal with I think it is the only practically passable route. I havn't heard any comments on the splitting of the #include files ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 5:10:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id A949C37B401 for ; Wed, 8 May 2002 05:10:45 -0700 (PDT) Received: (qmail 4184 invoked from network); 8 May 2002 12:10:43 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 May 2002 12:10:43 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g48CAgF33151; Wed, 8 May 2002 08:10:42 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <6912.1020853828@critter.freebsd.dk> Date: Wed, 08 May 2002 08:10:41 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. Cc: arch@FreeBSD.ORG, Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-May-2002 Poul-Henning Kamp wrote: > And that means that we can ditch the MPSAFE thing in the syscall.master > file, since the *_open() function will be MPSAFE nomatter what and if > open() isn't MPSAFE, then open() will grab and release GIANT. Maxime Henrion is already working on this anyways. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 8:46:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D59E537B408; Wed, 8 May 2002 08:46:12 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B5134535E; Wed, 8 May 2002 17:46:08 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "Brian F. Feldman" Cc: "J. Mallett" , "David O'Brien" , Garance A Drosihn , arch@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 References: <200205080304.g4834BL42647@green.bikeshed.org> From: Dag-Erling Smorgrav Date: 08 May 2002 17:46:08 +0200 In-Reply-To: <200205080304.g4834BL42647@green.bikeshed.org> Message-ID: Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Brian F. Feldman" writes: > Index: Makefile > =================================================================== > RCS file: /usr2/ncvs/src/usr.bin/sed/Makefile,v > retrieving revision 1.4 > diff -u -r1.4 Makefile > --- Makefile 8 Feb 2002 23:07:35 -0000 1.4 > +++ Makefile 8 May 2002 02:49:35 -0000 > @@ -3,6 +3,7 @@ > > PROG= sed > SRCS= compile.c main.c misc.c process.c > +SRCS+= getopt.c > > > .include What's this for? Leftovers from testing? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 8:48: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id A2B2D37B407 for ; Wed, 8 May 2002 08:47:49 -0700 (PDT) Received: (qmail 3578 invoked from network); 8 May 2002 15:47:48 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 May 2002 15:47:48 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g48FlkF33813; Wed, 8 May 2002 11:47:46 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 08 May 2002 11:47:39 -0400 (EDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, arch@FreeBSD.ORG, Garance A Drosihn , "David O'Brien" , "J. Mallett" , "Brian F. Feldman" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-May-2002 Dag-Erling Smorgrav wrote: > "Brian F. Feldman" writes: >> Index: Makefile >> =================================================================== >> RCS file: /usr2/ncvs/src/usr.bin/sed/Makefile,v >> retrieving revision 1.4 >> diff -u -r1.4 Makefile >> --- Makefile 8 Feb 2002 23:07:35 -0000 1.4 >> +++ Makefile 8 May 2002 02:49:35 -0000 >> @@ -3,6 +3,7 @@ >> >> PROG= sed >> SRCS= compile.c main.c misc.c process.c >> +SRCS+= getopt.c >> >> >> .include > > What's this for? Leftovers from testing? I think green was implying that sed would have its own getopt instead of changing the system getopt. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 8:49:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DDD9337B40E; Wed, 8 May 2002 08:49:35 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 08E32535E; Wed, 8 May 2002 17:49:34 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: John Baldwin Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, arch@FreeBSD.ORG, Garance A Drosihn , "David O'Brien" , "J. Mallett" , "Brian F. Feldman" Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 References: From: Dag-Erling Smorgrav Date: 08 May 2002 17:49:33 +0200 In-Reply-To: Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin writes: > I think green was implying that sed would have its own getopt instead > of changing the system getopt. Ugh. Nasty. Especially if the modified getopt() could be useful to other programs as well (do we have any programs with options that take optional arguments?) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 8:50:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from phoenix.dmnstech.net (phoenix.dmnstech.net [194.19.34.94]) by hub.freebsd.org (Postfix) with SMTP id 4272B37B41D; Wed, 8 May 2002 08:50:04 -0700 (PDT) Received: (from eivind@localhost) by phoenix.dmnstech.net (8.12.2/8.11.6) id g48FnmIC031647; Wed, 8 May 2002 17:49:48 +0200 (CEST) (envelope-from eivind) Date: Wed, 8 May 2002 17:49:48 +0200 From: Eivind Eklund To: Robert Watson Cc: John Baldwin , Matthew Dillon , arch@FreeBSD.ORG, Poul-Henning Kamp Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020508174948.B28633@phoenix.dmnstech.net> References: <20020507185119.C11452@phoenix.dmnstech.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rwatson@FreeBSD.ORG on Tue, May 07, 2002 at 01:53:35PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 01:53:35PM -0400, Robert Watson wrote: > > On Tue, 7 May 2002, Eivind Eklund wrote: > > > Somewhere between 0 and 3.5 we should have an > > > > X) Write a list of proposed changes to the syscalls by just going > > through the syscalls list and adding proposed changes, based on public > > discussion. > > > > I think the right thing to do might be to just make a copy of > > syscalls.master and let people commit suggested improvements, and then > > post it to arch for discussion after a while (e.g, 3 weeks.) > > Probably close to the right strategy -- unfortunately most of the more > interesting changes are in the supporting structs (struct stat, struct > ipcperm, ...), which does complicate things. Also, many of the changes > have to do with changing a type -- ino_t, or the like, rather than > changing the arguments to the system call. This breaks the ABI, but > maintains source-level compatibility as visible in syscalls.master :-). I was thinking of adding the suggested improvements as comments between the lines in the copy of syscalls.master, just using it as a red thread to make sure we examine a number of the relevant issues, and get a structured document out. And even the conversions you mention would end up being relevant there, as we would add comments on which syscalls would need a converting frontend to gain backwards compatibility. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 9: 5:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from storm.FreeBSD.org.uk (storm.FreeBSD.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id 3228337B400 for ; Wed, 8 May 2002 09:05:22 -0700 (PDT) Received: from storm.FreeBSD.org.uk (uucp@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.12.2/8.12.2) with ESMTP id g48G5ID5058346; Wed, 8 May 2002 17:05:18 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Received: (from uucp@localhost) by storm.FreeBSD.org.uk (8.12.2/8.12.2/Submit) with UUCP id g48G5Ihv058345; Wed, 8 May 2002 17:05:18 +0100 (BST) Received: from grimreaper.grondar.org (localhost [127.0.0.1]) by grimreaper.grondar.org (8.12.3/8.12.3) with ESMTP id g48G3KjV084431; Wed, 8 May 2002 17:03:20 +0100 (BST) (envelope-from mark@grimreaper.grondar.org) Message-Id: <200205081603.g48G3KjV084431@grimreaper.grondar.org> To: Dag-Erling Smorgrav Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 References: In-Reply-To: ; from Dag-Erling Smorgrav "08 May 2002 17:49:33 +0200." Date: Wed, 08 May 2002 17:03:20 +0100 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ CC: list assaulted with a machete ] > John Baldwin writes: > > I think green was implying that sed would have its own getopt instead > > of changing the system getopt. > > Ugh. Nasty. Especially if the modified getopt() could be useful to > other programs as well (do we have any programs with options that take > optional arguments?) At the risk of detracting from the matter at hand, this would be a useful extension to getopt(3), as would the ability to have numeric-only options (a' la "tail -123"), that is not just single digits, but whole numbers. I'm not going to write it, I'm not going argue about it, and I'm not going to say any more about it, so if this is utterly ridiculous, then ignore me and this branch of the thread will die :-). M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 10:28:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5357237B407; Wed, 8 May 2002 10:28:37 -0700 (PDT) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g48HSYf47716; Wed, 8 May 2002 13:28:36 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200205081728.g48HSYf47716@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: John Baldwin , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org, Garance A Drosihn , "David O'Brien" , "J. Mallett" Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 In-Reply-To: Your message of "08 May 2002 17:49:33 +0200." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 May 2002 13:28:34 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > John Baldwin writes: > > I think green was implying that sed would have its own getopt instead > > of changing the system getopt. > > Ugh. Nasty. Especially if the modified getopt() could be useful to > other programs as well (do we have any programs with options that take > optional arguments?) Okay, fine, assume we'd just do the same thing to the system's getopt() instead of a special getopt(). So then...? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 10:42:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id 3F47D37B404 for ; Wed, 8 May 2002 10:42:02 -0700 (PDT) Received: (qmail 25183 invoked from network); 8 May 2002 17:42:01 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 May 2002 17:42:01 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g48HfxF34276; Wed, 8 May 2002 13:41:59 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 08 May 2002 13:41:52 -0400 (EDT) From: John Baldwin To: Dag-Erling Smorgrav Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Cc: "Brian F. Feldman" , "J. Mallett" , "David O'Brien" , Garance A Drosihn , arch@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 08-May-2002 Dag-Erling Smorgrav wrote: > John Baldwin writes: >> I think green was implying that sed would have its own getopt instead >> of changing the system getopt. > > Ugh. Nasty. Especially if the modified getopt() could be useful to > other programs as well (do we have any programs with options that take > optional arguments?) Most people consider optional arguments a bad thing, and apparently they are forbidden by some standards. I think the intent was to discourage other programs from using this "bad" practice by not changing the getopt in libc. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 11:32:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id ABC7B37B409; Wed, 8 May 2002 11:32:35 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g48IWTnG234048; Wed, 8 May 2002 14:32:29 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200205080304.g4834BL42647@green.bikeshed.org> References: <200205080304.g4834BL42647@green.bikeshed.org> Date: Wed, 8 May 2002 14:32:28 -0400 To: "Brian F. Feldman" , "J. Mallett" From: Garance A Drosihn Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Cc: arch@FreeBSD.ORG, Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 11:04 PM -0400 5/7/02, Brian F. Feldman wrote: >Trying to move this to arch: ...certainly a good idea. >Another option would be to extend getopt(3) in what could >simply be a very reasonable way. Here's my proposition >for making a "clean" version that acts like Perl: I must admit that I kind of like the idea of modifying getopt(3) so that it has the ability to process optional attached-arguments to a command flag. There are older programs which have such options, and it would be nice if those programs could use a common routine for all their processing. I expect that I shouldn't like that, as it means we've deviated getopt(3) from how it is defined in the standards, but I'll admit I like the idea. Your idea of using ';' for the flag (to getopt) that indicates an optional argument seems like a very good choice, too. On the other hand, when it comes to any brand new option for some command, then I (personally) think there is no need to have flags which take optional arguments. The recent standards committees are definitely not fond of optional arguments, and as a user (including a user of perl) I find them more of a hassle than they are worth. By "standards", I am referring to Utility Syntax Guidelines in Single Unix Spec v2, guideline 7, which says: "Option-arguments should not be optional". [which reminds me, I still haven't received the copy of SUS-v3 that I ordered...] This then suggests we need two command-flags, one which always takes an argument and one which never takes one. As to which-is-which, or what the implied argument is for the flag which never takes an argument, I like -i for the flag which never takes an argument, and having -i mean the same as '-I ""', but I'd be equally happy with any other combination just as long as we are not adding a command-flag that takes an optional argument. I think this -i/-I idea is good enough that many others would pick up on it when they see it, and it makes sense to define it in a way that doesn't conflict with what standards-groups have already said about options. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 13:11: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id 04B4C37B42F; Wed, 8 May 2002 13:05:11 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.3/8.12.2) with ESMTP id g48K4wev073088; Wed, 8 May 2002 13:04:58 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.3/Submit) id g48K4wPO073087; Wed, 8 May 2002 13:04:58 -0700 (PDT) Date: Wed, 8 May 2002 13:04:58 -0700 From: "David O'Brien" To: Garance A Drosihn Cc: "Brian F. Feldman" , "J. Mallett" , arch@FreeBSD.ORG, Garrett Wollman Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020508130458.B72921@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Garance A Drosihn , "Brian F. Feldman" , "J. Mallett" , arch@FreeBSD.ORG, Garrett Wollman References: <200205080304.g4834BL42647@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Wed, May 08, 2002 at 02:32:28PM -0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Bogus From: address, because people cannot be bothered to respect Reply-To:] On Wed, May 08, 2002 at 02:32:28PM -0400, Garance A Drosihn wrote: > This then suggests we need two command-flags, one which > always takes an argument and one which never takes one. > As to which-is-which, or what the implied argument is > for the flag which never takes an argument, I like -i > for the flag which never takes an argument, and having > -i mean the same as '-I ""', but I'd be equally happy > with any other combination just as long as we are not > adding a command-flag that takes an optional argument. Why do we need to waste two flags on this functionality? IF we are not going to accurately follow perl, then require "-i" to have an argument. The reason for allowing -i to not have an argument is because Perl does not require it. I have been shot down at having `sed' accurately reimplement this Perl functionality, so others can relax their optionless "-i" requirement. If ``sed -i"" foo'' works properly, people can just live with it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 13:18:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from finntroll.newgold.net (durham-ar1-4-64-252-019.durham.dsl-verizon.net [4.64.252.19]) by hub.freebsd.org (Postfix) with SMTP id CABC337B8A6 for ; Wed, 8 May 2002 13:12:23 -0700 (PDT) Received: (qmail 17217 invoked by uid 1001); 8 May 2002 20:15:48 -0000 Date: Wed, 8 May 2002 20:15:47 +0000 From: "J. Mallett" To: John Baldwin Cc: Dag-Erling Smorgrav , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, arch@FreeBSD.ORG, Garance A Drosihn , David O'Brien , "J. Mallett" , "Brian F. Feldman" Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020508201547.GA19530@FreeBSD.ORG> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organisation: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 08, 2002 at 11:47:39AM -0400, John Baldwin wrote: > > On 08-May-2002 Dag-Erling Smorgrav wrote: > > "Brian F. Feldman" writes: > >> Index: Makefile > >> =================================================================== > >> RCS file: /usr2/ncvs/src/usr.bin/sed/Makefile,v > >> retrieving revision 1.4 > >> diff -u -r1.4 Makefile > >> --- Makefile 8 Feb 2002 23:07:35 -0000 1.4 > >> +++ Makefile 8 May 2002 02:49:35 -0000 > >> @@ -3,6 +3,7 @@ > >> > >> PROG= sed > >> SRCS= compile.c main.c misc.c process.c > >> +SRCS+= getopt.c > >> > >> > >> .include > > > > What's this for? Leftovers from testing? > > I think green was implying that sed would have its own getopt instead > of changing the system getopt. Which, by the way, should be called 'egetopt' probably. -- jmallett@FreeBSD.org | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve "I've never tried to give my life meaning by demeaning you." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 13:19:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from finntroll.newgold.net (durham-ar1-4-64-252-019.durham.dsl-verizon.net [4.64.252.19]) by hub.freebsd.org (Postfix) with SMTP id C1E5537B8B9 for ; Wed, 8 May 2002 13:14:24 -0700 (PDT) Received: (qmail 13857 invoked by uid 1001); 8 May 2002 20:18:01 -0000 Date: Wed, 8 May 2002 20:18:01 +0000 From: "J. Mallett" To: "Brian F. Feldman" Cc: Dag-Erling Smorgrav , John Baldwin , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org, Garance A Drosihn , David O'Brien , "J. Mallett" Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020508201800.GB19530@FreeBSD.ORG> References: <200205081728.g48HSYf47716@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205081728.g48HSYf47716@green.bikeshed.org> User-Agent: Mutt/1.3.27i Organisation: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 08, 2002 at 01:28:34PM -0400, Brian F. Feldman wrote: > Dag-Erling Smorgrav wrote: > > John Baldwin writes: > > > I think green was implying that sed would have its own getopt instead > > > of changing the system getopt. > > > > Ugh. Nasty. Especially if the modified getopt() could be useful to > > other programs as well (do we have any programs with options that take > > optional arguments?) > > Okay, fine, assume we'd just do the same thing to the system's getopt() > instead of a special getopt(). So then...? Better to localise the dispicable behaviour to sed(1). Other programs provide their own egetopt(), for non-standard stuff. If sed(1) is supposed to be portable, it can't rely on such a change to the system getopt(3), and I'd be hesitant to say we should at all. But that's just a bikeshed opinion. Well, that and I had patches to getopt(3) when I proposed optional args to xargs(1) for GNU/compatability, and I was told outright by a few individuals "don't touch getopt(3), even if your change won't affect existing programs, it's non-portable as hell". Anyway. -- jmallett@FreeBSD.org | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve "I've never tried to give my life meaning by demeaning you." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 13:21:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from finntroll.newgold.net (durham-ar1-4-64-252-019.durham.dsl-verizon.net [4.64.252.19]) by hub.freebsd.org (Postfix) with SMTP id CCED537BA27 for ; Wed, 8 May 2002 13:17:33 -0700 (PDT) Received: (qmail 6670 invoked by uid 1001); 8 May 2002 20:21:32 -0000 Date: Wed, 8 May 2002 20:21:32 +0000 From: "J. Mallett" To: Garance A Drosihn Cc: "Brian F. Feldman" , "J. Mallett" , arch@FreeBSD.ORG, Garrett Wollman Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020508202131.GC19530@FreeBSD.ORG> References: <200205080304.g4834BL42647@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Organisation: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 08, 2002 at 02:32:28PM -0400, Garance A Drosihn wrote: > At 11:04 PM -0400 5/7/02, Brian F. Feldman wrote: > >Trying to move this to arch: > > ...certainly a good idea. > > >Another option would be to extend getopt(3) in what could > >simply be a very reasonable way. Here's my proposition > >for making a "clean" version that acts like Perl: > > I must admit that I kind of like the idea of modifying > getopt(3) so that it has the ability to process optional > attached-arguments to a command flag. There are older > programs which have such options, and it would be nice > if those programs could use a common routine for all > their processing. I expect that I shouldn't like that, as > it means we've deviated getopt(3) from how it is defined > in the standards, but I'll admit I like the idea. Your > idea of using ';' for the flag (to getopt) that indicates > an optional argument seems like a very good choice, too. I prefer "XX:", but that's a stylistic nit, I suppose. I would rather not introduce a new internal flag as such tho, as keep in mind you're saying "-; is not a valid option", which while in practice may be safe, may not be the best thing to say. XX: would not affect anything. > This then suggests we need two command-flags, one which > always takes an argument and one which never takes one. > As to which-is-which, or what the implied argument is > for the flag which never takes an argument, I like -i > for the flag which never takes an argument, and having > -i mean the same as '-I ""', but I'd be equally happy > with any other combination just as long as we are not > adding a command-flag that takes an optional argument. > > I think this -i/-I idea is good enough that many others > would pick up on it when they see it, and it makes > sense to define it in a way that doesn't conflict with > what standards-groups have already said about options. GNU implemented -i for xargs(1), in the way that I wanted to do compatability for. This option occurs in NEXTSTEP3.3 xargs(1), I do not know where it originates. SysV apparently has it... They also introduced '-I' which *required* an arg, and that was picked up by SUS/POSIX. I think if we don't do that we're being fools, and selling short our wonderful new capability for sed(1) [not that it matters, I just love being proud of work I've done]. -- jmallett@FreeBSD.org | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve "I've never tried to give my life meaning by demeaning you." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 13:22:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from finntroll.newgold.net (durham-ar1-4-64-252-019.durham.dsl-verizon.net [4.64.252.19]) by hub.freebsd.org (Postfix) with SMTP id E798E37BA61 for ; Wed, 8 May 2002 13:19:27 -0700 (PDT) Received: (qmail 18199 invoked by uid 1001); 8 May 2002 20:23:26 -0000 Date: Wed, 8 May 2002 20:23:26 +0000 From: "J. Mallett" To: David O'Brien , Garance A Drosihn , "Brian F. Feldman" , "J. Mallett" , arch@FreeBSD.ORG, Garrett Wollman Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020508202325.GD19530@FreeBSD.ORG> References: <200205080304.g4834BL42647@green.bikeshed.org> <20020508130458.B72921@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020508130458.B72921@dragon.nuxi.com> User-Agent: Mutt/1.3.27i Organisation: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, May 08, 2002 at 01:04:58PM -0700, David O'Brien wrote: > [Bogus From: address, because people cannot be bothered to respect > Reply-To:] > > On Wed, May 08, 2002 at 02:32:28PM -0400, Garance A Drosihn wrote: > > This then suggests we need two command-flags, one which > > always takes an argument and one which never takes one. > > As to which-is-which, or what the implied argument is > > for the flag which never takes an argument, I like -i > > for the flag which never takes an argument, and having > > -i mean the same as '-I ""', but I'd be equally happy > > with any other combination just as long as we are not > > adding a command-flag that takes an optional argument. > > Why do we need to waste two flags on this functionality? > IF we are not going to accurately follow perl, then require "-i" to have > an argument. The reason for allowing -i to not have an argument is > because Perl does not require it. I have been shot down at having `sed' > accurately reimplement this Perl functionality, so others can relax their > optionless "-i" requirement. If ``sed -i"" foo'' works properly, people > can just live with it. So standards can pick it up without feeling bad. I don't think it hurts, and certainly having a *portable* inline editing flag would be sexy. My twelfth (or so) contribution of two cents. -- jmallett@FreeBSD.org | C, MIPS, POSIX, UNIX, BSD, IRC Geek. http://www.FreeBSD.org | The Power to Serve "I've never tried to give my life meaning by demeaning you." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 13:25:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 196AB37BB16; Wed, 8 May 2002 13:23:57 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.3) with ESMTP id g48KNuEN086702; Wed, 8 May 2002 16:23:56 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.3/Submit) id g48KNu47086699; Wed, 8 May 2002 16:23:56 -0400 (EDT) Date: Wed, 8 May 2002 16:23:56 -0400 (EDT) From: Garrett Wollman Message-Id: <200205082023.g48KNu47086699@khavrinen.lcs.mit.edu> To: "J. Mallett" Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 In-Reply-To: <20020508201547.GA19530@FreeBSD.ORG> References: <20020508201547.GA19530@FreeBSD.ORG> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Ridiculously long CC list trimmed.] < said: > Which, by the way, should be called 'egetopt' probably. POSIX allows implementations to extend getopt(), subject to the restriction that such extensions must reserve characters in the Portable Filename Character Set (except 'W') for application use. - -GAWollman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE82YlYPs90GwuS+uoRAuOrAJ4miZo0AQI6bEuuTrQohyTZ+LQQbACdEokC oju1s78jJ2m348dxzlieuEI= =cYu5 -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 14:11:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 5D39137B6FA; Wed, 8 May 2002 14:08:25 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g48L8KnG138328; Wed, 8 May 2002 17:08:20 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020508130458.B72921@dragon.nuxi.com> References: <200205080304.g4834BL42647@green.bikeshed.org> <20020508130458.B72921@dragon.nuxi.com> Date: Wed, 8 May 2002 17:08:19 -0400 To: "David O'Brien" From: Garance A Drosihn Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Cc: "Brian F. Feldman" , "J. Mallett" , arch@FreeBSD.ORG, Garrett Wollman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:04 PM -0700 5/8/02, David O'Brien wrote: >[Bogus From: address, because people cannot be bothered to respect >Reply-To:] > >On Wed, May 08, 2002, Garance A Drosihn wrote: > > This then suggests we need two command-flags, one which > > always takes an argument and one which never takes one. > >Why do we need to waste two flags on this functionality? >IF we are not going to accurately follow perl, then require >"-i" to have an argument. Oh. Yes, that would be fine with me too. I thought someone had argued that '-i' must not have an argument. That was OK with me, but I'm equally happy to have just the one flag instead of two. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed May 8 16:12:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 1D2E437B401; Wed, 8 May 2002 16:12:43 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g48NCfnG473974; Wed, 8 May 2002 19:12:41 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020508202131.GC19530@FreeBSD.ORG> References: <200205080304.g4834BL42647@green.bikeshed.org> <20020508202131.GC19530@FreeBSD.ORG> Date: Wed, 8 May 2002 19:12:40 -0400 To: "J. Mallett" From: Garance A Drosihn Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Cc: arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:21 PM +0000 5/8/02, J. Mallett wrote: >Keep in mind you're saying "-; is not a valid option", >which while in practice may be safe, may not be the best >thing to say. But consider, for instance: /bin/echo test -? somestring vs: /bin/echo test -; somestring if you don't quote the '-;', then the shell will use it as a command-separator before the command ever sees it. This seems to be true with sh, csh, and bash on my freebsd-current system. This makes '-;' a very awkward flag for a command to use. Seems like a nice extension to getopt(3). -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 5:54:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id B2C8837B40C for ; Thu, 9 May 2002 05:54:12 -0700 (PDT) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g49CreHA026701 for ; Thu, 9 May 2002 14:53:40 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@FreeBSD.ORG Subject: New ABI (32->64) [take two]... Date: Thu, 09 May 2002 14:53:40 +0200 Message-ID: <26700.1020948820@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG So, Status: 1. Yes, 32->64 brings sufficient havoc that a new ABI is a good idea. 2. Yes, we have at least one way to mark the ELF binaries as using the new ABI. 3. TBD: name/numbering of new ABI. 4. Yes, kernel side should be split into $ABI_$syscall() which does the copyins and type conversions and sc_$syscall() which operates entirely in kernel native data types. 5. TBD: Split header files in src/sys/sys into src/sys/include and src/sys/$ABI. src/$arch/include into src/$arch/include and src/$arch/$ABI to separate userland/syscall arguments from kernel native arguments. 6. TBD: Review and approval process for new syscall definition. 7. TBD: Decision process if/when -current/5.0 switches to new API (TBD: To Be Determined == still outstanding) Is this correctly interpreted ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 6:15:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DD5D937B41E; Thu, 9 May 2002 06:15:06 -0700 (PDT) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g49DF6W70696; Thu, 9 May 2002 09:15:06 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200205091315.g49DF6W70696@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn Cc: "J. Mallett" , arch@FreeBSD.ORG Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 In-Reply-To: Your message of "Wed, 08 May 2002 19:12:40 EDT." From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 May 2002 09:15:06 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > At 8:21 PM +0000 5/8/02, J. Mallett wrote: > >Keep in mind you're saying "-; is not a valid option", > >which while in practice may be safe, may not be the best > >thing to say. > > But consider, for instance: > > /bin/echo test -? somestring > vs: /bin/echo test -; somestring > > if you don't quote the '-;', then the shell will use it > as a command-separator before the command ever sees it. > This seems to be true with sh, csh, and bash on my > freebsd-current system. This makes '-;' a very awkward > flag for a command to use. Seems like a nice extension > to getopt(3). It really does seem, though, that lots of applications reimplement getopt(3) (incorrectly) in order to have one or two "frivolous" features. Applications which take -o[optarg] and -o [several] [args] seem to be none-too-uncommon. I'd want to try to support them just so that they all don't reinvent getopt(3) badly, but then again there's the problem that other operating systems would have to adopt the extended getopt syntax, too. Lots of applications just use getopt_long(3) instead, which I suppose can easily allow for this functionality with GNU arguments just by virtue that they cannot be concatenated anyway. My temptation is not to provide the functionality in the system's libraries because that would tend to make developers actually use it, and in doing so become unportable to those OSes having a different getopt(3) in addition to going against the grain of what POSIX wants. I don't think there's a clean way of doing it without a modified getopt, so I'd say that either sed should have its own getopt with that change locally or it would just fail to support the Perl syntax. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 6:22:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 5922137B41B for ; Thu, 9 May 2002 06:22:42 -0700 (PDT) Received: (qmail 26020 invoked from network); 9 May 2002 13:22:41 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 May 2002 13:22:41 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g49DMeF37874; Thu, 9 May 2002 09:22:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <26700.1020948820@critter.freebsd.dk> Date: Thu, 09 May 2002 09:22:33 -0400 (EDT) From: John Baldwin To: Poul-Henning Kamp Subject: RE: New ABI (32->64) [take two]... Cc: arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 09-May-2002 Poul-Henning Kamp wrote: > > So, Status: > > 1. Yes, 32->64 brings sufficient havoc that a new ABI is a good idea. > > 2. Yes, we have at least one way to mark the ELF binaries as using > the new ABI. > > 3. TBD: name/numbering of new ABI. > > 4. Yes, kernel side should be split into $ABI_$syscall() which does > the copyins and type conversions and sc_$syscall() which operates > entirely in kernel native data types. I would just leave the latter as $syscall() but that's not a big deal. > 5. TBD: Split header files in > src/sys/sys into src/sys/include and src/sys/$ABI. > src/$arch/include into src/$arch/include and src/$arch/$ABI > to separate userland/syscall arguments from kernel native arguments. > > 6. TBD: Review and approval process for new syscall definition. > > 7. TBD: Decision process if/when -current/5.0 switches to new API > > (TBD: To Be Determined == still outstanding) > > Is this correctly interpreted ? Yes. 5 is ugly but I don't have any better ideas. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 6:54:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 0C51B37B40B for ; Thu, 9 May 2002 06:54:50 -0700 (PDT) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 175oNe-000Pra-00 for arch@FreeBSD.org; Thu, 09 May 2002 15:54:50 +0200 From: Sheldon Hearn To: arch@FreeBSD.org Subject: whither whereis? Date: Thu, 09 May 2002 15:54:50 +0200 Message-ID: <99421.1020952490@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, As per the "Perl scripts that need rewiting" thread on -current, Perl is going to be removed from the base src [1]. The various perl scripts in the base system must be removed or replaced. I offered to tackle whereis. It seems stupid to rewrite it from scratch, so I took at look at our fellow BSD distributions: 1) NetBSD has a standalone whereis utility written in C. 2) OpenBSD has a which utility written in C. This utility behaves like whereis when called as such. Neither of these implementations support all the fanciness that Joerg threw in for free when he wrote our whereis Perl script. My feeling is that we should adopt NetBSD or OpenBSD's implementation. This would lose us some of the existing whereis functionality we have. I don't think this is a real problem because: 1) whereis(1) isn't covered by POSIX/SUSv3. 2) The extra fanciness can mostly be accomplished with shell scripting. 3) I've never seen the extra fanciness used in shell scripts in the wild. So, can anyone think of any good reason to go in favour of one over the other of the NetBSD and OpenBSD implementations? I'm leaning toward OpenBSD's, because which(1) and whereis(1) share common functionality, and so I think it makes sense that they be implemented in the same source module. Ciao, Sheldon. [1] Saying that Perl will be removed from the base _system_ has confused a lot of people; FreeBSD installs will still include Perl by default, but it'll come from a package (unless the default is overridden), not the bin dist. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 18: 5:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from web11107.mail.yahoo.com (web11107.mail.yahoo.com [216.136.131.154]) by hub.freebsd.org (Postfix) with SMTP id B6D5437B407 for ; Thu, 9 May 2002 18:05:40 -0700 (PDT) Message-ID: <20020510010540.77293.qmail@web11107.mail.yahoo.com> Received: from [200.210.78.2] by web11107.mail.yahoo.com via HTTP; Thu, 09 May 2002 22:05:40 ART Date: Thu, 9 May 2002 22:05:40 -0300 (ART) From: "=?iso-8859-1?q?Rodrigo=20F.=20Baroni?=" Reply-To: rodrigobaroni@yahoo.com.br Subject: FreeBSD design and concepts To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello all I´m a computer science student, and I´m doing a project about FreeBSD, could someone tell me where I can find docs about design, concepts and implementation about FreeBSD ?! Thanks so very Rodrigo F. BAroni Brazil _______________________________________________________________________ Yahoo! Encontros O lugar certo para você encontrar aquela pessoa que falta na sua vida. Cadastre-se hoje mesmo! http://br.encontros.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 21:59: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nuit.iteration.net (nuit.iteration.net [198.92.249.80]) by hub.freebsd.org (Postfix) with ESMTP id 4D2B737B401; Thu, 9 May 2002 21:58:59 -0700 (PDT) Received: by nuit.iteration.net (Postfix, from userid 1001) id 8250011B571; Thu, 9 May 2002 21:57:01 -0700 (PDT) Date: Thu, 9 May 2002 21:57:01 -0700 From: "Michael C. Wu" To: arch@FreeBSD.ORG Cc: Matthew Dillon , obrien@freebsd.org Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020510045701.GA34750@nuit.iteration.net> Reply-To: "Michael C. Wu" References: <200205071940.g47Jehl84130@apollo.backplane.com> <20020507131314.B29014@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020507131314.B29014@dragon.nuxi.com> User-Agent: Mutt/1.3.28i X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, May 07, 2002 at 01:13:14PM -0700, David O'Brien scribbled: | On Tue, May 07, 2002 at 12:40:43PM -0700, Matthew Dillon wrote: | > the way for us to allow natively compiled multi-architectural support. | > e.g. consider this: | > cc -ABI4 ... | > cc -ABI5 ... | > cc -ABILinux ... | > cc -ABIOpenBSD ... | Honestly, why do we have this need? It seems to fall into the "it would | be nice"; but seldomly used. Vendor imported code (e.g. KAME(sigh..), USB, possibly 1394, cardbus, possibly some userland important tools and libraries) would have little or no diffs from the original vendor's code.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 22:13:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id 59E0C37B407 for ; Thu, 9 May 2002 22:13:56 -0700 (PDT) Received: (qmail 28067 invoked from network); 10 May 2002 05:13:55 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 May 2002 05:13:55 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4A5DsF40911; Fri, 10 May 2002 01:13:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020510045701.GA34750@nuit.iteration.net> Date: Fri, 10 May 2002 01:13:52 -0400 (EDT) From: John Baldwin To: "Michael C. Wu" Subject: Re: syscall changes to deal with 32->64 changes. Cc: obrien@freebsd.org, Matthew Dillon , arch@FreeBSD.ORG Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-May-2002 Michael C. Wu wrote: > On Tue, May 07, 2002 at 01:13:14PM -0700, David O'Brien scribbled: >| On Tue, May 07, 2002 at 12:40:43PM -0700, Matthew Dillon wrote: >| > the way for us to allow natively compiled multi-architectural support. >| > e.g. consider this: >| > cc -ABI4 ... >| > cc -ABI5 ... >| > cc -ABILinux ... >| > cc -ABIOpenBSD ... >| Honestly, why do we have this need? It seems to fall into the "it would >| be nice"; but seldomly used. > > Vendor imported code (e.g. KAME(sigh..), USB, possibly 1394, > cardbus, possibly some userland important tools and libraries) > would have little or no diffs from the original vendor's code.. Erm, all the changes so far aren't in API's, but rather changing the size of types like time_t. The same KAME code would compile fine. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 23:46:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailsrv.otenet.gr (mailsrv.otenet.gr [195.170.0.5]) by hub.freebsd.org (Postfix) with ESMTP id 3099737B400 for ; Thu, 9 May 2002 23:46:43 -0700 (PDT) Received: from hades.hell.gr (patr530-a042.otenet.gr [212.205.215.42]) by mailsrv.otenet.gr (8.12.3/8.12.3) with ESMTP id g4A6kTj7015971; Fri, 10 May 2002 09:46:41 +0300 (EEST) Received: from hades.hell.gr (hades [127.0.0.1]) by hades.hell.gr (8.12.3/8.12.3) with ESMTP id g4A6jkV6008812; Fri, 10 May 2002 09:46:28 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from charon@localhost) by hades.hell.gr (8.12.3/8.12.2/Submit) id g4A4IiOq001707; Fri, 10 May 2002 07:18:44 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 10 May 2002 07:18:43 +0300 From: Giorgos Keramidas To: Mark Murray Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/sed main.c sed.1 Message-ID: <20020510041843.GA1327@hades.hell.gr> References: <200205081603.g48G3KjV084431@grimreaper.grondar.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205081603.g48G3KjV084431@grimreaper.grondar.org> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 2002-05-08 17:03, Mark Murray wrote: > > At the risk of detracting from the matter at hand, this would be a > useful extension to getopt(3), as would the ability to have numeric-only > options (a' la "tail -123"), that is not just single digits, but whole > numbers. Optional arguments sounds nice. I don't care about the numeric ones, since I like '-n 123' a lot better. - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu May 9 23:56:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DA02737B40C; Thu, 9 May 2002 23:56:35 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g4A6uZhU031060; Thu, 9 May 2002 23:56:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g4A6uZgF031059; Thu, 9 May 2002 23:56:35 -0700 (PDT) Date: Thu, 9 May 2002 23:56:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200205100656.g4A6uZgF031059@apollo.backplane.com> To: John Baldwin Cc: "Michael C. Wu" , obrien@FreeBSD.org, arch@FreeBSD.org Subject: Re: syscall changes to deal with 32->64 changes. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> :> Vendor imported code (e.g. KAME(sigh..), USB, possibly 1394, :> cardbus, possibly some userland important tools and libraries) :> would have little or no diffs from the original vendor's code.. : :Erm, all the changes so far aren't in API's, but rather changing the size :of types like time_t. The same KAME code would compile fine. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ Huh? Changing the size of time_t sure sounds like an API change to me! . Which was my original point... though I was considering those ports which might not be 64-bit-time_t friendly (probably hundreds). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 10 0:44:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from softweyr.com (softweyr.com [65.88.244.127]) by hub.freebsd.org (Postfix) with ESMTP id 5B42737B400 for ; Fri, 10 May 2002 00:44:34 -0700 (PDT) Received: from 66-75-153-50.san.rr.com ([66.75.153.50] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.35 #1) id 17654h-0004RA-00; Fri, 10 May 2002 01:44:24 -0600 Message-ID: <3CDB6CCB.B8AD30DA@softweyr.com> Date: Fri, 10 May 2002 00:46:35 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: rodrigobaroni@yahoo.com.br Cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD design and concepts References: <20020510010540.77293.qmail@web11107.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Rodrigo F. Baroni" wrote: > > Hello all > > I´m a computer science student, and I´m doing a > project about FreeBSD, could someone tell me where I > can find docs about design, concepts and > implementation about FreeBSD ?! In the source code. I know this sounds trite, but it is the best resource for learning what the system is and what it does. For a more historical perspective, the CVS logs are an excellent tool as well. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 10 1:10:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id B723537B400; Fri, 10 May 2002 01:10:22 -0700 (PDT) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g4A8A1J89007; Fri, 10 May 2002 01:10:01 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3) with ESMTP id g4A8A5e6004739; Fri, 10 May 2002 01:10:05 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g4A8A4Wq004738; Fri, 10 May 2002 01:10:04 -0700 (PDT) Date: Fri, 10 May 2002 01:10:04 -0700 From: Marcel Moolenaar To: Matthew Dillon Cc: John Baldwin , "Michael C. Wu" , obrien@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: syscall changes to deal with 32->64 changes. Message-ID: <20020510081004.GA4266@dhcp01.pn.xcllnt.net> References: <200205100656.g4A6uZgF031059@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200205100656.g4A6uZgF031059@apollo.backplane.com> User-Agent: Mutt/1.3.99i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, May 09, 2002 at 11:56:35PM -0700, Matthew Dillon wrote: > > :> Vendor imported code (e.g. KAME(sigh..), USB, possibly 1394, > :> cardbus, possibly some userland important tools and libraries) > :> would have little or no diffs from the original vendor's code.. > : > :Erm, all the changes so far aren't in API's, but rather changing the size > :of types like time_t. The same KAME code would compile fine. > : > > Huh? Changing the size of time_t sure sounds like an API change to me! There's no programmer visual change if you change the size of a type. Only when you go down to the binary level, you'll notice things have changed. I think this means that changing the definition of an abstract type (which time_t is) is not an API change. Put differently: you don't have to recode, just recompile (provided you didn't make assumptions about the size of course :-) I'm not 100% sure, but it's how I intuitively interpret API... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 10 5: 5:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by hub.freebsd.org (Postfix) with ESMTP id CBB4837B408 for ; Fri, 10 May 2002 05:05:12 -0700 (PDT) Received: (qmail 25297 invoked from network); 10 May 2002 12:05:11 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 May 2002 12:05:11 -0000 Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4AC5AF42136; Fri, 10 May 2002 08:05:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200205100656.g4A6uZgF031059@apollo.backplane.com> Date: Fri, 10 May 2002 08:05:08 -0400 (EDT) From: John Baldwin To: Matthew Dillon Subject: Re: syscall changes to deal with 32->64 changes. Cc: arch@FreeBSD.org, obrien@FreeBSD.org, "Michael C. Wu" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-May-2002 Matthew Dillon wrote: > >:> >:> Vendor imported code (e.g. KAME(sigh..), USB, possibly 1394, >:> cardbus, possibly some userland important tools and libraries) >:> would have little or no diffs from the original vendor's code.. >: >:Erm, all the changes so far aren't in API's, but rather changing the size >:of types like time_t. The same KAME code would compile fine. >: >:-- >: >:John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > Huh? Changing the size of time_t sure sounds like an API change to me! > . Which was my original point... though I was considering those > ports which might not be 64-bit-time_t friendly (probably hundreds). It's not one that other source needs to be changed for though. It's not like you've changed the prototypes of functions. Instead, you've changed the binary representation of certain types. We don't need to use the old ABI's for vendor code like Michael suggested because vendor code will compile just fine with the newer one. > -Matt > Matthew Dillon > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 10 5:50:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id C300337B405 for ; Fri, 10 May 2002 05:50:00 -0700 (PDT) Received: (qmail 5792 invoked from network); 10 May 2002 12:50:02 -0000 Received: from ken.yumyumyum.org (192.168.0.2) by router.yumyumyum.org with SMTP; 10 May 2002 12:50:02 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Kenneth Culver To: rodrigobaroni@yahoo.com.br Subject: Re: FreeBSD design and concepts Date: Fri, 10 May 2002 08:50:22 -0400 X-Mailer: KMail [version 1.4] References: <20020510010540.77293.qmail@web11107.mail.yahoo.com> In-Reply-To: <20020510010540.77293.qmail@web11107.mail.yahoo.com> Cc: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200205100850.22791.culverk@yumyumyum.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The FreeBSD webpage would be a good start: http://www.freebsd.org Also, try looking at the source code, that's also a good place to see the= =20 design of FreeBSD. Ken On Thursday 09 May 2002 09:05 pm, Rodrigo F. Baroni wrote: > Hello all > > > > I=B4m a computer science student, and I=B4m doing a > project about FreeBSD, could someone tell me where I > can find docs about design, concepts and > implementation about FreeBSD ?! > > > Thanks so very > > > Rodrigo F. BAroni > Brazil > > > > _______________________________________________________________________ > Yahoo! Encontros > O lugar certo para voc=EA encontrar aquela pessoa que falta na sua vida= =2E > Cadastre-se hoje mesmo! http://br.encontros.yahoo.com/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 10 10:35:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B34B37B401; Fri, 10 May 2002 10:35:52 -0700 (PDT) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.3/8.9.1) with ESMTP id g4AHZqhU033405; Fri, 10 May 2002 10:35:52 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.3/8.12.3/Submit) id g4AHZpIG033404; Fri, 10 May 2002 10:35:51 -0700 (PDT) Date: Fri, 10 May 2002 10:35:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200205101735.g4AHZpIG033404@apollo.backplane.com> To: John Baldwin Cc: arch@FreeBSD.org, obrien@FreeBSD.org, "Michael C. Wu" Subject: Re: syscall changes to deal with 32->64 changes. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :It's not one that other source needs to be changed for though. It's not like :you've changed the prototypes of functions. Instead, you've changed the binary :representation of certain types. We don't need to use the old ABI's for vendor :code like Michael suggested because vendor code will compile just fine with the :newer one. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ John, I've got to disagree. You are using an extremely narrow definition of what an API change is by making the assumption that most code will just recompile without problems. I can tell you from experience that this simply is not true... especially for something like time_t. You didn't have to live through the off_t change that occured when 64 bit cpu's started hitting the mainstream UNIX world. It was *NASTY*. time_t is going to be almost as nasty. Even many of our current utilities, for example those that embed time_t in data streams or data files, will either break or become incompatible with their brethren. This isn't a matter of brute-forcing the change. There is just too much stuff out there to brute-force. All I am suggesting is that we take the capabilities that we already have to add to the compiler and extend them out to userland as an option. It helps us, and it helps ports. I'm not an expert on GCC but I could probably do the work if nobody else wants to. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri May 10 14:40:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id DF99637B404; Fri, 10 May 2002 14:40:11 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g4ALe85J146210; Fri, 10 May 2002 17:40:08 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200205101735.g4AHZpIG033404@apollo.backplane.com> References: <200205101735.g4AHZpIG033404@apollo.backplane.com> Date: Fri, 10 May 2002 17:40:07 -0400 To: Matthew Dillon , John Baldwin From: Garance A Drosihn Subject: Re: syscall changes to deal with 32->64 changes. Cc: arch@FreeBSD.ORG, obrien@FreeBSD.ORG, "Michael C. Wu" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:35 AM -0700 5/10/02, Matthew Dillon wrote: >John Baldwin wrote: >: >: It's not one that other source needs to be changed for though. >: It's not like you've changed the prototypes of functions. >: Instead, you've changed the binary representation of certain >: types. We don't need to use the old ABI's for vendor code >: like Michael suggested because vendor code will compile just >: fine with the newer one. > > [...] the off_t change that occured when 64 bit cpu's > started hitting the mainstream UNIX world. It was *NASTY*. > > time_t is going to be almost as nasty. Even many of our > current utilities, for example those that embed time_t in > data streams or data files, will either break or become > incompatible with their brethren. > > This isn't a matter of brute-forcing the change. There is > just too much stuff out there to brute-force. All I am > suggesting is that we take the capabilities that we already > have to add to the compiler and extend them out to userland > as an option. It helps us, and it helps ports. The more I think about this, the more I think Matt's suggestion is a prudent one. There is still plenty of code which thinks that size_t is 'int', or uses size_t when it really should be using offset_t. The code "works" mainly because we rarely have really large files. Who knows how much code we have, both in the base system and in all the ports, which makes invalid assumptions about time_t, or of some of the other types that might be changed with this new syscall vector. > I'm not an expert on GCC but I could probably do the work > if nobody else wants to. Of course, the sticky question is that we're also in the middle of a major change in the gcc world, so I don't know how disruptive it would be to try and do these changes in about the same timeframe. And certainly the latest and greatest gcc is critical to a good 5.0-release. Still, if we were going to "do it right", I think it does make more sense to allow the ABI's to co-exist, instead of trying to make a hard cutover. If someone does have a problem with a port, it would be nice to just recompile with "the old API" and see that effects the problem. Perhaps we could volunteer Matt to at least look into the idea a bit more, without making any actual changes yet, just to see how hard it would be to do this. That work should be unrelated to the actual syscall change, so looking into this should not slow down that project. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat May 11 9:21:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from web21307.mail.yahoo.com (web21307.mail.yahoo.com [216.136.128.232]) by hub.freebsd.org (Postfix) with SMTP id DDA3337B400 for ; Sat, 11 May 2002 09:21:49 -0700 (PDT) Message-ID: <20020511162149.75783.qmail@web21307.mail.yahoo.com> Received: from [193.251.159.163] by web21307.mail.yahoo.com via HTTP; Sat, 11 May 2002 09:21:49 PDT Date: Sat, 11 May 2002 09:21:49 -0700 (PDT) From: kone ibrahim Subject: URGENT ASSISTANCE/INVESTMENT To: arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG FROM : MR.ISMIL IBRAHIM ABIDJAN.IVORY COAST WEST-AFRICA DEAR SIR PERMIT ME TO INFORM YOU OF MY DESIRE OF ENTERING INTO BUSINESS RELATIONSHIP WITH YOU. I GOT YOUR EMAIL THROUGH A FRIEND WHO WORKS IN THE HUMAN RIGHTS COMMISSION HERE IN ABIDJAN COTE D IVOIRE I PRAYED OVER IT AND SELECTED YOUR NAME AMOUNG OTHER NAMES DUE TO IT’S ESTEEMING NATURE AND THE RECOMMENDATIONS GIVEN TO ME AS A REPUTABLE AND TRUSTWORTHY PERSON I CAN DO BUSINESS WITH AND BY THEIR RECOMMENDATIONS I MUST NOT HESITATE TO CONFIDE IN YOU FOR THIS SIMPLE AND SINCERE BUSINESS. I MR.ISMIL IBRAHIM, THE ONLY CHILD OF LATE MR AND MRS. IBRAHIM. MY FATER WAS A VERY WEALTHY COCOA MERCHANT BASED IN ABIDJAN. THE ECONOMIC CAPITAL OF IVORY COAST BEFORE HE WAS POISONED TO DEATH BY HIS BUSINESS ASSOCIATES ON ONE OF THEIR OUTING TO DISCUSS ON A BUSINESS DEAL. WHEN MY MOTHER DIED ON THE 21ST OCTOBER 1995. MY FATHER TOOK ME SO SPECIAL BECAUSE I AM MOTHERLESS. BEFORE THE DEATH OF MY FATHER ON 29TH AUGUST 2000 IN A PRIVATE HOSPITAL HERE IN ABIDJAN. HE SECRETLY CALLED ME ON HIS BEDSIDE AND TOLD ME THAT HE HAS A SUM OF US$22.500.000 (TWENTY TWO MILLION FIVE HUNDRED THOUSAND, UNITED STATES DOLLARS) LEFT IN A LOCAL BANK HERE IN ABIDJAN. THAT HE USED MY NAME AS HIS ONLY SON FOR THE NEXT OF KIN IN DEPOSIT OF THE FUND. HE ALSO EXPLAINED TO ME THAT IT WAS BECAUSE OF THIS WEALTH THAT HE WAS POISONED BY HIS BUSINESS ASSOCIATES, THAT I SHOULD SEEK FOR A FOREIGN PARTNER IN A COUNTRY OF MY CHOICE WHERE I WILL TRANSFER THIS MONEY AND USE IT FOR INVESTMENT PURPOSE. (SUCH AS REAL ESTATE MANAGEMENT). SIR, I AM HONOURABLY SEEKING YOUR ASSISTANCE IN THE FOLLOWING WAYS : TO PROVIDE A BANK ACCOUNT WHERE THIS MONEY WOULD BE TRANSFERED TO TO SERVE AS THE GUARDIAN OF THIS FUND SINCE I AM A BOY OF 26 YEARS TO MAKE ARRANGEMENT FOR ME TO COME OVER TO YOUR COUNTRY TO FURTHER MY EDUCATION AND TO SECURE A RESIDENTIAL PERMIT IN YOUR COUNTRY. MOREOVER, SIR, I AM WILLING TO OFFER YOU 20% OF THE TOTAL SUM AS COMPENSATION FOR YOUR EFFORT INPUT AFTER THE SUCCESSFUL TRANSFER OF THIS FUND TO YOUR NOMINATED ACCOUNT OVERSEAS. FURTHERMORE, YOU CAN INDICATE YOUR OPTION TOWARDS ASSISTING ME AS I BELIEVE THAT THIS TRANSACTION WOULD BE CONCLUDED WITHIN SEVEN (7) DAYS YOU SIGNIFY INTEREST TO ASSIST ME. I WILL APPRECIATE YOU SEND ME E-MAIL. ANTICIPATING TO HEAR FROM YOU SOON. THANKS AND GOD BLESS. MR.ISMIL IBRAHIM __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message