From owner-freebsd-arch Sun Jan 20 1:40: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 970AB37B400 for ; Sun, 20 Jan 2002 01:40:06 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020120094006.DEDB26243.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 20 Jan 2002 09:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA05299; Sun, 20 Jan 2002 01:26:45 -0800 (PST) Date: Sun, 20 Jan 2002 01:26:44 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: doreti() and userret() In-Reply-To: <20020120182437.R7452-100000@gamplex.bde.org> 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 Sun, 20 Jan 2002, Bruce Evans wrote: > On Sat, 19 Jan 2002, Julian Elischer wrote: > > See sys.dif.gz in ~bde on freefall. A lot of cosmetic changes there amongst the real changes.. I notice that you are reversing people's work of gradually getting rid of K&R function declarations. This is opposite to what we are doing as a group. (converting functions to ansi declarations as we hit them). Lots of good stuff though.. ANy chance you can extract a set of cosmetic patches for commit out of that? I am tempted to do so just to reduce the size of your diff :-) > > For optimizing userret(), the idea is to set flags for ast() to check. > E.g., there is a flag for signals so that usrret() doesn't need the > CURSIG() loop. CURSIG() is much more expensive than it used to be, > since it has to check 128 signals instead of 32 and aquire and release > 2 locksE.g., there is a flag for signals so that usrret() doesn't need the > CURSIG() loop. CURSIG() is much more expensive than it used to be, > since it has to check 128 signals instead of 32 and aquire and release > 2 locks instead of none. Ok that makes sense.. I may do similar int eh KSE kernel anyhow. > > > On Sun, 20 Jan 2002, Bruce Evans wrote: > > > > > On Sat, 19 Jan 2002, Alfred Perlstein wrote: > > > > > > > * Julian Elischer [020119 10:01] wrote: > > > > > > > > > > On Sun, 20 Jan 2002, Bruce Evans wrote: > > Please don't top post (top mail?). what does that mean? I shouldn't add to the top of the old email? > > Bruce > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 2: 0:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 9745437B400 for ; Sun, 20 Jan 2002 02:00:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020120100010.ZTKY3578.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sun, 20 Jan 2002 10:00:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA05358; Sun, 20 Jan 2002 01:51:39 -0800 (PST) Date: Sun, 20 Jan 2002 01:51:37 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: doreti() and userret() 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 replying to self: On Sun, 20 Jan 2002, Julian Elischer wrote: > > > On Sun, 20 Jan 2002, Bruce Evans wrote: > > > On Sat, 19 Jan 2002, Julian Elischer wrote: > > > > See sys.dif.gz in ~bde on freefall. > > A lot of cosmetic changes there amongst the real changes.. > I notice that you are reversing people's work of gradually > getting rid of K&R function declarations. This is opposite to what we > are doing as a group. (converting functions to ansi declarations > as we hit them). > Not to mention adding __P() when everyone else is stripping them out as we come across them. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 2:20: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 4B74437B402 for ; Sun, 20 Jan 2002 02:20:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020120102006.DNHW26243.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sun, 20 Jan 2002 10:20:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id CAA05415; Sun, 20 Jan 2002 02:01:17 -0800 (PST) Date: Sun, 20 Jan 2002 02:01:16 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: doreti() and userret() 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 replying to mself again: On Sun, 20 Jan 2002, Julian Elischer wrote: > > > On Sun, 20 Jan 2002, Bruce Evans wrote: > > > On Sat, 19 Jan 2002, Julian Elischer wrote: > > > > See sys.dif.gz in ~bde on freefall. > > A lot of cosmetic changes there amongst the real changes.. > I notice that you are reversing people's work of gradually > getting rid of K&R function declarations. This is opposite to what we > are doing as a group. (converting functions to ansi declarations > as we hit them). And I see this change, which is also reverse of where we are going: - u_int32_t en_mxcsr; /* SSE sontorol/status register */ - u_int32_t en_pad2; /* padding */ + u_int en_mxcsr; /* SSE sontorol/status register */ + u_int en_pad2; /* padding */ I thought that for hardware defined fields we were using the explicit size definitions wherever possible? (saves having to try remember which machine you are working on... and now that there are posix defined names for these... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 10:18:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from camelot.spsl.nsc.ru (camelot.spsl.nsc.ru [194.226.174.80]) by hub.freebsd.org (Postfix) with ESMTP id 2425D37B405 for ; Sun, 20 Jan 2002 10:18:15 -0800 (PST) Received: (from root@localhost) by camelot.spsl.nsc.ru (8.11.6/8.11.6) id g0KIHvv21444 for arch@freebsd.org.AVP; Mon, 21 Jan 2002 00:17:57 +0600 (NOVT) (envelope-from fjoe@iclub.nsu.ru) Received: from iclub.nsu.ru (root@iclub.nsu.ru [193.124.222.66]) by camelot.spsl.nsc.ru (8.11.6/8.11.6) with ESMTP id g0KIHrX21436; Mon, 21 Jan 2002 00:17:53 +0600 (NOVT) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.11.6/8.11.6) id g0KIHnW80990; Mon, 21 Jan 2002 00:17:49 +0600 (NS) (envelope-from fjoe) Date: Mon, 21 Jan 2002 00:17:49 +0600 From: Max Khon To: Bruce Evans Cc: Cy Schubert - ITSD Open Systems Group , Poul-Henning Kamp , arch@freebsd.org Subject: Re: request for review Message-ID: <20020121001749.A80939@iclub.nsu.ru> References: <20020116000607.B10938@iclub.nsu.ru> <20020116155828.T487-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020116155828.T487-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, Jan 16, 2002 at 04:18:12PM +1100 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, there! On Wed, Jan 16, 2002 at 04:18:12PM +1100, Bruce Evans wrote: > > > This patch also makes FreeBSD almost compatible with FreeBSD (versions > > > 1, 2, 3) that is. Old versions vn_stat() simply passed back the > > > va_blocksize set by VOP_GETTATTR(). > > > > NetBSD/OpenBSD do exactly the same > > The main point of the differences in FreeBSD is to set st_blksize to > a reasonable value for disks (since individual filesystems didn't do > it). The changes really shouldn't have affected non-disks. > > > > > > I think it is bogus for devices other than disks to flout a > > > > > va_blocksize, but I am on the other hand not sure what the > > > > > relevant (if any) standards say. > > > > > > POSIX says almost the same as the quote from www.opengroup.org in the > > > sources: "A file system-specific [sic] preferred I/O block size for > > > this object". 0 is wrong except possibly for /dev/null since it is > > > a very bad I/O size. > > > > do you think we should remove setting sb->st_blksize to 0 in vn_stat() at all? > > Yes. We should also fix any filesystems that set va_blocksize to 0, or > convert a va_blocksize of 0 to a more sensible st_blksize. I just noticed > the following comment in vn_stat(): > > * Default to zero to catch bogus uses of this field. > > This causes many bogus block sizes in the same way that a fixed default > in the kernel does. An st_blksize of 0 means stdio's BUFSIZ in many > cases, since stdio prefers to use st_blksize but has to invent a block > size if st_blksize is not useful. BUFSIZ is 1024, which is rather > small these days. It's good for slow cdevs but not much else. ok, what do you think about this patch? Index: vfs_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v retrieving revision 1.126 diff -u -p -r1.126 vfs_vnops.c --- vfs_vnops.c 13 Jan 2002 11:58:03 -0000 1.126 +++ vfs_vnops.c 20 Jan 2002 17:45:38 -0000 @@ -571,17 +571,17 @@ vn_stat(vp, sb, td) * Default to zero to catch bogus uses of this field. */ - if (vap->va_type == VREG) { - sb->st_blksize = vap->va_blocksize; - } else if (vn_isdisk(vp, NULL)) { + if (vn_isdisk(vp, NULL)) { sb->st_blksize = vp->v_rdev->si_bsize_best; if (sb->st_blksize < vp->v_rdev->si_bsize_phys) sb->st_blksize = vp->v_rdev->si_bsize_phys; if (sb->st_blksize < BLKDEV_IOSIZE) sb->st_blksize = BLKDEV_IOSIZE; - } else { - sb->st_blksize = 0; - } + } else + sb->st_blksize = vap->va_blocksize; + + if (sb->st_blksize == 0) + sb->st_blksize = PAGE_SIZE; sb->st_flags = vap->va_flags; if (suser_xxx(td->td_proc->p_ucred, 0, 0)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 12:43: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 3CE9037B405 for ; Sun, 20 Jan 2002 12:43:00 -0800 (PST) Received: (qmail 34688 invoked by uid 1000); 20 Jan 2002 20:43:45 -0000 Date: Sun, 20 Jan 2002 22:43:45 +0200 From: Peter Pentchev To: arch@FreeBSD.org Cc: djm@mindrot.org Subject: sftp, glob(3) and GLOB_NOMATCH - urgent before 4.5-R! Message-ID: <20020120224344.A15845@straylight.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org, djm@mindrot.org References: <20020118223810.D5B0FE92A@shitei.mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020118223810.D5B0FE92A@shitei.mindrot.org>; from bugzilla-daemon@mindrot.org on Sat, Jan 19, 2002 at 09:38:10AM +1100 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, In FreeBSD PR 34019, the submitter discusses an sftp core dump when a nonexistent file is uploaded. I found out that the same bug exists on uploading, and that it is caused by the fact that sftp expects glob(3) to error out when no matches are found. I opened up an OpenSSH problem report (bug id 73 in the mindrot.org database) and soon afterwards, I received the attached reply, which was CC'd to our GNATS. So.. somebody who is acquainted with standards, compatiblity, POLA and stuff - how do we go about this? Do we commit the fix in the audit trail of PR 34019, thus making another local change to OpenSSH? Do we change glob(3)'s behavior to return GLOB_NOMATCH? Or do we ship 4.5 with a known bad sftp client? :) I've CC'd Damien Miller (thanks for the fast response!) so that the OpenSSH folks are also aware of this discussion. G'luck, Peter -- because I didn't think of a good beginning of it. On Sat, Jan 19, 2002 at 09:38:10AM +1100, bugzilla-daemon@mindrot.org wrote: > http://bugzilla.mindrot.org/show_bug.cgi?id=73 > > ------- Additional Comments From djm@mindrot.org 2002-01-19 09:38 ------- > Are you sure it is not your glob() implementation that is incorrect here? sftp > relies on glob to return non-zero (i.e. GLOB_NOMATCH) when no files are matched. > This works correctly on Linux, Solaris and OpenBSD. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 13: 4:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id A537137B404 for ; Sun, 20 Jan 2002 13:04:48 -0800 (PST) Received: from pool0122.cvx21-bradley.dialup.earthlink.net ([209.179.192.122] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16SP8l-0004QA-00; Sun, 20 Jan 2002 13:04:35 -0800 Message-ID: <3C4B30DF.62FFD77E@mindspring.com> Date: Sun, 20 Jan 2002 13:04:31 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Bruce Evans , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: doreti() and userret() References: 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 Julian Elischer wrote: > I notice that you are reversing people's work of gradually > getting rid of K&R function declarations. This is opposite to what we > are doing as a group. (converting functions to ansi declarations > as we hit them). If you want, I could "hit" all of them for you; that would be as simple as running one of the ANSI-fication programs from port, if you were really into the idea of FreeBSD never being able to be compiled with a K&R compiler ever again. We all know that prototypes exist because there is a missing linker field in object files that would do that same thing at link time, without needing to have prottypes in scope at compilation time, and that this is probably because the compiler vendors were lazy at the time, and didn't want to have to modify their linkers or object file formats. Now we have the ability to put this information into a seperate ELF section, there's really no excuse for prototypes... Whatever happened to the idea that BSD code would run everywhere, or that an OS might have to be ported to a new platform, without the OS porting team having to become the GCC maintainer for that platform for the next 2 years, minimally, in order to meet the license and distribution requirements of GPL derived code? > > Please don't top post (top mail?). > > what does that mean? > I shouldn't add to the top of the old email? It means "don't post a response before the context in which the response is being made, or don't include unnecessary context at all, if the context included is not needed". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 13:25:58 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 F3E1537B416 for ; Sun, 20 Jan 2002 13:25:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g0KLPqf31593; Sun, 20 Jan 2002 16:25:52 -0500 (EST) (envelope-from wollman) Date: Sun, 20 Jan 2002 16:25:52 -0500 (EST) From: Garrett Wollman Message-Id: <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu> To: Michal Mertl Cc: arch@FreeBSD.org Subject: Re: 64 bit counters again In-Reply-To: References: <3C48FCEF.9190CA08@mindspring.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 I hope you'll forgive me for reopening this up to -arch again.... < said: > But compare and exchange or conditional move insns should be there. > And because the platform is fully 64 bit AFAIK I'd expect at least > 64 bit variants of them. The cache coherency problem is also > unrelated - it's there whatever size you have. The ultimate upshot of this is that it does not make sense to expose low-level primitives (such as compare-exchange or LL/SC) directly in the API. This is because each processor architecture will have its own requirements for coherency, in some cases requiring specialized instructions which a compiler would not normally generate, and often requiring memory barriers inside the spin loop. However, we can easily define a set of basic operations which every architecture we currently support can implement reliably and coherently without locking, including incrementing counters and updating some kinds of linked lists. (This has been proven both formally and by construction; see a recent Algorithms textbook.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 13:28:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id B72A037B405 for ; Sun, 20 Jan 2002 13:28:39 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id IAA24070; Mon, 21 Jan 2002 08:28:30 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KDBRHUHN0GVLYAGO@cim.alcatel.com.au>; Mon, 21 Jan 2002 08:28:28 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g0KLSR663168; Mon, 21 Jan 2002 08:28:27 +1100 Content-return: prohibited Date: Mon, 21 Jan 2002 08:28:27 +1100 From: Peter Jeremy Subject: Re: 64 bit counters again In-reply-to: <3C48FCEF.9190CA08@mindspring.com>; from tlambert2@mindspring.com on Fri, Jan 18, 2002 at 08:58:23PM -0800 To: Terry Lambert Cc: Garrett Wollman , mime@traveller.cz, arch@FreeBSD.ORG Mail-Followup-To: Terry Lambert , Garrett Wollman , mime@traveller.cz, arch@FreeBSD.ORG Message-id: <20020121082826.Z72285@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200201190350.g0J3oNN08944@khavrinen.lcs.mit.edu> <3C48FCEF.9190CA08@mindspring.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 2002-Jan-18 20:58:23 -0800, Terry Lambert wrote: >Garrett Wollman wrote: >> >> Yes. IA64. SPARC 9b (SPARC64) and Alpha, which are 64 >> >> bits, require locks, since they don't have the ability to >> >> do an atomic "lock; cmpxchg8b". >> > >> >Can they do "lock; add const,(mem)" in 32 or 64 bit? >> >> Terry is talking out of his ear again. >> >> Alpha most definitely does have 64-bit load-linked/store-conditional, >> which is entirely equivalent to i386's 64-bit compare-exchange. (For >> some reason in the Alpha ARM it's called ``load locked'' instead.) If >> we cared about running on MIPS architectures, they have LL/SC as well. >> SPARC v9 has 64-bit compare-and-swap (although unlike in IA32 a memory >> barrier is also required); see the SPARC v9 Architecture Reference >> Manual. IA64 has 64-bit compare-exchange as well; see the Itanium >> Architecture Software Developer's Manual, volume 2 (Intel document >> number 245318-003), where there's a whole section on implementing >> synchronization primitives on IA84; it also has an atomic FETCHADD >> instruction which I didn't bother to look more closely at. > >John Baldwin said: > >| Well, SMP on Pentium's maybe, but not on Alpha, sparc64, or ia64, all of which >| support OOE and looser memory models than x86, meaning that you really need >| locks unless you are going to have 386-specific code all over the place. I >| suppose you can wrap it behind an MI API but that seems like a lot of work for >| fairly small gain that can end up making the code uglier. > >So you can argue it out with him, Garrett. I think that we are suffering from an excessively vague definition of "lock". John is correct in saying that there is no equivalent of the IA32 "lock" prefix. Terry is correct that there is no atomic "lock; cmpxchg8b" _instruction_ - the equivalent needs an sequence of instructions - but that sequence includes locking - there's no need for separate mutex-style locks. John's comment is in response to an (incorrect) claim I made, and relates more to the need to include memory barriers than atomic locks - I think it is taken out of context here. On the IA32, it is possible to perform 32-bit atomic memory operations with very simple code sequences, eg "lock; addl reg,mem". None of the RISC architectures support memory RMW instructions, instead they all need a code sequence. 64-bit equivalents to the above IA32 instruction are: IA32: movl mem,%eax movl 4+mem,%edx 1: movl reg_lo,%ebx movl reg_hi,%ecx addl %eax,%ebx adcl %edx,%ecx lock cmpxchg8b mem jnz 1b Alpha (this is functionally correct but the branch is sub-optimal): 1: ldq_l r1,mem addq r1,reg,r1 stq_c r1,mem bne r1,1b I don't know SPARCv9 or IA64, so can't comment on those, but from Garrett's comments, the IA64 code is similar to the IA32 code and the SPARCv9 code is similar to the Alpha code. >Meanwhile, with a 32 bit cmpxchg, I don't need locks at all, >unless I want 64 bit counters so I can measure the wrong >thing. In a UP environment you don't need locks for either 32 or 64-bit operations. For an SMP environment, you need locks on both. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 13:36:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id E54CA37B404 for ; Sun, 20 Jan 2002 13:36:30 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id IAA24755; Mon, 21 Jan 2002 08:36:29 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37645) with ESMTP id <01KDBRS4AHSG5IJHWU@cim.alcatel.com.au>; Mon, 21 Jan 2002 08:36:46 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g0KLaQt63218; Mon, 21 Jan 2002 08:36:26 +1100 Content-return: prohibited Date: Mon, 21 Jan 2002 08:36:26 +1100 From: Peter Jeremy Subject: Re: 64 bit counters again In-reply-to: <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Sun, Jan 20, 2002 at 04:25:52PM -0500 To: Garrett Wollman Cc: Michal Mertl , arch@FreeBSD.ORG Mail-Followup-To: Garrett Wollman , Michal Mertl , arch@FreeBSD.ORG Message-id: <20020121083625.A72285@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <3C48FCEF.9190CA08@mindspring.com> <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu> 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-Jan-20 16:25:52 -0500, Garrett Wollman wrote: >The ultimate upshot of this is that it does not make sense to expose >low-level primitives (such as compare-exchange or LL/SC) directly in >the API. This is because each processor architecture will have its >own requirements for coherency, in some cases requiring specialized >instructions which a compiler would not normally generate, and often >requiring memory barriers inside the spin loop. Agreed. >However, we can easily define a set of basic operations which every >architecture we currently support can implement reliably and >coherently without locking, including incrementing counters and ^^^^^^^ protecting the operation by a separate mutex or semaphore-style lock. >updating some kinds of linked lists. Some form of inter-processor locking is required, but the low=level primitives implicitly achieve this. We already have a MI API for much of this in /sys//include/atomic.h Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 14:24:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 1123D37B43E for ; Sun, 20 Jan 2002 14:24:09 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id g0KMO8E56230 for ; Sun, 20 Jan 2002 17:24:08 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200201202224.g0KMO8E56230@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: arch@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: 64 bit counters again References: <200201190350.g0J3oNN08944@khavrinen.lcs.mit.edu> <3C48FCEF.9190CA08@mindspring.com> <20020121082826.Z72285@gsmx07.alcatel.com.au> In-reply-to: Your message of "Mon, 21 Jan 2002 08:28:27 +1100." <20020121082826.Z72285@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jan 2002 17:24:08 -0500 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 [trimming the cc: list] > In a UP environment you don't need locks for either 32 or 64-bit > operations. For an SMP environment, you need locks on both. As an innocent bystander so far, let me try to state some thoughts and let me know if I'm missing something: On an SMP system, some sort of locking is required to reliably update a 32 bit or 64 bit counter. - This can be an explicit high-level locking protocol; that is, obtaining some sort of lock object, updating the data in question, and then releasing the lock object. - This can be a low-level architectural feature, such as the IA32 LOCK prefix on an instruction to convert it into an atomic R-M-W operation. Either of these mechanisms require a distributed cache-invalidating operation to achieve the multiple CPU synchronization required. And I think that there's a general sense that it's this synchronization process which is "expensive" compared to the number of instructions executed to update the counters. If a simple spin-lock was used, then you could update an arbitrarily sized counter for essentially the same cost. If you were clever enough in writing your device drivers, you could arrange to update more than one counter (e.g., packets received, octets received) using the same lock, with the additional counters for free. This needs to be weighed against the per-CPU counters and the complexity associated with them. My gut feeling is that the level of contention is low enough that spin locks should be more than adequate to protect updating a couple of counters. This assumes that spin locks have not become expensive or bloated to invalidate their usefulness, I suppose. The larger thought is that there's this unstated assumption which probably needs to be state: We have and maintain accurate statistics on various operations that the FreeBSD kernel performs. For network elements, it's assumed that there are the typical network-interface stats which we also provide. We can agonize over the cost of having to implement all these statistics, but I'd claim that the kernel is defective if it doesn't do so. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 14:52: 3 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 8B76C37B419 for ; Sun, 20 Jan 2002 14:52:01 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g0KMpq032842; Sun, 20 Jan 2002 17:51:52 -0500 (EST) (envelope-from wollman) Date: Sun, 20 Jan 2002 17:51:52 -0500 (EST) From: Garrett Wollman Message-Id: <200201202251.g0KMpq032842@khavrinen.lcs.mit.edu> To: Peter Jeremy Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters again In-Reply-To: <20020121082826.Z72285@gsmx07.alcatel.com.au> References: <200201190350.g0J3oNN08944@khavrinen.lcs.mit.edu> <3C48FCEF.9190CA08@mindspring.com> <20020121082826.Z72285@gsmx07.alcatel.com.au> 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 < said: > 64-bit equivalents to the above IA32 instruction are: > IA32: > movl mem,%eax > movl 4+mem,%edx > 1: movl reg_lo,%ebx > movl reg_hi,%ecx > addl %eax,%ebx > adcl %edx,%ecx > lock cmpxchg8b mem > jnz 1b Actually, that local label needs to be two instructions earlier. The beauty of this instruction sequence is that it is also atomic with respect to interrupts on the local processor. > I don't know SPARCv9 or IA64, so can't comment on those, but from > Garrett's comments, the IA64 code is similar to the IA32 code and > the SPARCv9 code is similar to the Alpha code. Actually, the SPARC would be similar to the Intel. I think only Alpha and MIPS implemented the LL/SC version of this primitive. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 15:56:40 2002 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 1833437B404; Sun, 20 Jan 2002 15:56:34 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id g0KNuMg8095762; Mon, 21 Jan 2002 00:56:22 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g0KNuLrj095759; Mon, 21 Jan 2002 00:56:21 +0100 (CET) Date: Mon, 21 Jan 2002 00:56:21 +0100 (CET) From: Michal Mertl To: hackers@freebsd.org Cc: peter.jeremy@alcatel.com.au, , , , , , Subject: patch for network counter implementation (64bit/atomic) 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 After rather long discussion on arch with no apparent result I have my patch for STABLE ready. Sorry to repeat what has been already talked about but there may be people on hackers who don't read arch. I've posted 2 patches on http://home.eunet.cz/mime/syscntr.diff.20020120.gz and http://home.eunet.cz/mime/netstat.diff.gz (only modifies netstat to be able to show 64 bit values). The first one modifies lots of sources in kernel but I believe that most changes are totally harmless. It modifies all network device driver sources to use newly defined API for accessing counters (packets, bytes, errors...). It also modifies some files in /sys/net* to use the same API. The counters are defined in /sys/net/if.h and /sys/netinet/{ip|tcp|udp|igmp|icmp}_var.h and their type is changed from u_long to syscntr_t. The new API is defined in /sys/i386/include/syscntr.h but is 99% MI - no problem should occur with Alpha and other ports. By default the syscntr_t is u_int32_t and is accessed non-atomically. This is probably incorrect but it's the same way it's been done for ages so no new problem is created. Change of 2 defines in the file makes counters either 64 bit and/or atomic. Other API feature which may end up useless is that the different counters can be accessed by different type of operation (the size is always either 32 or 64 bit) - maybe even something not yet implemented - per cpu. Other change there is adding support for 64 bit atomic ops to X86 - unfortunatelly the instruction required for this operation is only or >=586. So atomic 64 bit operation is possible only on these computers - but that's maybe also only on SMP machines (>=586) where the atomicity is strictly needed. As discussed to death on arch atomicity and 64 bit both add to cost of accessing the counters. The most common operation is addition - on p3 non-atomic 32 bit cost about 2 clocks, atomic 32 bit 20 clocks, non-atomic 64 bit 7 clocks and atomic 64 bit 50 clocks. For each tcp packet we have at least 5 counter updates. The code is perfectly usable on CURRENT too. If there's single request I'll make sure it fits there 100%. There's one problem I'm aware of - NETGRAPH. It has some counters defined in code too and I think it will benefit from the change too. But I don't now if it's possible to change the types in there (are there NG drivers not it tree?). PS: After changing kernel counters from 32 to 64 bit, some of world has to be rebuild too (to notice the change in structs which contain the counters). Namely ifconfig, netstat, systat and probably others. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 15:59:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 8144A37B417 for ; Sun, 20 Jan 2002 15:59:42 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id g0KNxfg8095897; Mon, 21 Jan 2002 00:59:41 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g0KNxftE095894; Mon, 21 Jan 2002 00:59:41 +0100 (CET) Date: Mon, 21 Jan 2002 00:59:41 +0100 (CET) From: Michal Mertl To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters again In-Reply-To: <200201202125.g0KLPqf31593@khavrinen.lcs.mit.edu> 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 Sun, 20 Jan 2002, Garrett Wollman wrote: > I hope you'll forgive me for reopening this up to -arch again.... > > < said: > > > But compare and exchange or conditional move insns should be there. > > And because the platform is fully 64 bit AFAIK I'd expect at least > > 64 bit variants of them. The cache coherency problem is also > > unrelated - it's there whatever size you have. > > The ultimate upshot of this is that it does not make sense to expose > low-level primitives (such as compare-exchange or LL/SC) directly in > the API. This is because each processor architecture will have its It isn't exposed in the API as far as I see. > own requirements for coherency, in some cases requiring specialized > instructions which a compiler would not normally generate, and often > requiring memory barriers inside the spin loop. > > However, we can easily define a set of basic operations which every > architecture we currently support can implement reliably and > coherently without locking, including incrementing counters and > updating some kinds of linked lists. (This has been proven both > formally and by construction; see a recent Algorithms textbook.) Seems so. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 16: 8:12 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 0ABA737B402 for ; Sun, 20 Jan 2002 16:08:10 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g0L088333530; Sun, 20 Jan 2002 19:08:08 -0500 (EST) (envelope-from wollman) Date: Sun, 20 Jan 2002 19:08:08 -0500 (EST) From: Garrett Wollman Message-Id: <200201210008.g0L088333530@khavrinen.lcs.mit.edu> To: louie@TransSys.COM Subject: Re: 64 bit counters again X-Newsgroups: mit.lcs.mail.freebsd-arch In-Reply-To: References: Organization: MIT Laboratory for Computer Science 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 In article you write: >On an SMP system, some sort of locking is required to reliably >update a 32 bit or 64 bit counter. [...] > - This can be a low-level architectural feature, such as the IA32 >LOCK prefix on an instruction to convert it into an atomic R-M-W >operation. Technically, atomic RMW is not considered locking. (Hence, the class of algorithms known as ``lock-free synchronization algorithms''.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 16:12:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from prg.traveller.cz (prg.traveller.cz [193.85.2.77]) by hub.freebsd.org (Postfix) with ESMTP id 50E7137B402 for ; Sun, 20 Jan 2002 16:12:31 -0800 (PST) Received: from prg.traveller.cz (localhost [127.0.0.1]) by prg.traveller.cz (8.12.1[KQ-CZ](1)/8.12.1/pukvis) with ESMTP id g0L0CUg8096328; Mon, 21 Jan 2002 01:12:30 +0100 (CET) Received: from localhost (mime@localhost) by prg.traveller.cz (8.12.1[KQ-CZ](1)/pukvis) with ESMTP id g0L0CU6Q096325; Mon, 21 Jan 2002 01:12:30 +0100 (CET) Date: Mon, 21 Jan 2002 01:12:30 +0100 (CET) From: Michal Mertl To: "Louis A. Mamakos" Cc: arch@FreeBSD.ORG Subject: Re: 64 bit counters again In-Reply-To: <200201202224.g0KMO8E56230@whizzo.transsys.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 Sun, 20 Jan 2002, Louis A. Mamakos wrote: > If a simple spin-lock was used, then you could update an arbitrarily > sized counter for essentially the same cost. If you were clever > enough in writing your device drivers, you could arrange to > update more than one counter (e.g., packets received, octets received) > using the same lock, with the additional counters for free. > That's all nice but 1) would require quite a lot of bigger changes in kernel and 2) could sometimes create a contention for whole struct when only one member is needed (not too probable I guess). > This needs to be weighed against the per-CPU counters and the complexity > associated with them. > > My gut feeling is that the level of contention is low enough that spin > locks should be more than adequate to protect updating a couple of > counters. This assumes that spin locks have not become expensive or > bloated to invalidate their usefulness, I suppose. The 64 bit atomic ops on i386 work probably exactly the same. I guarantee there's no bloat :-). > > The larger thought is that there's this unstated assumption which > probably needs to be state: We have and maintain accurate statistics on > various operations that the FreeBSD kernel performs. For network > elements, it's assumed that there are the typical network-interface > stats which we also provide. We can agonize over the cost of having > to implement all these statistics, but I'd claim that the kernel > is defective if it doesn't do so. I won't be that harsh - some people may need them and they have their cost. We have lot of servers but none of them is longer time doing more than say 10Mbit. I would consider atomic ops free in this operation. -- Michal Mertl mime@traveller.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 17:55:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 3617D37B402 for ; Sun, 20 Jan 2002 17:55:32 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id MAA28161; Mon, 21 Jan 2002 12:55:29 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01KDC0TSTTN4VLWDUA@cim.alcatel.com.au>; Mon, 21 Jan 2002 12:55:26 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g0L1tNj64749; Mon, 21 Jan 2002 12:55:23 +1100 Content-return: prohibited Date: Mon, 21 Jan 2002 12:55:23 +1100 From: Peter Jeremy Subject: Re: 64 bit counters again In-reply-to: <200201202251.g0KMpq032842@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Sun, Jan 20, 2002 at 05:51:52PM -0500 To: Garrett Wollman Cc: arch@FreeBSD.ORG Mail-Followup-To: Garrett Wollman , arch@FreeBSD.ORG Message-id: <20020121125522.G72285@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200201190350.g0J3oNN08944@khavrinen.lcs.mit.edu> <3C48FCEF.9190CA08@mindspring.com> <20020121082826.Z72285@gsmx07.alcatel.com.au> <200201202251.g0KMpq032842@khavrinen.lcs.mit.edu> 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-Jan-20 17:51:52 -0500, Garrett Wollman wrote: >< said: > >> 64-bit equivalents to the above IA32 instruction are: >> IA32: >> movl mem,%eax >> movl 4+mem,%edx >> 1: movl reg_lo,%ebx >> movl reg_hi,%ecx >> addl %eax,%ebx >> adcl %edx,%ecx >> lock cmpxchg8b mem >> jnz 1b > >Actually, that local label needs to be two instructions earlier. According to the Intel Architecture Software Developer's Manual, volume 2 (1999 - order 243191), cmpxchg8b is defined as "compare EDX:EAX with m64. If equal, set ZF and load ECX:EBX into m64. Else, clear ZF and load m64 into EDX:EAX". Based on this, the initial move doesn't need to be repeated because it's embedded in the "fail" case of cmpxchg8b. The label may need to be before the initial load for other compare-and-swap implementations. > The >beauty of this instruction sequence is that it is also atomic with >respect to interrupts on the local processor. I think that's also true of all the atomic sequences. Definitely an interrupt will release the lock on an Alpha ldq_l/stq_l sequence (and make it take an extra pass thru the loop). >> I don't know SPARCv9 or IA64, so can't comment on those, but from >> Garrett's comments, the IA64 code is similar to the IA32 code and >> the SPARCv9 code is similar to the Alpha code. > >Actually, the SPARC would be similar to the Intel. I think only Alpha >and MIPS implemented the LL/SC version of this primitive. Sorry about that. I mis-read your mail. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 18:57:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id EE3E737B41A for ; Sun, 20 Jan 2002 18:57:42 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g0L2vfl46775; Sun, 20 Jan 2002 19:57:41 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g0L2vex41985; Sun, 20 Jan 2002 19:57:40 -0700 (MST) (envelope-from imp@village.org) Date: Sun, 20 Jan 2002 19:57:25 -0700 (MST) Message-Id: <20020120.195725.87764038.imp@village.org> To: peter.jeremy@alcatel.com.au Cc: wollman@khavrinen.lcs.mit.edu, arch@FreeBSD.ORG Subject: Re: 64 bit counters again From: "M. Warner Losh" In-Reply-To: <20020121125522.G72285@gsmx07.alcatel.com.au> References: <20020121082826.Z72285@gsmx07.alcatel.com.au> <200201202251.g0KMpq032842@khavrinen.lcs.mit.edu> <20020121125522.G72285@gsmx07.alcatel.com.au> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 In message: <20020121125522.G72285@gsmx07.alcatel.com.au> Peter Jeremy writes: : >Actually, the SPARC would be similar to the Intel. I think only Alpha : >and MIPS implemented the LL/SC version of this primitive. Not all MIPS processors have LL/SC. Vr41xx lack this, for example. However, there are no SMP Vr41xx systems, and I don't think any can be made due to all that cache coherency and interprocessor locking crap being removed :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 21:26:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by hub.freebsd.org (Postfix) with ESMTP id 7BC7B37B400 for ; Sun, 20 Jan 2002 21:26:07 -0800 (PST) Received: from dagger.cc.vt.edu (IDENT:mirapoint@dagger-lb.cc.vt.edu [10.1.1.11]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g0L5Q4C442098; Mon, 21 Jan 2002 00:26:04 -0500 (EST) Received: from enterprise.muriel.penguinpowered.com (hc6526444.dhcp.vt.edu [198.82.100.68]) by dagger.cc.vt.edu (Mirapoint) with ESMTP id ASX47627; Mon, 21 Jan 2002 00:26:03 -0500 (EST) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="_=XFMail.1.5.2.FreeBSD:20020121002603:272=_"; micalg=pgp-md5; protocol="application/pgp-signature" In-Reply-To: <20020120224344.A15845@straylight.oblivion.bg> Date: Mon, 21 Jan 2002 00:26:03 -0500 (EST) From: Mike Heffner To: Peter Pentchev Subject: Re: sftp, glob(3) and GLOB_NOMATCH - urgent before 4.5-R! Cc: djm@mindrot.org, 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 This message is in MIME format --_=XFMail.1.5.2.FreeBSD:20020121002603:272=_ Content-Type: text/plain; charset=us-ascii Well, IEEE 1003.1-2001 states that glob(3) should return GLOB_NOMATCH, but, as noticed, this hasn't been implemented in glob(3) yet. IMO, since we are so close to 4.5R, we should commit the local change in the PR to OpenSSH and worry about implementing GLOB_NOMATCH (and the other options that are lacking in glob(3)) after 4.5R. The change in the PR will be forwards compatible when it comes to implementing GLOB_NOMATCH. In anycase, the (untested) patch below should be enough to implement GLOB_NOMATCH. On 20-Jan-2002 Peter Pentchev wrote: | Hi, | | In FreeBSD PR 34019, the submitter discusses an sftp core dump when | a nonexistent file is uploaded. I found out that the same bug | exists on uploading, and that it is caused by the fact that sftp | expects glob(3) to error out when no matches are found. I opened | up an OpenSSH problem report (bug id 73 in the mindrot.org database) | and soon afterwards, I received the attached reply, which was CC'd | to our GNATS. | | So.. somebody who is acquainted with standards, compatiblity, POLA | and stuff - how do we go about this? Do we commit the fix in the | audit trail of PR 34019, thus making another local change to OpenSSH? | Do we change glob(3)'s behavior to return GLOB_NOMATCH? Or do we ship | 4.5 with a known bad sftp client? :) I've CC'd Damien Miller (thanks | for the fast response!) so that the OpenSSH folks are also aware of | this discussion. | Mike -- Mike Heffner Blacksburg, VA Index: include/glob.h =================================================================== RCS file: /home/ncvs/src/include/glob.h,v retrieving revision 1.5 diff -u -r1.5 glob.h --- include/glob.h 29 Jul 2001 00:52:33 -0000 1.5 +++ include/glob.h 21 Jan 2002 05:15:47 -0000 @@ -82,8 +82,10 @@ /* backwards compatibility, this is the old name for this option */ #define GLOB_MAXPATH GLOB_LIMIT +/* Error values returned by glob(3) */ #define GLOB_NOSPACE (-1) /* Malloc call failed. */ #define GLOB_ABEND (-2) /* Unignored error. */ +#define GLOB_NOMATCH (-3) /* No match and GLOB_NOCHECK was not set. */ __BEGIN_DECLS int glob __P((const char *, int, int (*)(const char *, int), glob_t *)); Index: lib/libc/gen/glob.3 =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/glob.3,v retrieving revision 1.20 diff -u -r1.20 glob.3 --- lib/libc/gen/glob.3 1 Oct 2001 16:08:51 -0000 1.20 +++ lib/libc/gen/glob.3 21 Jan 2002 05:15:47 -0000 @@ -392,6 +392,10 @@ was set or .Fa \*(lp*errfunc\*(rp\*(lp\*(rp returned non-zero. +.It Dv GLOB_NOMATCH +The pattern did not match a pathname and +.Dv GLOB_NOCHECK +was not set. .El .Pp The arguments Index: lib/libc/gen/glob.c =================================================================== RCS file: /home/ncvs/src/lib/libc/gen/glob.c,v retrieving revision 1.18 diff -u -r1.18 glob.c --- lib/libc/gen/glob.c 29 Jul 2001 00:52:33 -0000 1.18 +++ lib/libc/gen/glob.c 21 Jan 2002 05:15:48 -0000 @@ -493,12 +493,15 @@ * and the pattern did not contain any magic characters * GLOB_NOMAGIC is there just for compatibility with csh. */ - if (pglob->gl_pathc == oldpathc && - ((pglob->gl_flags & GLOB_NOCHECK) || - ((pglob->gl_flags & GLOB_NOMAGIC) && - !(pglob->gl_flags & GLOB_MAGCHAR)))) - return(globextend(pattern, pglob, limit)); - else if (!(pglob->gl_flags & GLOB_NOSORT)) + if (pglob->gl_pathc == oldpathc) { + if ((pglob->gl_flags & GLOB_NOCHECK) || + ((pglob->gl_flags & GLOB_NOMAGIC) && + !(pglob->gl_flags & GLOB_MAGCHAR))) + return(globextend(pattern, pglob, limit)); + else + return(GLOB_NOMATCH); + } + if (!(pglob->gl_flags & GLOB_NOSORT)) qsort(pglob->gl_pathv + pglob->gl_offs + oldpathc, pglob->gl_pathc - oldpathc, sizeof(char *), compare); return(0); --_=XFMail.1.5.2.FreeBSD:20020121002603:272=_ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8S6ZqFokZQs3sv5kRAvQCAKCIWOjv7qswCBlHMMF5ZjF+B/qk7ACfZGVb 9xU3Ez2+5yz702nxWw82fKY= =jcDU -----END PGP SIGNATURE----- --_=XFMail.1.5.2.FreeBSD:20020121002603:272=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 22:38:35 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 D0C7737B416 for ; Sun, 20 Jan 2002 22:38:32 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0L6cFO01596; Sun, 20 Jan 2002 22:38:15 -0800 (PST) (envelope-from dillon) Date: Sun, 20 Jan 2002 22:38:15 -0800 (PST) From: Matthew Dillon Message-Id: <200201210638.g0L6cFO01596@apollo.backplane.com> To: Eugene Grosbein Cc: arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files References: <20020120102521.A450@grosbein.pp.ru> 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! : :There is very frequently asked (at least, in Russian newsgroups) question: :is it possible to make Midnight Commander enter to archives on msdosfs :and stop his attempts to execute files there? The only way is to :use '-m 644', but then you can enter directories as root only. :Finally I got tired of these questions and patched kernel, :mount_msdosfs and its man page to accept new option '-M mask'. :This mask is used for directories only, if supplied. :If -M is used and -m is not then supplied mask is used for all objects. :I do not run CURRENT so this patch is for 4.5RC1 :That is my first 6K kernel patch so please review. :It works at least for me :-) Why not simply mount the filesystem with the 'noexec' flag? The patch looks fine, but I don't like the idea of such a targeted hack being added to the mount code and we definitely do not want to go changing msdosfs's mount structure just before the release either. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 20 22:49:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by hub.freebsd.org (Postfix) with ESMTP id C15A437B404 for ; Sun, 20 Jan 2002 22:49:19 -0800 (PST) Received: from www.kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.11.6/8.11.6) with ESMTP id g0L6n8m14630; Mon, 21 Jan 2002 13:49:08 +0700 (KRAT) (envelope-from eugen@www.kuzbass.ru) Message-ID: <3C4BB9E5.E7E63C29@www.kuzbass.ru> Date: Mon, 21 Jan 2002 13:49:09 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Matthew Dillon Cc: Eugene Grosbein , arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> Content-Type: text/plain; charset=koi8-r 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 Matthew Dillon wrote: > :That is my first 6K kernel patch so please review. > :It works at least for me :-) > Why not simply mount the filesystem with the 'noexec' flag? This does not turn 'executable' bit off from files and therefore does not prevent midc from 'executing' archives instead of 'entering into' them. > The patch looks fine, but I don't like the idea of such a targeted > hack being added to the mount code and we definitely do not want to > go changing msdosfs's mount structure just before the release either. I understand this wouldn't be wise. The patch is for 4.5-RC1 just because I run it now :-) Of course, it should be tested in CURRENT first as usual but I just have not CURRENT and there is no need to rush before release. Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 21 4:28:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from camelot.spsl.nsc.ru (camelot.spsl.nsc.ru [194.226.174.80]) by hub.freebsd.org (Postfix) with ESMTP id 7E46537B404 for ; Mon, 21 Jan 2002 04:28:21 -0800 (PST) Received: (from root@localhost) by camelot.spsl.nsc.ru (8.11.6/8.11.6) id g0LCP2j04315 for arch@freebsd.org.AVP; Mon, 21 Jan 2002 18:25:02 +0600 (NOVT) (envelope-from fjoe@iclub.nsu.ru) Received: from iclub.nsu.ru (root@iclub.nsu.ru [193.124.222.66]) by camelot.spsl.nsc.ru (8.11.6/8.11.6) with ESMTP id g0LCP0q04304; Mon, 21 Jan 2002 18:25:01 +0600 (NOVT) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.11.6/8.11.6) id g0LCOpK91803; Mon, 21 Jan 2002 18:24:51 +0600 (NS) (envelope-from fjoe) Date: Mon, 21 Jan 2002 18:24:50 +0600 From: Max Khon To: Bruce Evans Cc: Cy Schubert - ITSD Open Systems Group , Poul-Henning Kamp , arch@freebsd.org Subject: Re: request for review Message-ID: <20020121182450.A91754@iclub.nsu.ru> References: <20020116000607.B10938@iclub.nsu.ru> <20020116155828.T487-100000@gamplex.bde.org> <20020121001749.A80939@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020121001749.A80939@iclub.nsu.ru>; from fjoe@iclub.nsu.ru on Mon, Jan 21, 2002 at 12:17:49AM +0600 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, there! On Mon, Jan 21, 2002 at 12:17:49AM +0600, Max Khon wrote: > ok, what do you think about this patch? > > Index: vfs_vnops.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v > retrieving revision 1.126 > diff -u -p -r1.126 vfs_vnops.c > --- vfs_vnops.c 13 Jan 2002 11:58:03 -0000 1.126 > +++ vfs_vnops.c 20 Jan 2002 17:45:38 -0000 > @@ -571,17 +571,17 @@ vn_stat(vp, sb, td) > * Default to zero to catch bogus uses of this field. > */ > > - if (vap->va_type == VREG) { > - sb->st_blksize = vap->va_blocksize; > - } else if (vn_isdisk(vp, NULL)) { > + if (vn_isdisk(vp, NULL)) { > sb->st_blksize = vp->v_rdev->si_bsize_best; > if (sb->st_blksize < vp->v_rdev->si_bsize_phys) > sb->st_blksize = vp->v_rdev->si_bsize_phys; > if (sb->st_blksize < BLKDEV_IOSIZE) > sb->st_blksize = BLKDEV_IOSIZE; > - } else { > - sb->st_blksize = 0; > - } > + } else > + sb->st_blksize = vap->va_blocksize; > + > + if (sb->st_blksize == 0) > + sb->st_blksize = PAGE_SIZE; > > sb->st_flags = vap->va_flags; > if (suser_xxx(td->td_proc->p_ucred, 0, 0)) btw NetBSD/OpenBSD have the following code in ufs_getattr(): /* this doesn't belong here */ if (vp->v_type == VBLK) vap->va_blocksize = BLKDEV_IOSIZE; else if (vp->v_type == VCHR) vap->va_blocksize = MAXBSIZE; else vap->va_blocksize = vp->v_mount->mnt_stat.f_iosize; /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 21 9:27:48 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 334F337B4A1 for ; Mon, 21 Jan 2002 09:27:39 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0LHRBG03770; Mon, 21 Jan 2002 09:27:11 -0800 (PST) (envelope-from dillon) Date: Mon, 21 Jan 2002 09:27:11 -0800 (PST) From: Matthew Dillon Message-Id: <200201211727.g0LHRBG03770@apollo.backplane.com> To: Eugene Grosbein Cc: Eugene Grosbein , arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> <3C4BB9E5.E7E63C29@www.kuzbass.ru> 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 :> Why not simply mount the filesystem with the 'noexec' flag? : :This does not turn 'executable' bit off from files :and therefore does not prevent midc from 'executing' archives :instead of 'entering into' them. Ah. It kinda sounds like midc itself should be hacked as an 'official' solution rather then msdosfs, but I think you've done an excellent job to deal with your own users. -Matt :> The patch looks fine, but I don't like the idea of such a targeted :> hack being added to the mount code and we definitely do not want to :> go changing msdosfs's mount structure just before the release either. : :I understand this wouldn't be wise. The patch is for 4.5-RC1 just because :I run it now :-) Of course, it should be tested in CURRENT first as usual :but I just have not CURRENT and there is no need to rush before release. : :Eugene Grosbein -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 Mon Jan 21 15:30:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4BD4237B402; Mon, 21 Jan 2002 15:30:42 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA06126; Mon, 21 Jan 2002 16:30:40 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0LNUcM17764; Mon, 21 Jan 2002 16:30:38 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15436.42142.53176.44467@caddis.yogotech.com> Date: Mon, 21 Jan 2002 16:30:38 -0700 To: Robert Watson Cc: Greg Lehey , Dan Langille , Ruslan Ermilov , Joerg Wunsch , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist In-Reply-To: References: <20020119105733.A50299@wantadilla.lemis.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > Not in this forum. But we're not typical of the user base. I will > > continue to use catman, probably making it world writeable, since in my > > situation this isn't a compromise. But what about the man in the > > street? > > The difference between the developers and the users is that the users > hardly ever change the man pages, and so would probably benefit most from > simply using the catman pages in a pregenerated form, rather than having > to wait for each page to render the first time they read it, gradually > consuming more and more disk space as they read more manpages. Except that this doesn't allow the 'users' to print out the pages in a form that may be more usable by them. For example, for most manpages, I simply type 'man', but sometimes I want to print out the manpage on my printer, so I create a postscript file that is formatted better, and prints out much nicer than the tradional 'dumb terminal' manpage that is created by default as the catpage. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 21 15:54:24 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 03A9537B402; Mon, 21 Jan 2002 15:54:14 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g0LNs2D79121; Mon, 21 Jan 2002 18:54:02 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 21 Jan 2002 18:54:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nate Williams Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist In-Reply-To: <15436.42142.53176.44467@caddis.yogotech.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, 21 Jan 2002, Nate Williams wrote: > > > Not in this forum. But we're not typical of the user base. I will > > > continue to use catman, probably making it world writeable, since in my > > > situation this isn't a compromise. But what about the man in the > > > street? > > > > The difference between the developers and the users is that the users > > hardly ever change the man pages, and so would probably benefit most from > > simply using the catman pages in a pregenerated form, rather than having > > to wait for each page to render the first time they read it, gradually > > consuming more and more disk space as they read more manpages. > > Except that this doesn't allow the 'users' to print out the pages in a > form that may be more usable by them. > > For example, for most manpages, I simply type 'man', but sometimes I > want to print out the manpage on my printer, so I create a postscript > file that is formatted better, and prints out much nicer than the > tradional 'dumb terminal' manpage that is created by default as the > catpage. This doesn't preclude having the nroff sources installed also, I'm just pointing out that the argument that it's in the user's best interest to use the man cache mechanism seems a bit bogus to me. The intended goal of the man cache was presumably to avoid the full disk cost of catman pages, while attempting also to avoid the cpu cost of processing the page every time it's viewed. However, in practice it has become a security/space tradeoff: you sacrifice security to conserve a few megabytes of space in catman files. I think that the benefit may once have been there, but I think on modern systems that it's really not there. For compatibility purposes, it might be reasonable to install man non-setuid, but still have the cat pages and directories be installed as the man user. Then twiddling man to setuid man from bin/bin would still work for those wanting to enable it. However, for the default install, we should either rely purely on nroff source, or also install the catman distribution. 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 Mon Jan 21 18:56:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by hub.freebsd.org (Postfix) with ESMTP id 4982537B400 for ; Mon, 21 Jan 2002 18:56:09 -0800 (PST) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.11.6/8.11.6) id g0M2tr684056; Tue, 22 Jan 2002 09:55:53 +0700 (KRAT) (envelope-from eugen) Date: Tue, 22 Jan 2002 09:55:53 +0700 From: Eugene Grosbein To: Matthew Dillon Cc: arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files Message-ID: <20020122095553.A83831@svzserv.kemerovo.su> References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> <3C4BB9E5.E7E63C29@www.kuzbass.ru> <200201211727.g0LHRBG03770@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: <200201211727.g0LHRBG03770@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Jan 21, 2002 at 09:27:11AM -0800 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, Jan 21, 2002 at 09:27:11AM -0800, Matthew Dillon wrote: > :> Why not simply mount the filesystem with the 'noexec' flag? > :This does not turn 'executable' bit off from files > :and therefore does not prevent midc from 'executing' archives > :instead of 'entering into' them. > Ah. It kinda sounds like midc itself should be hacked as an 'official' > solution rather then msdosfs, but I think you've done an excellent job > to deal with your own users. Does it mean this path will not be commited even after code freeze? Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 21 19: 5:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id CDCFE37B400 for ; Mon, 21 Jan 2002 19:05:38 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 9412410DDF7; Mon, 21 Jan 2002 19:05:38 -0800 (PST) Date: Mon, 21 Jan 2002 19:05:38 -0800 From: Alfred Perlstein To: Eugene Grosbein Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files Message-ID: <20020121190538.T13686@elvis.mu.org> References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> <3C4BB9E5.E7E63C29@www.kuzbass.ru> <200201211727.g0LHRBG03770@apollo.backplane.com> <20020122095553.A83831@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020122095553.A83831@svzserv.kemerovo.su>; from eugen@www.svzserv.kemerovo.su on Tue, Jan 22, 2002 at 09:55:53AM +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 * Eugene Grosbein [020121 18:56] wrote: > On Mon, Jan 21, 2002 at 09:27:11AM -0800, Matthew Dillon wrote: > > > :> Why not simply mount the filesystem with the 'noexec' flag? > > :This does not turn 'executable' bit off from files > > :and therefore does not prevent midc from 'executing' archives > > :instead of 'entering into' them. > > Ah. It kinda sounds like midc itself should be hacked as an 'official' > > solution rather then msdosfs, but I think you've done an excellent job > > to deal with your own users. > > Does it mean this path will not be commited even after code freeze? Can you open a PR containing the patch so that it doesn't get lost? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 21 19:22:29 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 0A6C537B404 for ; Mon, 21 Jan 2002 19:22:23 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0M3MJ290659; Mon, 21 Jan 2002 19:22:19 -0800 (PST) (envelope-from dillon) Date: Mon, 21 Jan 2002 19:22:19 -0800 (PST) From: Matthew Dillon Message-Id: <200201220322.g0M3MJ290659@apollo.backplane.com> To: Eugene Grosbein Cc: arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> <3C4BB9E5.E7E63C29@www.kuzbass.ru> <200201211727.g0LHRBG03770@apollo.backplane.com> <20020122095553.A83831@svzserv.kemerovo.su> 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, Jan 21, 2002 at 09:27:11AM -0800, Matthew Dillon wrote: : :> :> Why not simply mount the filesystem with the 'noexec' flag? :> :This does not turn 'executable' bit off from files :> :and therefore does not prevent midc from 'executing' archives :> :instead of 'entering into' them. :> Ah. It kinda sounds like midc itself should be hacked as an 'official' :> solution rather then msdosfs, but I think you've done an excellent job :> to deal with your own users. : :Does it mean this path will not be commited even after code freeze? : :Eugene Grosbein Correct. I don't even know if the patch should be comitted at all, even after the freeze. It seems like such a huge hack just to get around the fact that somebody is actually trying to read files from an msdosfs mount using midnight commander. There are many, many problems using msdosfs as a general purpose filesystem, above and beyond the fact that the 'execute' bit gets set on everything. -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 Mon Jan 21 19:53:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by hub.freebsd.org (Postfix) with ESMTP id D62C137B404 for ; Mon, 21 Jan 2002 19:53:11 -0800 (PST) Received: from www.kuzbass.ru (kost [213.184.65.82]) by www.svzserv.kemerovo.su (8.11.6/8.11.6) with ESMTP id g0M3qmm87053; Tue, 22 Jan 2002 10:52:49 +0700 (KRAT) (envelope-from eugen@www.kuzbass.ru) Message-ID: <3C4CE211.A39AA155@www.kuzbass.ru> Date: Tue, 22 Jan 2002 10:52:49 +0700 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: Alfred Perlstein Cc: Matthew Dillon , arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> <3C4BB9E5.E7E63C29@www.kuzbass.ru> <200201211727.g0LHRBG03770@apollo.backplane.com> <20020122095553.A83831@svzserv.kemerovo.su> <20020121190538.T13686@elvis.mu.org> Content-Type: text/plain; charset=koi8-r 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 > Can you open a PR containing the patch so that it doesn't get lost? I could but it seems useless after Matt's reply. So I mark it Public Domain :-) Feel free to make PR if you wish. Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jan 21 21:13:40 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 BF8DB37B400 for ; Mon, 21 Jan 2002 21:13:38 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0M5DXe90954; Mon, 21 Jan 2002 21:13:33 -0800 (PST) (envelope-from dillon) Date: Mon, 21 Jan 2002 21:13:33 -0800 (PST) From: Matthew Dillon Message-Id: <200201220513.g0M5DXe90954@apollo.backplane.com> To: Eugene Grosbein Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: [PATCH] msdosfs: differrent masks for directories and other files References: <20020120102521.A450@grosbein.pp.ru> <200201210638.g0L6cFO01596@apollo.backplane.com> <3C4BB9E5.E7E63C29@www.kuzbass.ru> <200201211727.g0LHRBG03770@apollo.backplane.com> <20020122095553.A83831@svzserv.kemerovo.su> <20020121190538.T13686@elvis.mu.org> <3C4CE211.A39AA155@www.kuzbass.ru> 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 :> Can you open a PR containing the patch so that it doesn't get lost? : :I could but it seems useless after Matt's reply. :So I mark it Public Domain :-) :Feel free to make PR if you wish. : :Eugene Grosbein I'm not saying I'm against it, just that I'm not for it (if that makes any sense). i.e. if somebody commits it, I won't complain. -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 Jan 22 0:44:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id C5DA037B404; Tue, 22 Jan 2002 00:44:23 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0M8hOb80099; Tue, 22 Jan 2002 10:43:24 +0200 (EET) (envelope-from ru) Date: Tue, 22 Jan 2002 10:43:24 +0200 From: Ruslan Ermilov To: Nate Williams Cc: Robert Watson , Greg Lehey , Dan Langille , Joerg Wunsch , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist Message-ID: <20020122104324.B78733@sunbay.com> References: <20020119105733.A50299@wantadilla.lemis.com> <15436.42142.53176.44467@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15436.42142.53176.44467@caddis.yogotech.com> User-Agent: Mutt/1.3.23i 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, Jan 21, 2002 at 04:30:38PM -0700, Nate Williams wrote: > > > Not in this forum. But we're not typical of the user base. I will > > > continue to use catman, probably making it world writeable, since in my > > > situation this isn't a compromise. But what about the man in the > > > street? > > > > The difference between the developers and the users is that the users > > hardly ever change the man pages, and so would probably benefit most from > > simply using the catman pages in a pregenerated form, rather than having > > to wait for each page to render the first time they read it, gradually > > consuming more and more disk space as they read more manpages. > > Except that this doesn't allow the 'users' to print out the pages in a > form that may be more usable by them. > > For example, for most manpages, I simply type 'man', but sometimes I > want to print out the manpage on my printer, so I create a postscript > file that is formatted better, and prints out much nicer than the > tradional 'dumb terminal' manpage that is created by default as the > catpage. > ``man -t'' should work. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 0:59: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 8B1C237B400; Tue, 22 Jan 2002 00:58:45 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0M8wdw82301; Tue, 22 Jan 2002 10:58:39 +0200 (EET) (envelope-from ru) Date: Tue, 22 Jan 2002 10:58:39 +0200 From: Ruslan Ermilov To: Robert Watson Cc: Nate Williams , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist Message-ID: <20020122105839.C78733@sunbay.com> References: <15436.42142.53176.44467@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i 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, Jan 21, 2002 at 06:54:02PM -0500, Robert Watson wrote: > On Mon, 21 Jan 2002, Nate Williams wrote: > > > > > Not in this forum. But we're not typical of the user base. I will > > > > continue to use catman, probably making it world writeable, since in my > > > > situation this isn't a compromise. But what about the man in the > > > > street? > > > > > > The difference between the developers and the users is that the users > > > hardly ever change the man pages, and so would probably benefit most from > > > simply using the catman pages in a pregenerated form, rather than having > > > to wait for each page to render the first time they read it, gradually > > > consuming more and more disk space as they read more manpages. > > > > Except that this doesn't allow the 'users' to print out the pages in a > > form that may be more usable by them. > > > > For example, for most manpages, I simply type 'man', but sometimes I > > want to print out the manpage on my printer, so I create a postscript > > file that is formatted better, and prints out much nicer than the > > tradional 'dumb terminal' manpage that is created by default as the > > catpage. > > This doesn't preclude having the nroff sources installed also, I'm just > pointing out that the argument that it's in the user's best interest to > use the man cache mechanism seems a bit bogus to me. The intended goal of > the man cache was presumably to avoid the full disk cost of catman pages, > while attempting also to avoid the cpu cost of processing the page every > time it's viewed. However, in practice it has become a security/space > tradeoff: you sacrifice security to conserve a few megabytes of space in > catman files. I think that the benefit may once have been there, but I > think on modern systems that it's really not there. > > For compatibility purposes, it might be reasonable to install man > non-setuid, but still have the cat pages and directories be installed as > the man user. Then twiddling man to setuid man from bin/bin would still > work for those wanting to enable it. However, for the default install, we > should either rely purely on nroff source, or also install the catman > distribution. > OK, here's what I will do: 1. Restore man.c's SETUID code but do not enable it. 2. Fix SETUID code so that: a) system catpages are created in a pristine environment (/usr/bin/env -i) b) SETUID path is only attempted for system catpages 3. Provide make.conf knob (ENABLE_SUID_MAN) for installing man(1) ``setuid man''. a) will fix the environment race, b) will fix the symlink race. I've already implemented a), and will post a patch here when b) is also implemented. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 2:56: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from straylight.ringlet.net (discworld.nanolink.com [217.75.135.248]) by hub.freebsd.org (Postfix) with SMTP id 6395D37B405 for ; Tue, 22 Jan 2002 02:55:59 -0800 (PST) Received: (qmail 10836 invoked by uid 1000); 22 Jan 2002 10:56:48 -0000 Date: Tue, 22 Jan 2002 12:56:48 +0200 From: Peter Pentchev To: green@FreeBSD.org Cc: re@FreeBSD.org, arch@FreeBSD.ORG Subject: Re: sftp, glob(3) and GLOB_NOMATCH - urgent before 4.5-R! Message-ID: <20020122125648.A1743@straylight.oblivion.bg> Mail-Followup-To: green@FreeBSD.org, re@FreeBSD.org, arch@FreeBSD.ORG References: <20020120224344.A15845@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mheffner@vt.edu on Mon, Jan 21, 2002 at 12:26:03AM -0500 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 OK then; Brian, what do you think of patching the FreeBSD version of OpenSSH for the present? What do the Release Engineers think of MFC'ing this in time for 4.5-RELEASE? G'luck, Peter -- This sentence every third, but it still comprehensible. On Mon, Jan 21, 2002 at 12:26:03AM -0500, Mike Heffner wrote: > Well, IEEE 1003.1-2001 states that glob(3) should return GLOB_NOMATCH, > but, as noticed, this hasn't been implemented in glob(3) yet. IMO, since > we are so close to 4.5R, we should commit the local change in the PR to > OpenSSH and worry about implementing GLOB_NOMATCH (and the other options > that are lacking in glob(3)) after 4.5R. The change in the PR will be > forwards compatible when it comes to implementing GLOB_NOMATCH. In > anycase, the (untested) patch below should be enough to implement > GLOB_NOMATCH. > > On 20-Jan-2002 Peter Pentchev wrote: > | Hi, > | > | In FreeBSD PR 34019, the submitter discusses an sftp core dump when > | a nonexistent file is uploaded. I found out that the same bug > | exists on uploading, and that it is caused by the fact that sftp > | expects glob(3) to error out when no matches are found. I opened > | up an OpenSSH problem report (bug id 73 in the mindrot.org database) > | and soon afterwards, I received the attached reply, which was CC'd > | to our GNATS. > | > | So.. somebody who is acquainted with standards, compatiblity, POLA > | and stuff - how do we go about this? Do we commit the fix in the > | audit trail of PR 34019, thus making another local change to OpenSSH? > | Do we change glob(3)'s behavior to return GLOB_NOMATCH? Or do we ship > | 4.5 with a known bad sftp client? :) I've CC'd Damien Miller (thanks > | for the fast response!) so that the OpenSSH folks are also aware of > | this discussion. > | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 7:48: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 236DC37B41B; Tue, 22 Jan 2002 07:47:34 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id IAA14809; Tue, 22 Jan 2002 08:47:32 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0MFlVJ20763; Tue, 22 Jan 2002 08:47:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15437.35219.698601.837380@caddis.yogotech.com> Date: Tue, 22 Jan 2002 08:47:31 -0700 To: Ruslan Ermilov Cc: Nate Williams , Robert Watson , Greg Lehey , Dan Langille , Joerg Wunsch , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, arch@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist In-Reply-To: <20020122104324.B78733@sunbay.com> References: <20020119105733.A50299@wantadilla.lemis.com> <15436.42142.53176.44467@caddis.yogotech.com> <20020122104324.B78733@sunbay.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > > Not in this forum. But we're not typical of the user base. I will > > > > continue to use catman, probably making it world writeable, since in my > > > > situation this isn't a compromise. But what about the man in the > > > > street? > > > > > > The difference between the developers and the users is that the users > > > hardly ever change the man pages, and so would probably benefit most from > > > simply using the catman pages in a pregenerated form, rather than having > > > to wait for each page to render the first time they read it, gradually > > > consuming more and more disk space as they read more manpages. > > > > Except that this doesn't allow the 'users' to print out the pages in a > > form that may be more usable by them. > > > > For example, for most manpages, I simply type 'man', but sometimes I > > want to print out the manpage on my printer, so I create a postscript > > file that is formatted better, and prints out much nicer than the > > tradional 'dumb terminal' manpage that is created by default as the > > catpage. > > > ``man -t'' should work. Agreed, I was making the point that if we only installed 'catpages', this wouldn't work. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 12: 0:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id E2C2C37B404; Tue, 22 Jan 2002 12:00:27 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020122200027.XKFL3578.rwcrmhc52.attbi.com@InterJet.elischer.org>; Tue, 22 Jan 2002 20:00:27 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA18268; Tue, 22 Jan 2002 11:54:21 -0800 (PST) Date: Tue, 22 Jan 2002 11:54:19 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Cc: dillon@freebsd.org Subject: STOP and SLEEP in the kernel 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 Matt Dillon and I spent some time looking at the way in which process suspension is achieved in FreeBSD in order to try work out how best to do it in the KSE kernel. We discovered a couple of things. FIrstly that teh suspension occurs in CURSIG() which is an alias for issignal() and that CURSIG is called in a number of places, at least one of which seems to us to be a rather dubious place to suspend a process. for example: in cv_switch_catch() cv_wait_sig() msleep() userret() <-this is ok ncp_poll() It seems to us that we need to think carefully about whether suspending a thread in cvwait or msleep is a good idea. ncp_poll() seems a really odd place for a thread to suspend. The difficult part for me in a multithreaded system another thread could call exit() while the thread is stopped there and I need to be able to break it out safely. This means that I need to be able to get it to back out to the user boundary at least, so that I can be sure it's released all resources before I shoot it. Surely a thread can continue within the kernel while the process is stopped as long as it's suspended before it tries to go back to userland. I would suggest that we use a separate check for suspended state, rather than combine it into CURSIG. It would allow a check for signals that would be independent of the worry that the thread would freeze there. PLUS there is in the KSE kernel, now the possibility that a process is suspended in a way completely independent of signals. (this was always the case to some extent as signals really needn't be used for stopping a process for tracing reasons). Signals and suspension are the last major hurdle before I can get a multithreaded process running. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 12:34:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 7CE8C37B404; Tue, 22 Jan 2002 12:34:06 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 5303A10DDF9; Tue, 22 Jan 2002 12:34:06 -0800 (PST) Date: Tue, 22 Jan 2002 12:34:06 -0800 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org, dillon@freebsd.org Subject: Re: STOP and SLEEP in the kernel Message-ID: <20020122123406.D13686@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Tue, Jan 22, 2002 at 11:54:19AM -0800 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 * Julian Elischer [020122 12:00] wrote: > > Matt Dillon and I spent some time looking at the way in which process > suspension is achieved in FreeBSD in order to try work out how best to do > it in the KSE kernel. > > We discovered a couple of things. > FIrstly that teh suspension occurs in CURSIG() which is an alias for > issignal() To deal with these issues it may be a good idea to consider a rundown state in which kses automatically exit right before returning to userland. This should help: thread A calls exit(2). in exit(2) the thread aquires a lock on the proc struct. if the thread count is 1, it just exit(2)s, otherwise: it marks "in exit" in the proc struct. it then signalls all threads with a non blockable signal. (this will cause them to enter the kernel or interrupt any long blocking operation.) it then sleeps on the proc struct's thread count address or a cv. Now all other threads should be in the kernel. They will post a signal to themselves to help them avoid blocking. At exit points they will notice the flag and self terminate themselves, they will decerement the thread count. The second to last thread (the thread other than 'A') will notice the count go to '1' and wakeup the exit(2)'ing thread. Done. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 13: 0:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 2839C37B402; Tue, 22 Jan 2002 13:00:13 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020122210012.VQUU10199.rwcrmhc53.attbi.com@InterJet.elischer.org>; Tue, 22 Jan 2002 21:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA18558; Tue, 22 Jan 2002 12:54:49 -0800 (PST) Date: Tue, 22 Jan 2002 12:54:47 -0800 (PST) From: Julian Elischer To: Alfred Perlstein Cc: arch@freebsd.org, dillon@freebsd.org Subject: Re: STOP and SLEEP in the kernel In-Reply-To: <20020122123406.D13686@elvis.mu.org> 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, 22 Jan 2002, Alfred Perlstein wrote: > * Julian Elischer [020122 12:00] wrote: > > > > Matt Dillon and I spent some time looking at the way in which process > > suspension is achieved in FreeBSD in order to try work out how best to do > > it in the KSE kernel. > > > > We discovered a couple of things. > > FIrstly that teh suspension occurs in CURSIG() which is an alias for > > issignal() > > To deal with these issues it may be a good idea to consider a rundown > state in which kses automatically exit right before returning to userland. > > This should help: This is what is being done (approximatley) However the rundown (exit) state is part of a new state called 'singlethreading' in which case only one thread is allowed to continue while all other threads are suspended or forced to exit, depending on how viscious the single-threader is feeling. For exit() it sets the 'exit' flag but in fork() and exec() it sets the flag to 'suspend'. it is notified when it is the only runnable thread left. userret() is modified to check this state before going back to userland and the threads either call thread_exit() or thread_suspend() depending on the wishes of the master thread. Singlethreading, in turn is part of a larger state called 'suspended' for which all threads must check at strategic locations and act accordingly. This will be set by psignal() in the case of a SIGSTOP and by the TRACE code and also by the singlethreading code. (The check makes the master thread immune to suspending if the singlethreading bit is the only bit set in the suspended flags.) The locations of the checks for suspension have also to take into account that they may need to handle the case of exit() pulling the pin, and causing whatever syscall they are in to abort completely. The safest place for the check is in userret(), but if we wish to fully simulate the current susoension code then we also need to add the checks to issignal() (CURSIG()), or more likely, right next to where CURSIG() is called, and change CURSIG() to not to do the check. SUSPENSION is not limited to signals so CURSIG is not really the right place, though it may be called from all teh right places :-) ALSO there is a whole different STOPPING mechanism in the kernel as well. I refer to the STOPEVENT() stuff, which actually uses msleep() to stop the thread. This needs to be rationalised. We should have only one stopping/suspending mechanism, not 3. > > thread A calls exit(2). > > in exit(2) the thread aquires a lock on the proc struct. > if the thread count is 1, it just exit(2)s, otherwise: > > it marks "in exit" in the proc struct. > it then signalls all threads with a non blockable signal. > (this will cause them to enter the kernel or interrupt any long blocking > operation.) > it then sleeps on the proc struct's thread count address or a cv. been looking at my code huh? :-) > > Now all other threads should be in the kernel. > They will post a signal to themselves to help them avoid blocking. > At exit points they will notice the flag and self terminate themselves, > they will decerement the thread count. > The second to last thread (the thread other than 'A') will notice the > count go to '1' and wakeup the exit(2)'ing thread. > > Done. yep that's what I'm doing... check out the posted diffs. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 15: 8:58 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 9AB9137B400; Tue, 22 Jan 2002 15:08:51 -0800 (PST) Received: from pool0657.cvx21-bradley.dialup.earthlink.net ([209.179.194.147] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16TA26-0007NH-00; Tue, 22 Jan 2002 15:08:50 -0800 Message-ID: <3C4DF0FE.6E9B0D35@mindspring.com> Date: Tue, 22 Jan 2002 15:08:46 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org, dillon@freebsd.org Subject: Re: STOP and SLEEP in the kernel References: 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 Julian Elischer wrote: > It seems to us that we need to think carefully about whether suspending a > thread in cvwait or msleep is a good idea. ncp_poll() seems a really odd > place for a thread to suspend. The difficult part for me in a > multithreaded system another thread could call exit() while the thread is > stopped there and I need to be able to break it out safely. This means > that I need to be able to get it to back out to the user boundary at > least, so that I can be sure it's released all resources before I shoot > it. I believe this is intentional, due to the need to run soft interrupts on a fairly consistant basis. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 16:27:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 4C6F637B405; Tue, 22 Jan 2002 16:27:22 -0800 (PST) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id E994678306; Wed, 23 Jan 2002 10:57:19 +1030 (CST) Date: Wed, 23 Jan 2002 10:57:19 +1030 From: Greg Lehey To: Ruslan Ermilov Cc: Robert Watson , Nate Williams , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/man/man Makefile man.c src/etc/mtree BSD.local.dist BSD.usr.dist BSD.x11-4.dist BSD.x11.dist Message-ID: <20020123105719.J31684@wantadilla.lemis.com> References: <15436.42142.53176.44467@caddis.yogotech.com> <20020122105839.C78733@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020122105839.C78733@sunbay.com> User-Agent: Mutt/1.3.23i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF 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 Tuesday, 22 January 2002 at 10:58:39 +0200, Ruslan Ermilov wrote: > On Mon, Jan 21, 2002 at 06:54:02PM -0500, Robert Watson wrote: >> For compatibility purposes, it might be reasonable to install man >> non-setuid, but still have the cat pages and directories be installed as >> the man user. Then twiddling man to setuid man from bin/bin would still >> work for those wanting to enable it. However, for the default install, we >> should either rely purely on nroff source, or also install the catman >> distribution. >> > OK, here's what I will do: > > 1. Restore man.c's SETUID code but do not enable it. > > 2. Fix SETUID code so that: > > a) system catpages are created in a pristine environment > (/usr/bin/env -i) > > b) SETUID path is only attempted for system catpages > > 3. Provide make.conf knob (ENABLE_SUID_MAN) for installing > man(1) ``setuid man''. > > a) will fix the environment race, b) will fix the symlink race. > I've already implemented a), and will post a patch here when > b) is also implemented. That looks like a good solution. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 19:30:30 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 A028237B405 for ; Tue, 22 Jan 2002 19:30:28 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0N3Tro03179; Tue, 22 Jan 2002 19:29:53 -0800 (PST) (envelope-from dillon) Date: Tue, 22 Jan 2002 19:29:53 -0800 (PST) From: Matthew Dillon Message-Id: <200201230329.g0N3Tro03179@apollo.backplane.com> To: Julian Elischer Cc: Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: STOP and SLEEP in the kernel 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 What really freaks me out is that if t/msleep() is called with PCATCH, it appears to process a STOP signal right then and there and actually stop the process rather then return. t/msleep() is called all over the place with PCATCH while holding vnode and other lockmgr locks so a ^Z at the wrong point could deadlock the system. "That can't be right" I said to myself and to Julian, but neither of us can see where the code might do something else. As far as I can tell the existing -stable and -current code *will* in fact STOP the process while potentially holding (a vnode lock for example). There is a whole lot of code, especially in NFS, that uses PCATCH. It can't be right. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 20:43:17 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 055C937B400 for ; Tue, 22 Jan 2002 20:43:08 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g0N4gCh03552; Tue, 22 Jan 2002 20:42:12 -0800 (PST) (envelope-from dillon) Date: Tue, 22 Jan 2002 20:42:12 -0800 (PST) From: Matthew Dillon Message-Id: <200201230442.g0N4gCh03552@apollo.backplane.com> To: Alfred Perlstein , Julian Elischer Cc: arch@freebsd.org, Bruce Evans , David Greenman Subject: PCATCH vs signal(SIGSTOP) (was Re: STOP and SLEEP in the kernel) References: <200201230329.g0N3Tro03179@apollo.backplane.com> <20020122203517.I13686@elvis.mu.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 [020122 19:30] wrote: :> What really freaks me out is that if t/msleep() is called with PCATCH, :> it appears to process a STOP signal right then and there and actually :> stop the process rather then return. t/msleep() is called all over the :> place with PCATCH while holding vnode and other lockmgr locks so a ^Z :> at the wrong point could deadlock the system. :> :> "That can't be right" I said to myself and to Julian, but neither of us :> can see where the code might do something else. As far as I can tell the :> existing -stable and -current code *will* in fact STOP the process :> while potentially holding (a vnode lock for example). There is a whole :> lot of code, especially in NFS, that uses PCATCH. It can't be right. : :*ARRRRRRGH* : :Obviously STOP signals should only be honoured in userret and signal :entry points. Any chance for a fix? : :-- :-Alfred Perlstein [alfred@freebsd.org] I'm still not sure it even happens, but I can't find any code to prevent it. I would like somebody whos played with the signal code before, like BDE or DG, to take a look at the STOP/PCATCH handling. For those I've just added to the CC: Julian and I were looking at the STOP signal handling code and it appears that a tsleep()/msleep() called with PCATCH can cause the process to go into a STOPped state if it is signaled at just that moment, leaving held locks in place and potentially deadlocking the system. There is a whole lot of code in the kernel that uses PCATCH and assumes that tsleep()/msleep() will return when a signal occurs rather then the process being stopped. If it is indeed hapenning the way I fear, the fix should be easy. The question is... is it hapenning the way I fear? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 22 21:20:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 36C8737B400 for ; Tue, 22 Jan 2002 21:20:11 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020123052010.QMJV3578.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 23 Jan 2002 05:20:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA20434; Tue, 22 Jan 2002 21:10:20 -0800 (PST) Date: Tue, 22 Jan 2002 21:10:19 -0800 (PST) From: Julian Elischer To: Matthew Dillon Cc: Alfred Perlstein , arch@freebsd.org, Bruce Evans , David Greenman Subject: Re: PCATCH vs signal(SIGSTOP) (was Re: STOP and SLEEP in the kernel) In-Reply-To: <200201230442.g0N4gCh03552@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, 22 Jan 2002, Matthew Dillon wrote: > > : > :* Matthew Dillon [020122 19:30] wrote: > :> What really freaks me out is that if t/msleep() is called with PCATCH, > :> it appears to process a STOP signal right then and there and actually > :> stop the process rather then return. t/msleep() is called all over the > :> place with PCATCH while holding vnode and other lockmgr locks so a ^Z > :> at the wrong point could deadlock the system. > :> > :> "That can't be right" I said to myself and to Julian, but neither of us > :> can see where the code might do something else. As far as I can tell the > :> existing -stable and -current code *will* in fact STOP the process > :> while potentially holding (a vnode lock for example). There is a whole > :> lot of code, especially in NFS, that uses PCATCH. It can't be right. > : > :*ARRRRRRGH* > : > :Obviously STOP signals should only be honoured in userret and signal > :entry points. Any chance for a fix? > : > :-- > :-Alfred Perlstein [alfred@freebsd.org] > What I've done in the KSE code is to remove the mi_switch etc from issignal() and add a separate function in userret() that checks for a STOPPED condition on the process and does the mi_switch() then. It seems to work but I seem to have screwed up the restarting code.. :-) I'll hopefully have that fixed tonight. > I'm still not sure it even happens, but I can't find any code to > prevent it. > > I would like somebody whos played with the signal code before, like > BDE or DG, to take a look at the STOP/PCATCH handling. > > For those I've just added to the CC: Julian and I were looking at > the STOP signal handling code and it appears that a tsleep()/msleep() > called with PCATCH can cause the process to go into a STOPped state if > it is signaled at just that moment, leaving held locks in place and > potentially deadlocking the system. There is a whole lot of code in > the kernel that uses PCATCH and assumes that tsleep()/msleep() will > return when a signal occurs rather then the process being stopped. > > If it is indeed hapenning the way I fear, the fix should be easy. The > question is... is it hapenning the way I fear? I think it is happenning but most of the time it is benign because most log term sleeps (that are likely to be hit by ^Z) do not hold a lot of resources across the sleep because they are aware that they may be sleeping or a long while. Certainly they are not holding locked items, just references on vnodes etc. I think it happens but is not as bad as our initial gut reaction felt. > > -Matt > > > 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 Wed Jan 23 5:18:33 2002 Delivered-To: freebsd-arch@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id AE60637B400; Wed, 23 Jan 2002 05:18:22 -0800 (PST) Received: from netch@localhost (netch@localhost) by burka.carrier.kiev.ua id PHA46547; Wed, 23 Jan 2002 15:18:16 +0200 (EET) (envelope-from netch) Date: Wed, 23 Jan 2002 15:18:16 +0200 From: Valentin Nechayev To: Gregory Neil Shapiro Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG, anders@fix.no Subject: Re: New sendmail users (was Re: HEADS UP: Apache port change from nobody:nogroup to www:www planned) Message-ID: <20020123131816.GA43706@lucky.net> Reply-To: netch@lucky.net References: <29611.1003411145@axl.seasidesoftware.co.za> <15311.1383.814782.672622@horsey.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15311.1383.814782.672622@horsey.gshapiro.net> X-42: On 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 Thu, Oct 18, 2001 at 09:37:59, gshapiro wrote about "New sendmail users (was Re: HEADS UP: Apache port change from nobody:nogroup to www:www planned)": > Index: master.passwd > =================================================================== > RCS file: /src/FreeBSD/cvsrepo/src/etc/master.passwd,v > retrieving revision 1.25 > diff -u -r1.25 master.passwd > --- master.passwd 1999/09/13 17:09:07 1.25 > +++ master.passwd 2001/10/18 16:31:44 > @@ -10,6 +10,8 @@ > games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin > news:*:8:8::0:0:News Subsystem:/:/sbin/nologin > man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin > +smmsp:*:25:25:Sendmail Submission User:/var/spool/clientmqueue:/sbin/nologin > +mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/sbin/nologin This breaks majordomo from current port. For secure install, majordomo wrapper is allowed to be run only for majordomo user and group, and port installer adds user=daemon to this group. Today I had to diagnose a host which was updated to 4.5-rc2; addition of mailnull user broke it because sendmail prefers mailnull to daemon when running pipes from root-owned aliases and forwards. The port's maintainer is already notified, but new port revision can't help for already installed ones. Another place where this will break some things (and I know it will really happen for a bunch of my controlled hosts) are direction to files from root-owned aliases/forwards/includes. Now some of these files are owned by daemon, and explicit action is required to update their owner. I suppose that adding of mailnull user and group should be explicitly mentioned in src/UPDATING, with advices for both mentioned cases (majordomo & files). /netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 8: 3:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 3495A37B404; Wed, 23 Jan 2002 08:03:07 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA16605; Wed, 23 Jan 2002 11:03:06 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g0NG2aZ55948; Wed, 23 Jan 2002 11:02:36 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15438.56988.569944.942146@grasshopper.cs.duke.edu> Date: Wed, 23 Jan 2002 11:02:36 -0500 (EST) To: freebsd-arch@FreeBSD.org Cc: luigi@FreeBSD.org Subject: noisy ethernet drivers (was Re: 4.5-RC2 kernel, m_clalloc failed) In-Reply-To: <1011797933.75400.19.camel@elmer.i.eunet.no> References: <1011797933.75400.19.camel@elmer.i.eunet.no> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Lars Erik Gullerud writes: > > Jan 23 14:34:41 disrv01 /kernel: m_clalloc failed, consider increase > NMBCLUSTERS value > Jan 23 14:34:41 disrv01 /kernel: fxp0: cluster allocation failed, packet > dropped! > Jan 23 14:34:42 disrv01 last message repeated 850 times Speaking of this, now that we have rate-limited reporting in uipc_mbuf.c, can we PLEASE axe the printfs in the individual drivers? The way it stands now, once you run out of mbuf clusters on a machine w/a serial console, you can just about forget about ever getting into it again without power-cycling it. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 8:53:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 9C6A537B405; Wed, 23 Jan 2002 08:53:30 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.2/8.12.2) with ESMTP id g0NGrCUa066584 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Jan 2002 08:53:13 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.2/8.12.2/Submit) id g0NGrBPe066577; Wed, 23 Jan 2002 08:53:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15438.60023.705225.44960@horsey.gshapiro.net> Date: Wed, 23 Jan 2002 08:53:11 -0800 From: Gregory Neil Shapiro To: netch@lucky.net Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG, anders@fix.no, imp@FreeBSD.ORG Subject: Re: New sendmail users (was Re: HEADS UP: Apache port change from nobody:nogroup to www:www planned) In-Reply-To: <20020123131816.GA43706@lucky.net> References: <29611.1003411145@axl.seasidesoftware.co.za> <15311.1383.814782.672622@horsey.gshapiro.net> <20020123131816.GA43706@lucky.net> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid 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 >> +mailnull:*:26:26:Sendmail Default User:/var/spool/mqueue:/sbin/nologin netch> This breaks majordomo from current port. For secure install, netch> majordomo wrapper is allowed to be run only for majordomo user and netch> group, and port installer adds user=daemon to this group. Today I netch> had to diagnose a host which was updated to 4.5-rc2; addition of netch> mailnull user broke it because sendmail prefers mailnull to daemon netch> when running pipes from root-owned aliases and forwards. netch> The port's maintainer is already notified, but new port revision netch> can't help for already installed ones. netch> Another place where this will break some things (and I know it will netch> really happen for a bunch of my controlled hosts) are direction to netch> files from root-owned aliases/forwards/includes. Now some of these netch> files are owned by daemon, and explicit action is required to update netch> their owner. netch> I suppose that adding of mailnull user and group should be explicitly netch> mentioned in src/UPDATING, with advices for both mentioned cases netch> (majordomo & files). (Note I've quoted the entire message and CC'ed Warner in case he does want to add something to UPDATING on both the HEAD and RELENG_4.) If you still want sendmail to use daemon for the default user, simply add this to your .mc file: define(`confDEF_USER_ID', `daemon') However, migrating to mailnull will increase system security. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 9: 2:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from prism.flugsvamp.com (66-188-92-95.mad.wi.charter.com [66.188.92.95]) by hub.freebsd.org (Postfix) with ESMTP id 0778237B402; Wed, 23 Jan 2002 09:02:15 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g0NGw6H19753; Wed, 23 Jan 2002 10:58:06 -0600 (CST) (envelope-from jlemon) Date: Wed, 23 Jan 2002 10:58:06 -0600 From: Jonathan Lemon To: Andrew Gallatin Cc: freebsd-arch@FreeBSD.ORG, luigi@FreeBSD.ORG Subject: Re: noisy ethernet drivers (was Re: 4.5-RC2 kernel, m_clalloc failed) Message-ID: <20020123105806.F59128@prism.flugsvamp.com> References: <1011797933.75400.19.camel@elmer.i.eunet.no> <15438.56988.569944.942146@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <15438.56988.569944.942146@grasshopper.cs.duke.edu> 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, Jan 23, 2002 at 11:02:36AM -0500, Andrew Gallatin wrote: > > Lars Erik Gullerud writes: > > > > Jan 23 14:34:41 disrv01 /kernel: m_clalloc failed, consider increase > > NMBCLUSTERS value > > Jan 23 14:34:41 disrv01 /kernel: fxp0: cluster allocation failed, packet > > dropped! > > Jan 23 14:34:42 disrv01 last message repeated 850 times > > Speaking of this, now that we have rate-limited reporting in > uipc_mbuf.c, can we PLEASE axe the printfs in the individual drivers? I thought that luigi did that already when he put the centralized rate-limiting code in? -- Joanthan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 9:19:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 877AD37B416 for ; Wed, 23 Jan 2002 09:19:37 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.3/8.11.3) id g0NHJZD60023; Wed, 23 Jan 2002 09:19:35 -0800 (PST) (envelope-from rizzo) Date: Wed, 23 Jan 2002 09:19:35 -0800 From: Luigi Rizzo To: Jonathan Lemon Cc: Andrew Gallatin , freebsd-arch@FreeBSD.ORG Subject: Re: noisy ethernet drivers (was Re: 4.5-RC2 kernel, m_clalloc failed) Message-ID: <20020123091935.A59705@iguana.icir.org> References: <1011797933.75400.19.camel@elmer.i.eunet.no> <15438.56988.569944.942146@grasshopper.cs.duke.edu> <20020123105806.F59128@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020123105806.F59128@prism.flugsvamp.com> User-Agent: Mutt/1.3.23i 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 > > > Jan 23 14:34:42 disrv01 last message repeated 850 times > > > > Speaking of this, now that we have rate-limited reporting in > > uipc_mbuf.c, can we PLEASE axe the printfs in the individual drivers? > > I thought that luigi did that already when he put the centralized > rate-limiting code in? That was the intention, but i did not sweep through the individual devices, I got sidetracked by other things... If the release engineer agree, the change is pretty trivial, but i think now it is better to wait right after the release. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 9:21:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id DF52037B405; Wed, 23 Jan 2002 09:21:19 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA19386; Wed, 23 Jan 2002 12:21:19 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g0NHKng56150; Wed, 23 Jan 2002 12:20:49 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15438.61680.931767.691683@grasshopper.cs.duke.edu> Date: Wed, 23 Jan 2002 12:20:48 -0500 (EST) To: Jonathan Lemon Cc: freebsd-arch@FreeBSD.ORG, luigi@FreeBSD.ORG Subject: Re: noisy ethernet drivers (was Re: 4.5-RC2 kernel, m_clalloc failed) In-Reply-To: <20020123105806.F59128@prism.flugsvamp.com> References: <1011797933.75400.19.camel@elmer.i.eunet.no> <15438.56988.569944.942146@grasshopper.cs.duke.edu> <20020123105806.F59128@prism.flugsvamp.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Jonathan Lemon writes: > I thought that luigi did that already when he put the centralized > rate-limiting code in? That's sort of what I was getting at. On Dec 16th, this was done: luigi 2001/12/16 07:46:08 PST Modified files: (Branch: RELENG_4) sys/pci if_pcn.c if_rl.c if_sf.c if_sk.c if_ste.c if_ti.c if_tl.c if_vr.c if_wb.c Log: MFC: Remove printf's on mbuf/cluster allocation failures. There are now equivalent and less dangerous (rate limited) messages in the mbuf allocation code. But it looks like there are still printfs in some of the more popular drivers (fxp, xl, more??). Anybody know why those were omitted? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 9:31:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 5A19D37B402; Wed, 23 Jan 2002 09:31:25 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020123173125.ZBAA10199.rwcrmhc53.attbi.com@bmah.dyndns.org>; Wed, 23 Jan 2002 17:31:25 +0000 Received: (from bmah@localhost) by bmah.dyndns.org (8.11.6/8.11.6) id g0NHVO085022; Wed, 23 Jan 2002 09:31:24 -0800 (PST) (envelope-from bmah) Message-Id: <200201231731.g0NHVO085022@bmah.dyndns.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Gregory Neil Shapiro Cc: netch@lucky.net, arch@FreeBSD.ORG, stable@FreeBSD.ORG, anders@fix.no, imp@FreeBSD.ORG Subject: Re: New sendmail users (was Re: HEADS UP: Apache port change from nobody:nogroup to www:www planned) In-reply-to: <15438.60023.705225.44960@horsey.gshapiro.net> References: <29611.1003411145@axl.seasidesoftware.co.za> <15311.1383.814782.672622@horsey.gshapiro.net> <20020123131816.GA43706@lucky.net> <15438.60023.705225.44960@horsey.gshapiro.net> Comments: In-reply-to Gregory Neil Shapiro message dated "Wed, 23 Jan 2002 08:53:11 -0800." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jan 2002 09:31:24 -0800 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 If memory serves me right, Gregory Neil Shapiro wrote: > (Note I've quoted the entire message and CC'ed Warner in case he does want > to add something to UPDATING on both the HEAD and RELENG_4.) Errr. This sounds like a relnotes thing too...guess I ought to think (quickly) about this. Just so I have this straight, this problem came about because of the change to master.passwd, not because of any code change in sendmail (which, if I read my relnotes right, hasn't changed between 4.4-RELEASE and 4.5-RC). Right? > If you still want sendmail to use daemon for the default user, simply add > this to your .mc file: > > define(`confDEF_USER_ID', `daemon') > > However, migrating to mailnull will increase system security. Is this because there are fewer processes running as daemon? Bruce. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 9:33:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by hub.freebsd.org (Postfix) with ESMTP id 124CB37B417; Wed, 23 Jan 2002 09:33:35 -0800 (PST) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.2/8.12.2) with ESMTP id g0NHXWUa071173 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Jan 2002 09:33:32 -0800 (PST) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.2/8.12.2/Submit) id g0NHXWjN071170; Wed, 23 Jan 2002 09:33:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15438.62444.300546.808256@horsey.gshapiro.net> Date: Wed, 23 Jan 2002 09:33:32 -0800 From: Gregory Neil Shapiro To: bmah@FreeBSD.ORG Cc: netch@lucky.net, arch@FreeBSD.ORG, stable@FreeBSD.ORG, anders@fix.no, imp@FreeBSD.ORG Subject: Re: New sendmail users (was Re: HEADS UP: Apache port change from nobody:nogroup to www:www planned) In-Reply-To: <200201231731.g0NHVO085022@bmah.dyndns.org> References: <29611.1003411145@axl.seasidesoftware.co.za> <15311.1383.814782.672622@horsey.gshapiro.net> <20020123131816.GA43706@lucky.net> <15438.60023.705225.44960@horsey.gshapiro.net> <200201231731.g0NHVO085022@bmah.dyndns.org> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid 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 bmah> Errr. This sounds like a relnotes thing too...guess I ought to bmah> think (quickly) about this. bmah> Just so I have this straight, this problem came about because of the bmah> change to master.passwd, not because of any code change in sendmail bmah> (which, if I read my relnotes right, hasn't changed between 4.4-RELEASE bmah> and 4.5-RC). Right? Correct. sendmail uses mailnull if the account exists so when the account was created, it started using it. >> If you still want sendmail to use daemon for the default user, simply add >> this to your .mc file: >> >> define(`confDEF_USER_ID', `daemon') >> >> However, migrating to mailnull will increase system security. bmah> Is this because there are fewer processes running as daemon? No, it is because other processes run as daemon. The sendmail DefaultUser should not be used by anything else. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 16:18:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f88.law9.hotmail.com [64.4.9.88]) by hub.freebsd.org (Postfix) with ESMTP id 950AE37B402 for ; Wed, 23 Jan 2002 16:18:07 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 23 Jan 2002 16:18:07 -0800 Received: from 207.46.137.9 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 24 Jan 2002 00:18:02 GMT X-Originating-IP: [207.46.137.9] From: "Nathan Arun" To: arch@freebsd.org Subject: a suggestion Date: Thu, 24 Jan 2002 00:18:02 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jan 2002 00:18:07.0566 (UTC) FILETIME=[992226E0:01C1A46C] 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 FreeBSD developers, I sent an e-mail to freebsd core team. Mr. Warner Losh suggested I should sent that e-mail to this arch list. So here it is. thanks Nathan ----------------------------------------------------------------------- To FreeBSD Core Team: Hi Everyone, I'm a software engineer whose experience is primarily on Windows though I have used UNIX a little bit. Recently I tried to install FreeBSD 4.4 in one of the old P133 boxes I had. Installation was not difficult. I was able to get it running. Though I have to say, UNIX is intimidating to windows users. My intention is to set up a site with php and mysql. May I dare suggest a cosmetic change to FreeBSD? Please set aside your contempt for a windows programmer and objectively assess my e-mail. Section 3.3 of the handbook outlines the directory structure. How about changing the structure to something akin to windows? Say /sys --> all system binaries, scripts that now reside in /bin, /sbin, /usr/bin,/usr/sbin, /boot, /etc, including KERNEL, gcc, ... will reside here. In addition /sys will have the following sub-directories: /sys/mnt --> mount point (if necessary) /sys/conf --> conf file location for binaries in /sys /sys/dev --> all device nodes /sys/log --> log file location for binaries in /sys /sys/src --> source code for the binaries in /sys /sys/include, /sys/lib --> C/C++ sdk /sys/man --> man pages for binaries in /sys /apps --> all applications. for e.g. /apps can have /apps/apache --> application binaries /apps/apache/log /apps/apache/conf /apps/apache/src /apps/apache/man /apps/samba --> application binaries /apps/samba/log /apps/samba/conf /apps/samba/src /apps/samba/man /apps/X11R6 /apps/src --> source code of all the ports (6000+). /usr --> all user directories. for e.g. /usr can have /usr/root /usr/root/.cshrc /usr/sysadmin /usr/postgresql /usr/johndoe Other miscellaneous files that are currently under /usr/local, /usr/share, /var can be moved under one of the above. So there will be only 4 file systems: /, /sys, /apps, /usr. What I have suggested is an exact copy of Windows' "Winnt", "Program Files" and "Documents and Settings" directories. But what's wrong in being easy and clear? This structure is more logical. I'm suggesting this because it is confusing to have so many bin & sbin directories. This may sound trivial to experienced UNIX users like you, but if you want to grow your user base, you should target the OS at more naive developers like me. Many developers feel that windows is easy and want to try something more challenging, but UNIX is too difficult. These difficulties in turn become a "SIGNIFICANT BARRIER TO ADOPTION". UNIX community steadfastly refused to improve usability on the desktop and Microsoft laughed it's way to the bank. I'm afraid the same thing is going to happen on the server side as well. My good luck to you in all your efforts. Thank you for reading this far. Hope I have'nt offended anyone. Nathan Arun ----------------------------------------------------------------------- _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 16:38: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 1364937B404; Wed, 23 Jan 2002 16:38:05 -0800 (PST) Received: from pool0159.cvx40-bradley.dialup.earthlink.net ([216.244.42.159] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16TXu0-0004dK-00; Wed, 23 Jan 2002 16:38:04 -0800 Message-ID: <3C4F5767.1B19D5BC@mindspring.com> Date: Wed, 23 Jan 2002 16:37:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Neil Shapiro Cc: bmah@FreeBSD.ORG, netch@lucky.net, arch@FreeBSD.ORG, stable@FreeBSD.ORG, anders@fix.no, imp@FreeBSD.ORG Subject: Re: New sendmail users (was Re: HEADS UP: Apache port change from nobody:nogroup to www:www planned) References: <29611.1003411145@axl.seasidesoftware.co.za> <15311.1383.814782.672622@horsey.gshapiro.net> <20020123131816.GA43706@lucky.net> <15438.60023.705225.44960@horsey.gshapiro.net> <200201231731.g0NHVO085022@bmah.dyndns.org> <15438.62444.300546.808256@horsey.gshapiro.net> 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 Gregory Neil Shapiro wrote: For what it's worth, I think that the user: smmsp Sendmail Mail Submission Protocol should be changed to: mspd Mail Submission Protocol Daemon to be agnostic to the program using it. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 23 17:58:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 0CF8E37B41A for ; Wed, 23 Jan 2002 17:58:06 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C461D10DE00; Wed, 23 Jan 2002 17:58:05 -0800 (PST) Date: Wed, 23 Jan 2002 17:58:05 -0800 From: Alfred Perlstein To: Nathan Arun Cc: arch@freebsd.org Subject: Re: a suggestion Message-ID: <20020123175805.M13686@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nathan_arun@hotmail.com on Thu, Jan 24, 2002 at 12:18:02AM +0000 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 Arun [020123 16:18] wrote: > Hello FreeBSD developers, > I sent an e-mail to freebsd core team. Mr. Warner Losh suggested I should > sent that e-mail to this arch list. > > So here it is. Talk to the signature. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 0: 1: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 ED25E37B41B for ; Thu, 24 Jan 2002 00:01:54 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 6C84E532C; Thu, 24 Jan 2002 09:01:53 +0100 (CET) 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: "Nathan Arun" Cc: arch@freebsd.org Subject: Re: a suggestion References: From: Dag-Erling Smorgrav Date: 24 Jan 2002 09:01:52 +0100 In-Reply-To: Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 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 "Nathan Arun" writes: > Section 3.3 of the handbook outlines the directory structure. How about > changing the structure to something akin to windows? If you want Windows, you know where to find it. 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 Thu Jan 24 0:52:20 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 03E1037B404 for ; Thu, 24 Jan 2002 00:52:19 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 34DAA532C; Thu, 24 Jan 2002 09:52:17 +0100 (CET) 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: arch@freebsd.org Subject: Nit in wait(2) man page? From: Dag-Erling Smorgrav Date: 24 Jan 2002 09:52:16 +0100 Message-ID: Lines: 10 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 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 The wait(2) man page says: [EINTR] The call was interrupted by a caught signal, or the signal did not have the SA_RESTART flag set. Should this be s/or/and/? 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 Thu Jan 24 1: 0:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 75B9337B41A for ; Thu, 24 Jan 2002 01:00:10 -0800 (PST) Received: from pool0373.cvx22-bradley.dialup.earthlink.net ([209.179.199.118] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Tfjs-0004Yw-00; Thu, 24 Jan 2002 01:00:08 -0800 Message-ID: <3C4FCD14.E6F278BE@mindspring.com> Date: Thu, 24 Jan 2002 01:00:04 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Arun Cc: arch@freebsd.org Subject: Re: a suggestion References: 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 Nathan Arun wrote: > > Hello FreeBSD developers, > I sent an e-mail to freebsd core team. Mr. Warner Losh suggested I should > sent that e-mail to this arch list. > > So here it is. [ ... change layout of disk to resemble Windows ... ] The problem with this is that both layouts are wrong. The Windows layout is wrong because it assumes that programs will install libraries and other software into system controlled directories. The UNIX layout is wrong because it assumes that things will be installed into /usr/local. While it's nice that UNIX has at least made it possible to tell the difference between pieces of the OS, and the software you install on top of the OS, by the location where it is installed, ideally, applciations would be autonomous resources. This basically means that you would be able to get them out of the file space from a subhierarchy, and not care if the location of the files was on the local system, a remote system, or a CDROM. The problem with the Windows approach (aside from the inherent succeptibility to exploits and the confusion of what is application and what is system) is that the version of what's installed is not installation specific (this could be corrected on Windows, if they had hard links available in the FS -- they've only very recently "invented" symbolic links) so that each program could bring in the version of the DLLs and other file dependencies it cares about. The UNIX approach is much closer to the ideal, but could benefit from the idea of a "default user". Windows XP moves closer to the ideal, but from the wrong direction, by providing "personal views" on things. Like "themes", the main effect of a "persona view" is that technical support becomes an order of magnitude harder, since there are much fewer common points of reference between the person providing the support, and the person needing the support (in information theory, a common point of reference is called a "Schelling Point"; an old example is the file "README.TXT", and a more or less modern one is the file "LICENSE"). > I'm suggesting this because it is confusing to have so many bin & sbin > directories. This may sound trivial to experienced UNIX users like you, but > if you want to grow your user base, you should target the OS at more naive > developers like me. Many developers feel that windows is easy > and want to try something more challenging, but UNIX is too difficult. > > These difficulties in turn become a "SIGNIFICANT BARRIER TO ADOPTION". I claim that this is based on the false premise that the average user would be looking around for, or even care where, files are located. The user cares whether or not the programs on the system work, and could really care less about whether or not the command they are accessing is in "/sbin", "/bin", "/usr/sbin", "/usr/bin", "/usr/local/sbin", "/usr/local/bin", "/usr/X11R6/bin", etc.. Finding the program is the job of the shell or file manager or desktop shortcut, not the job of the user, and it only becomes a problem when it's not where it can be found by that software. Windows hides this using the "installed image" concept, which originally came from VMS and its predecessors TOPS-20, TOPS-10, etc.. The programs are "known" because they are referenced by an installed image name vs. real path pair in the registry, or if they are user supplied, in the shortcut (e.g. moving an executable directory to a different name and clicking on the shortcut results in an automatic "search" operation that finds the moved program, and offers to permanently change the shortcut). > UNIX community steadfastly refused to improve usability on the desktop and > Microsoft laughed it's way to the bank. This is certainly true. But I place the blame at the feet of Novell. I once asked a Novell executive, at the preannouncement meeting for the employees (to see how it would sell) where they "deemphasized UNIX on the desktop", "If users aren't going to run UnixWare on their desktops, what _Novell_ OS *are* they going to run instead?". The answer was "Microsoft Windows", and that executive left Novell to pursue other opportunities after making that response. > I'm afraid the same thing is going > to happen on the server side as well. Unlikely. Server software has different human factors requirements (mostly because it's used by "different" humans 8-) 8-)). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 1: 6:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id C9FDD37B404 for ; Thu, 24 Jan 2002 01:06:37 -0800 (PST) Received: from pool0373.cvx22-bradley.dialup.earthlink.net ([209.179.199.118] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16Tfq7-0007bG-00; Thu, 24 Jan 2002 01:06:36 -0800 Message-ID: <3C4FCE98.2C0BE57E@mindspring.com> Date: Thu, 24 Jan 2002 01:06:32 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: Nit in wait(2) man page? References: 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 Dag-Erling Smorgrav wrote: > The wait(2) man page says: > > [EINTR] The call was interrupted by a caught signal, or the > signal did not have the SA_RESTART flag set. > > Should this be s/or/and/? Yes. Interrupted system calls do not return error codes if the restart flag is set, they are restarted, instead. I think you may need to be careful here, though, based on the interaction with threads. I'm not sure how the wrapped system calls find themselves restarted, if they are interrupted by a signal handler. In tehory, this should be transparent, but in practice, there is a heck of a lot of voodoo in the wrapper code to deal with masks and stuff, mostly to deal with the fact that system call restart is no longer the default behaviour, thanks to POSIX. The historical interface was to always restart system calls unless siginterrupt(2) has been called, and prior to the siginterrupt(2) being introduces (ULTRIX 4.1), the only way a signal could interrupt a system call was as a result of a longjmp(3) out of the signal handler, with a corresponding setjmp(3) before the system call. All in all, this was a much more UNIX-like behaviour (complex behaviour emergent from a small set of not-so-complex building blocks). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 2: 0:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 7A4C737B404 for ; Thu, 24 Jan 2002 02:00:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020124100007.JCFW26243.rwcrmhc51.attbi.com@InterJet.elischer.org> for ; Thu, 24 Jan 2002 10:00:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA26277 for ; Thu, 24 Jan 2002 01:41:23 -0800 (PST) Date: Thu, 24 Jan 2002 01:41:22 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: simple KSE test program 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 Several people have asked how a KSE program would look. Here is a program I am writing for testing KSEs: I hope to be using it within a day or two. it includes 2 new syscalls (kse_new() and kse_yield()). One function not yet written is the function loadthread() which reads the registers in from the saved context in a user_thread structure, in a similar way to how longjmp() does, but with more to load. I need to add that in a .s file. First I include the kse include file: #ifndef SYS_KSE_H #define SYS_KSE_H /* * This file defines the structures needed for communication between * the userland and the kernel when running a KSE-based threading system. * The only programs that should see this file are the UTS and the kernel. */ /* * Each userland thread has one of these buried in it's * Thread control structure somewhere. */ struct thread_mailbox { struct thread_mailbox *next_completed; unsigned int flags; void *UTS_handle; /* UTS can use this for anything */ mcontext_t ctx; /* thread's saved context goes here. */ /* The ctx field will become a union of types trapframe and mcontext_t aligned accordingly. */ }; /* * You need to supply one of these as the argument to the * kse_new() system call. */ struct kse_mailbox { struct thread_mailbox *current_thread; struct thread_mailbox *completed_threads; unsigned int flags; void *UTS_handle; /* The UTS can use this for anything */ }; #define KEMBXF_CRITICAL 0x00000001 struct kse_global_mailbox { unsigned int flags; }; #define GMBXF_CRITICAL 0x00000001 /* some provisional sycalls: */ int kse_new(struct kse_mailbox *mbx, int new_grp_flag); int kse_exit(void); /* last will clear KSE mode */ int thread_wakeup(struct thread_mailbox *tmbx); /* make it complete */ int kse_wakeup(void); /* wake any idle KSEs */ void kse_yield(void); /* this kse can become idle */ --------------------------------------------------------------- and here is the program. Only the last 4 functions should be in the program itself. All the rest make up the basis of what would be in a library. In fact some of what is done in main() might even be abstracted too. I hope to be testing this within a couple of days (given a few cleanups and loose-ends to fix) ---------- #include #include #include #include /************************************************************* * These should probably be in a .h file **************************************************************/ typedef void thread_fn(void *arg); struct user_thread { struct thread_mailbox mbox; char *stack; int stack_size; struct user_thread *runq_next; }; struct per_kse { struct kse_mailbox *mbox; struct user_thread *curthread }; /************************************************************* * Debug stuff **************************************************************/ #if 0 jmp_buf jb3; #define DUMPREGS(desc) do {_setjmp(jb3); printjb(jb3, desc); } while (0) char *regname[] = {"%eip","%ebx","%esp","%ebp", "%esi","%edi","fpcr","MSK0", "MSK1","MSK2","MSK3"}; static printjb(struct _jmp_buf *jb, char *desc) { int i; printf("jb (%s) is at 0x%x\n", desc, jb); for( i = 0; i< _JBLEN-4; i++) { printf("jb[%d] (%s) = 0x%x\n", i, regname[i], jb[0]._jb[i]); } } #endif /************************************************************* * Globals **************************************************************/ struct per_kse first_kse; /* for NOW cheat and make it global */ struct user_thread *runqueue; struct user_thread **runq_last; /************************************************************* * Implementation parameters **************************************************************/ #define T_STACKSIZE (16*4096) /* thread stacksize */ #define K_STACKSIZE (1*4096) /* KSE (UTS) stacksize */ /************************************************************* * UTS funcions. * Simple round_robin for now. **************************************************************/ static void runq_insert(struct user_thread *thread) { thread->runq_next = NULL; *runq_last = thread; runq_last = &thread->runq_next; } static struct user_thread * select_thread(void) { struct user_thread *thread; if ((thread = runqueue)) { if ((runqueue = thread->runq_next) == NULL) { runq_last = &runqueue; } } return (thread); } /************************************************************* * The UTS upcall entrypoint * Called once on startup (and left by longjump) * and there-after, returned to by the upcall many times. **************************************************************/ static void UTS(struct _jmp_buf *jb1, struct per_kse *ksedata, int newgroup) { struct kse_mailbox ke_mbox; struct user_thread *thread; struct thread_mailbox *completed; /* Let the caller know where our mailbox is */ ksedata->mbox = &ke_mbox; ke_mbox.UTS_handle = ksedata; if (kse_new(&ke_mbox, newgroup)) { /* initial call returns */ _longjmp(jb1, 1); /* go back to caller's stack and caller */ /* NOTREACHED */ } /**********************************/ /* UTS upcall starts running here. */ /**********************************/ /**********************************/ printf("we are in the UTS with mailbox at 0x%x\n", &ke_mbox); /* If there are returned syscall threads, put them on the run queue */ if ((completed = ke_mbox.completed_threads)) { ke_mbox.completed_threads = NULL; while (completed) { thread = completed->UTS_handle; completed = completed->next_completed; runq_insert(thread); } } /* find highest priority thread and load it */ if ((thread = select_thread())) { ksedata->curthread = thread; ke_mbox.current_thread = &thread->mbox; loadthread(thread) /* loads context similar to longjmp() */ /* NOTREACHED */ } kse_yeild(); /* in the kernel it does a thread_exit() */ /* NOTREACHED */ } /************************************************************* * Startup mechanism functions **************************************************************/ static int; kickkse(struct per_kse *ksedata, int newgroup) { char * newstack; jmp_buf jb1; jmp_buf jb2; struct kse_mailbox *mboxaddr; int i; newstack = malloc(K_STACKSIZE); printf("newstack is at 0x%x-0x%x\n", newstack, newstack + K_STACKSIZE); if (_setjmp(jb1) == 0) { if (_setjmp(jb2) == 0) { jb2[0]._jb[2] = &newstack[K_STACKSIZE - 16]; _longjmp(jb2, 1); } /* running with a different SP */ { /* Get all the rest set up. */ UTS(&jb1[0], ksedata, newgroup); /* NOTREACHED */ } } return(1); } static struct kse_mailbox * startkse(struct per_kse *ksedata) { return (kickkse(ksedata, 0)); } static struct kse_mailbox * startksegrp(struct per_kse *ksedata); { return(kickkse(ksedata, 1)); } void badreturn() { printf("thread returned when shouldn't\n"); exit(1); } __inline__ void pushontostack(struct user_thread *tcb, int value) { int *SP; SP = (int *)(tcb->mbox.ctx.trapframe.tf_isp); *--SP = value; tcb->mbox.ctx.trapframe.tf.tf_isp = (int)SP; } struct user_thread * makethread(thread_fn *fn, int arg1, void *arg2) { struct user_thread *tcb; /* We could combine these mallocs */ tcb = malloc(sizeof *tcb); bzero(tcb, sizeof(*tcb)); tcb->mbox.UTS_handle = tcb; /* back pointer */ /* malloc the thread's stack */ /* We COULD mmap it with STACK characteristics */ /* Then we could add a guard page. */ tcb->stack_size = T_STACKSIZE; /* set the size we want */ tcb->stack = malloc(tcb->stack_size); /* set the PC to the fn */ tcb->mbox.ctx.trapframe.tf_eip = fn; /* Set the stack and push on the args and a dammy return address */ tcb->mbox.ctx.trapframe.tf_isp = tcb->stack + tcb->stack_size - 16; pushontostack(tcb, (int)arg2); pushontostack(tcb, (int)arg1); pushontostack(tcb, (int)&badreturn); /* safety return address */ } /************************************************************* * code for three separate threads. (so we can see if it works) *************************************************************/ static void thread1_code(void *arg) { for(;;) { sleep (1); write(1,".",1); } } static void thread2_code(void *arg) { for(;;) { sleep (3); write(1,"+",1); } } static void thread3_code(void *arg) { for(;;) { sleep (5); write(1,"=",1); } } static struct thread_mailbox * main() { struct kse_mailbox *k_mbox; /* set up global structures */ runq_last = &runqueue; runqueue = NULL; /* define two threads to run, they are runnable but not yet running */ runq_insert( makethread(&thread1_code, 0, NULL)); runq_insert( makethread(&thread2_code, 0, NULL)); /* and one which we will run ourself */ firstkse->curthread = makethread(&thread3_code, 0, NULL); /* start two KSEs in different KSEGRPs */ k_mbox = startkse(&first_kse); /* startksegrp(&second_kse); */ /* we can't do 2 KSEs yet */ /* One will be sufficient */ /* we are a thread, start the ball rolling */ /* let the kernel know we are it */ firstkse->mbox->current_thread = curthread->mbox; thread3_code(NULL); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 2:15:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id F345037B402 for ; Thu, 24 Jan 2002 02:15:34 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0OAEj423962; Thu, 24 Jan 2002 12:14:45 +0200 (EET) (envelope-from ru) Date: Thu, 24 Jan 2002 12:14:45 +0200 From: Ruslan Ermilov To: Terry Lambert Cc: Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: Nit in wait(2) man page? Message-ID: <20020124121445.F16972@sunbay.com> References: <3C4FCE98.2C0BE57E@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C4FCE98.2C0BE57E@mindspring.com> User-Agent: Mutt/1.3.23i 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, Jan 24, 2002 at 01:06:32AM -0800, Terry Lambert wrote: > Dag-Erling Smorgrav wrote: > > The wait(2) man page says: > > > > [EINTR] The call was interrupted by a caught signal, or the > > signal did not have the SA_RESTART flag set. > > > > Should this be s/or/and/? > > Yes. Interrupted system calls do not return error codes if > the restart flag is set, they are restarted, instead. > I'd suggest that you just drop that ", or" part, like any other interruptable syscalls manpages do (see siginterrupt(3)). > I think you may need to be careful here, though, based on > the interaction with threads. I'm not sure how the wrapped > system calls find themselves restarted, if they are > interrupted by a signal handler. In tehory, this should be > transparent, but in practice, there is a heck of a lot of > voodoo in the wrapper code to deal with masks and stuff, > mostly to deal with the fact that system call restart is no > longer the default behaviour, thanks to POSIX. > POSIX has: [EINTR] The function was interrupted by a signal. [siginterrupt(3) historical material snipped] Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 5: 3:41 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nic.upatras.gr (nic.upatras.gr [150.140.129.30]) by hub.freebsd.org (Postfix) with SMTP id C983437B402 for ; Thu, 24 Jan 2002 05:03:28 -0800 (PST) Received: (qmail 15977 invoked from network); 24 Jan 2002 13:00:13 -0000 Received: from dialup3-ceid-dialinpool-6.upatras.gr (HELO hades.hell.gr) (root@150.140.128.198) by nic.upatras.gr with SMTP; 24 Jan 2002 13:00:13 -0000 Received: (from charon@localhost) by hades.hell.gr (8.11.6/8.11.6) id g0OD3JI04606; Thu, 24 Jan 2002 15:03:19 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Thu, 24 Jan 2002 15:03:19 +0200 From: Giorgos Keramidas To: Nathan Arun Cc: arch@freebsd.org Subject: Re: a suggestion Message-ID: <20020124130318.GA4375@hades.hell.gr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i 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-01-24 00:18:02, Nathan Arun wrote: > Hello FreeBSD developers, > I sent an e-mail to freebsd core team. Mr. Warner Losh suggested I > should sent that e-mail to this arch list. > > So here it is. > > thanks > Nathan > ----------------------------------------------------------------------- > To FreeBSD Core Team: > [...] > May I dare suggest a cosmetic change to FreeBSD? Please set aside your > contempt for a windows programmer and objectively assess my e-mail. > > Section 3.3 of the handbook outlines the directory structure. How about > changing the structure to something akin to windows? Say Although you have a point that the UNIX tree takes a bit of time to get used to, here's a few comments why there is absolutely no reason to make so radical changes to the filesystem structure (apart from the obvious objection that you are trying to change FreeBSD to suit what you are used to, and cause grief, discomfort, and surprise to everybody else who already uses it -- which sounds a bit selfish to me, but I'll let it pass): > /sys/conf --> conf file location for binaries in /sys Why not /system//configuration as you have outlined in /apps? > /sys/log --> log file location for binaries in /sys Ditto, /system//log would someone else suggest. > /sys/src --> source code for the binaries in /sys Someone else would suggest /sources/system/... here. > /sys/include, /sys/lib --> C/C++ sdk There are tons of languages. Why don't you extend this to be: /system/language/binaries /system/language/binaries/compilers /system/language/binaries/interpreters /system/language/binaries/linkers /system/language/include /system/language/libraries /system/language/documentation/tutorials /system/language/documentation/reference ... > /apps --> all applications. for e.g. /apps can have > /apps/apache --> application binaries > /apps/samba --> application binaries > /apps/X11R6 > /apps/src --> source code of all the ports (6000+). Think of what your $PATH would have to be to accomodate for 6000+ entries like /applications/program/binaries. Keep in mind that all these are in the environment, and a copy of the environment is saved for every process you as a user runs. Let me remind you that the entire PATH has to be searched every time you execute a command from (say) its 3763'th component. > So there will be only 4 file systems: /, /sys, /apps, /usr. And the overhead that wou saved by axing away the current tree structure was replaced by the overhead of another one. On top of this, you are suggesting to throw away years of accumulated wisdom, forget all everyone knows about something that has been tested and found that it works, to use some radically different replacement. This is usually answered by the Linux crowd with simple (and somewhat annoying, I have to admit) things like: Cool. Show us the code now! But, I don't want to sound evil or something. This type of thing (asking that something gets replaced with a new, shining, more 'modern' way of doing things) is not always bad. Your bad in this case is only that you seem to be trying to work around the fact that you're new to FreeBSD, and have troubles finding your way around, in the wrong manner. Instead of trying to change FreeBSD, please do at least try to understand it first :) Cheers, -- Giorgos Keramidas . . . . . . . . . keramida@{ceid.upatras.gr,freebsd.org} FreeBSD Documentation Project . . . http://www.freebsd.org/docproj/ FreeBSD: 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 Jan 24 5:26:55 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 7928837B402; Thu, 24 Jan 2002 05:26:48 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.6/8.11.1) id g0ODQlg29061; Thu, 24 Jan 2002 05:26:47 -0800 (PST) (envelope-from obrien) Date: Thu, 24 Jan 2002 05:26:47 -0800 From: "David O'Brien" To: Murray Stokely Cc: John Baldwin , Alfred Perlstein , arch@FreeBSD.org, re@FreeBSD.org Subject: Re: xfree4 by default? Message-ID: <20020124052647.C97610@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20011231174113.O16101@elvis.mu.org> <20011231162222.V2286@windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011231162222.V2286@windriver.com>; from murray@FreeBSD.org on Mon, Dec 31, 2001 at 04:22:22PM -0800 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 Mon, Dec 31, 2001 at 04:22:22PM -0800, Murray Stokely wrote: > On Mon, Dec 31, 2001 at 03:43:19PM -0800, John Baldwin wrote: > > The last time I and others brought this up to Jordan, the tentative plan was to > > switch for 5.0. At this point in the game it is probably a bit late for 4.5, > > however, if you want to head up an effort to get test port builds done after > > the release with 4 as the default and get people to test it out then perhaps a > > switch could be done for 4.6. > > I agree that we should make the switch in -STABLE immediately after > FreeBSD 4.5 is released. I disagree with the timming. We have yet to have a single report that -current packages available on the FTP site are even built against X4. The last time I checked Bento was building against X4, but those packages weren't making it to the FTP server. Unless someone has touched Sysinstall WRT installing X4 since I last did, the support is still incomplete. This needs more flushing out in -current before doing it for -stable. -- -- 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 Thu Jan 24 7:13:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hotmail.com (f244.law9.hotmail.com [64.4.9.244]) by hub.freebsd.org (Postfix) with ESMTP id 5C21037B416 for ; Thu, 24 Jan 2002 07:13:50 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 24 Jan 2002 07:13:50 -0800 Received: from 207.46.171.68 by lw9fd.law9.hotmail.msn.com with HTTP; Thu, 24 Jan 2002 15:13:49 GMT X-Originating-IP: [207.46.171.68] From: "Nathan Arun" To: arch@freebsd.org Subject: Re: a suggestion Date: Thu, 24 Jan 2002 15:13:49 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jan 2002 15:13:50.0286 (UTC) FILETIME=[BA4A6EE0:01C1A4E9] 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 Thank you FreeBSD developers for your time and valuable feedback on my suggestion to change directory structure. Once I get to know UNIX better, I have decided to contribute to the project myself. (i can see some of you pressing panic buttons :) bye Nathan _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 8: 1:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mongrel.pacific.net.au (mongrel.pacific.net.au [61.8.0.107]) by hub.freebsd.org (Postfix) with ESMTP id 4C05937B416 for ; Thu, 24 Jan 2002 08:01:20 -0800 (PST) Received: from dungeon.home (ppp35.dyn249.pacific.net.au [203.143.249.35]) by mongrel.pacific.net.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id CAA24551; Fri, 25 Jan 2002 02:53:52 +1100 X-Authentication-Warning: mongrel.pacific.net.au: Host ppp35.dyn249.pacific.net.au [203.143.249.35] claimed to be dungeon.home Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.11.3/8.11.1) with ESMTP id g0OG6I517948; Fri, 25 Jan 2002 02:06:18 +1000 (EST) (envelope-from mckay) Message-Id: <200201241606.g0OG6I517948@dungeon.home> To: Nathan Arun Cc: arch@freebsd.org, mckay@thehub.com.au Subject: Re: a suggestion References: In-Reply-To: from "Nathan Arun" at "Thu, 24 Jan 2002 00:18:02 +0000" Date: Fri, 25 Jan 2002 02:06:18 +1000 From: Stephen McKay 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 Thursday, 24th January 2002, "Nathan Arun" wrote: >May I dare suggest a cosmetic change to FreeBSD? Please set aside your >contempt for a windows programmer and objectively assess my e-mail. Rather than rip into you because you come from the dark side, I'll take this as a straightforward question. I'm sure you can be saved. :-) What you've suggested isn't really cosmetic. All Unix admins have these paths that you find confusing hardwired into their brains and fingers. It's totally automatic after a short time. So, in some sense, it's a non-problem: If you are ever going to need to know enough Unix that the exact directory structure matters, then you'll know that by osmosis before you know all the other really important stuff. >[He moves everything around a lot] >So there will be only 4 file systems: /, /sys, /apps, /usr. I've idly thought of rearranging everything too. After all, it mostly just accreted as time went by. Once there was only /bin for executables. And /usr was the "User" pack. Then user binaries had to go in /usr/bin. Once /usr/bin became formalised as part of the O/S, user binaries had to go somewhere else. /usr/local sprang into being. Network computing brought new difficulties, so /var was born. Later, package handling got out of hand and /opt was added to fix this (not here though, for some reason the ports people just stole /usr/local from the local admins). Hmm. Ports people: When can we have /usr/local back? I'll trade you /pkg for it. :-) My simplification of the directory structures ends up like this: / Mandatory, of course /dev Devices /bin Standard OS Executables /lib Standard Shared libraries /etc Local machine configuration files /opt Packages, 3rd party applications, and so forth /share Basically == /usr/share, but I can't think of a better name /var Writable local storage (so most of the rest can be R/O) /home User data In my scheme, the "Standard OS" part can be quite small, and most stuff can live in /opt. Of course there's no chance anyone will adopt this. I just dream. :-) >What I have suggested is an exact copy of Windows' "Winnt", "Program Files" >and "Documents and Settings" directories. But what's wrong in being easy and >clear? This structure is more logical. Logic must be in the eye of the beholder. I've always found the Windows layout to be totally bonkers. Especially the part where random apps overwrite bits of the OS as a "feature". And a plague of Biblical Proportions on whoever invented the registry! >I'm suggesting this because it is confusing to have so many bin & sbin >directories. This may sound trivial to experienced UNIX users like you, but >if you want to grow your user base, you should target the OS at more naive >developers like me. Many developers feel that windows is easy >and want to try something more challenging, but UNIX is too difficult. > >These difficulties in turn become a "SIGNIFICANT BARRIER TO ADOPTION". Well, there are a lot of books on Unix. And lots of free source code to read. There is a lot of support available. Truly. I don't think the location of a few directories makes any difference. It's more in the fundamental mind set difference between Unix (power tool) and windows (um, some cuddly not-power tool of some sort, help me out here!). >UNIX community steadfastly refused to improve usability on the desktop and >Microsoft laughed it's way to the bank. I'm afraid the same thing is going >to happen on the server side as well. It's much more complicated than that. My desktop is top notch. Why don't you like it? Probably it is too spartan for you. Nothing animates. Nothing fades in or out. It is completely oriented towards getting my work done without getting in the way. No improvement in usability is necessary. Does that explain why I'm not working on desktop "improvement"? I'm not running Unix because it is difficult and I have a hairy chest. I do this because Bill Gate's toy OS is excruciatingly frustrating and never does what I want. Unix is enormously easier for me to use than windows. Oh, and being a product of a convicted monopoly that is intent on complete world domination doesn't help. I eat Dolphin Free tuna too. :-) Now, in the server area, a different class of people is involved. Unix is much safer there. I still laugh all day long at people who walk into the next room because they have to fiddle with the console to adjust some trivial setting on a windows server. I've always been able to remotely administer all my Unix boxes. This is from way back before windows even existed. What's wrong with all those windows weenies? Don't they care that their OS has been built stupid from day one? >Thank you for reading this far. Hope I haven't offended anyone. Um. Ditto. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 12:18: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id F044437B404 for ; Thu, 24 Jan 2002 12:17:56 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id HAA00290; Fri, 25 Jan 2002 07:17:55 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01KDHA7TS7XCVFNEYU@cim.alcatel.com.au>; Fri, 25 Jan 2002 07:18:00 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g0OKHpv09955; Fri, 25 Jan 2002 07:17:51 +1100 Content-return: prohibited Date: Fri, 25 Jan 2002 07:17:51 +1100 From: Peter Jeremy Subject: Re: a suggestion In-reply-to: ; from nathan_arun@hotmail.com on Thu, Jan 24, 2002 at 12:18:02AM +0000 To: Nathan Arun Cc: arch@FreeBSD.ORG Mail-Followup-To: Nathan Arun , arch@FreeBSD.ORG Message-id: <20020125071750.F72285@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i 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 Thu, Jan 24, 2002 at 12:18:02AM +0000, Nathan Arun wrote: >Section 3.3 of the handbook outlines the directory structure. How about >changing the structure to something akin to windows? The Unix filesystem layout predates the Windows layout and is more logical so I'd suggest you write to Microsoft and get them to change the Windows filesystem layout :-). >/sys --> all system binaries, scripts that now reside in /bin, > /sbin, /usr/bin,/usr/sbin, /boot, /etc, including > KERNEL, gcc, ... will reside here. I presume this means that /bin/sh will become /sys/sh etc. > In addition /sys will have the following sub-directories: ... > /sys/mnt --> mount point (if necessary) What is this for? > /sys/conf --> conf file location for binaries in /sys > /sys/dev --> all device nodes > /sys/log --> log file location for binaries in /sys > /sys/src --> source code for the binaries in /sys > /sys/include, /sys/lib --> C/C++ sdk > /sys/man --> man pages for binaries in /sys This last entry provides a clear demonstration of the disadvantages of this approach: 1) /usr/bin/man is a command to display a man page. My understanding of your first point is that it would be renamed to /sys/man. This immediately precludes the use of /sys/man as a directory. 2) Man pages document far for than the binaries. They document the kernel and library interfaces as well as the configuration file formats etc. Where do all these other man pages go? Question for you: Where would you put things like the compiler back ends (currently in /usr/libexec), various datafiles needed by things like lint and perl (currently in /usr/libdata) and general files (/usr/share). >/apps --> all applications. for e.g. /apps can have ... Apart from your approach to the executable locations, this approach is used by some Un*x variants (though the directory is either /opt or /usr/opt). There are occasional discussions in FreeBSD lists about using this approach for ports. >/usr --> all user directories. for e.g. /usr can have > /usr/root > /usr/root/.cshrc Root's home directory needs to be in the root filesystem so that it is available in single-user mode when no other filesystems are mounted. For other user directories, it's fairly arbitrary whether they live in /usr, /user, /usr/users, /home or /lusers. >Other miscellaneous files that are currently under /usr/local, /usr/share, >/var can be moved under one of the above. This is where your proposal starts to lose steam. Most of these files don't fit into any of the categories or sub-directories mentioned above. Also, /var's sole reason for existence is to allow /usr to become read-only (the root filesystem was already virtually read- only). Mixing the files in /var back into other filesystems is a definite regression. >So there will be only 4 file systems: /, /sys, /apps, /usr. What about /tmp? If all the system executables have been moved into /sys, how does the system get from single-user mode (with only the root filesystem available) to multi-user mode (with all filesystems available). >What I have suggested is an exact copy of Windows' "Winnt", "Program Files" >and "Documents and Settings" directories. "Winnt" and "Program Files" are logically equivalent to /sys and /apps above, but I don't see any relationship between "Documents and Settings" and /usr. > But what's wrong in being easy and clear? Nothing. We currently have a logical filesystem layout. I think it's clearer and more logical than Windows. I've always thought that the idea of having random subdirectories within the directories forming the searchpath is very illogical. One of the things I dislike about Windows is the arbitrary and random structure - with subdirectories where I'd expect to find executables. >I'm suggesting this because it is confusing to have so many bin & sbin >directories. The distinction between /bin and /usr/bin (& /sbin and /usr/sbin) is now fairly arbitrary. Originally, the root filesystem was fairly small due to physical disk sizes. This was continued after disk sizes grew because a small (and mostly static) filesystem was less likely to be damaged by a crash. The root file system (including /bin and /sbin) included the utilities necessary to validate and recover the system. On many modern Unices, /bin is a symbolic link to /usr/bin. If you look back through the archives, you will find that this has been discussed fairly recently. As for the distinction between /bin and /sbin: /sbin (and /usr/sbin) is for commands that are only needed for system administration. Normal users shouldn't need to access any of these files. (In a tightly secured environment you might prevent normal users accessing them). > This may sound trivial to experienced UNIX users like you, but >if you want to grow your user base, you should target the OS at more naive >developers like me. Many developers feel that windows is easy >and want to try something more challenging, but UNIX is too difficult. The Window's filesystem structure is definitely not intuitively obvious. You must have expended significant time and effort in learning the Windows structure, I fail to see why you expect that you should be able to migrate to Unix without expending any effort. Keep in mind that what you're suggesting would require all Un*x sysadmins to re-learn the filesystem layout before they could use FreeBSD. This would significantly reduce the appeal of FreeBSD within the Un*x community. One final point: FreeBSD is mostly a volunteer project. If you want something done, the best person to do it is yourself. If you seriously want to re-arrange the filesystem, provide the necessary patches - a complete list of all the changes that would be necessary to implement your approach. If you want to get other people on-board, you will need to provide a more detailed proposal that defines the new location for every object in the FreeBSD filesystem (and doesn't gloss over things like /usr/share and /var) and justifies the change (better than "because Windows does it that way"). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 12:53: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 5FD0337B402 for ; Thu, 24 Jan 2002 12:52:59 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0OKqoV02589 for ; Thu, 24 Jan 2002 13:52:50 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0OKqoM00492 for arch@freebsd.org; Thu, 24 Jan 2002 13:52:50 -0700 (MST) (envelope-from davidc) Date: Thu, 24 Jan 2002 13:52:50 -0700 From: Chad David To: arch@freebsd.org Subject: strtod() Message-ID: <20020124135250.A454@colnta.acns.ab.ca> Mail-Followup-To: arch@freebsd.org 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 After a short discussion with Alfred he recommended that I post my question here. On current (as of today) strtod() sets errno to EINVAL even when no error actually occurs. While I understand that the value of errno is undefined if an error does not occur, there is confusion when 0.0 is passed and the conversion is successful. SUSv2 states that if no conversion can be performed 0.0 is returned, and error MAY be set to EINVAL; as well, the Solaris interpretation of SUSv2 and c89 say: "3. If strtod() returns 0.0, one of the following occurred: a. The "subject sequence" was not an empty string, but evaluated to 0.0. (In this case, errno will be left unchanged.) b. The "subject sequence" was an empty string. (In this case, the Single UNIX Specification version 2 allows errno to be set to EINVAL or to be left unchanged. The C Standard does not specify any specific behavior in this case.) c. The "subject sequence" specified a numeric value that would cause a floating point underflow. (In this case, errno may be set to ERANGE or may be left unchanged.)" The usage notes all so say: "Because 0 is returned on error and is also a valid return on success, an application wishing to check for error situa- tions should set errno to 0, then call strtod(), then check errno and if it is non-zero, assume an error has occurred." I'm not saying that just because Solaris chooses to implement the interface in this way that FreeBSD should, but I do think that there is a lot of room for introducing (needless) complexity when porting applications from Solaris (like I am), and that while FreeBSD does not have to set EINVAL when an error occurs, it should NOT set it when an error does not occur. Note that on stable errno does not get set to EINVAL. Thanks. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 13:40: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 17EEA37B416 for ; Thu, 24 Jan 2002 13:39:59 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0OLdr887088; Fri, 25 Jan 2002 00:39:53 +0300 (MSK) (envelope-from ache) Date: Fri, 25 Jan 2002 00:39:52 +0300 From: "Andrey A. Chernov" To: Chad David Cc: arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020124213951.GB87013@nagual.pp.ru> References: <20020124135250.A454@colnta.acns.ab.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020124135250.A454@colnta.acns.ab.ca> User-Agent: Mutt/1.3.27i 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, Jan 24, 2002 at 13:52:50 -0700, Chad David wrote: > > SUSv2 states that if no conversion can be performed 0.0 is returned, and > error MAY be set to EINVAL; POSIX says it too. IMHO it is proper variant to _set_ it to distinguish pure 0.0 with 0.0 as result of wrong conversion. Our other strto*() functions in the -current already do so. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 14:45:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from draco.over-yonder.net (draco.over-yonder.net [198.78.58.61]) by hub.freebsd.org (Postfix) with ESMTP id 90D9837B416 for ; Thu, 24 Jan 2002 14:45:29 -0800 (PST) Received: by draco.over-yonder.net (Postfix, from userid 100) id F3872FC4; Thu, 24 Jan 2002 16:45:28 -0600 (CST) Date: Thu, 24 Jan 2002 16:45:28 -0600 From: "Matthew D. Fuller" To: Stephen McKay Cc: Nathan Arun , arch@freebsd.org Subject: Re: a suggestion Message-ID: <20020124164528.D2760@over-yonder.net> References: <200201241606.g0OG6I517948@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5-fullermd.1i In-Reply-To: <200201241606.g0OG6I517948@dungeon.home>; from mckay@thehub.com.au on Fri, Jan 25, 2002 at 02:06:18AM +1000 X-Editor: vi X-OS: FreeBSD 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 Fri, Jan 25, 2002 at 02:06:18AM +1000 I heard the voice of Stephen McKay, and lo! it spake thus: > > I've idly thought of rearranging everything too. After all, it mostly just > accreted as time went by. Once there was only /bin for executables. And > /usr was the "User" pack. Then user binaries had to go in /usr/bin. Once > /usr/bin became formalised as part of the O/S, user binaries had to go > somewhere else. /usr/local sprang into being. Network computing brought That's not quite it. /usr, last I checked, still stood for Unix System Repository (or some similar), and came about because / was getting too big for the fixed (in the sense of "fixed for all eternity, don't even bother to think about replacing me" :) disks in systems of the time. /usr/local became a defacto place for locally-installed software. > new difficulties, so /var was born. Later, package handling got out of hand > and /opt was added to fix this (not here though, for some reason the ports > people just stole /usr/local from the local admins). Hmm. Ports people: > When can we have /usr/local back? I'll trade you /pkg for it. :-) /opt came about when formalized packaging systems came about. Ports seems to have the attitude of "Wait, whether it's compiled manually or with our packaging framework, it's STILL a local addition, why the heck would we waste another directory?". I can see plenty of arguments for both sides of THAT particular argument, so let's not start that flamefest just yet :-). > It's much more complicated than that. My desktop is top notch. Why > don't you like it? Probably it is too spartan for you. Nothing animates. > Nothing fades in or out. It is completely oriented towards getting my > work done without getting in the way. No improvement in usability is > necessary. Does that explain why I'm not working on desktop "improvement"? Amen to that. I love my twm. Keep your bloody 'icons' the hell away from my desktop, than you very much. What makes Unix desktops "better" in the eyes of me-as-the-person-using-it, is that it IS structured so you CAN easily do it a kadzillion different ways. KDE is heavy as hell, and it's got everything you can imagine integrated into it. Then you've got the twm's and mwm and the like which are extremely minimalistic. And the Blackbox's and fvwm's and xfce's in the middle. Pick what fits you and use it; what could possibly be an 'improvement' on that? Though, I must admit, I like the taste of dolphin... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 14:53: 6 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 7945D37B402 for ; Thu, 24 Jan 2002 14:53:02 -0800 (PST) Received: from pool0162.cvx40-bradley.dialup.earthlink.net ([216.244.42.162] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16Tsjl-0000E7-00; Thu, 24 Jan 2002 14:52:54 -0800 Message-ID: <3C509041.7CFEA046@mindspring.com> Date: Thu, 24 Jan 2002 14:52:49 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: Nathan Arun , arch@FreeBSD.ORG Subject: Re: a suggestion References: <20020125071750.F72285@gsmx07.alcatel.com.au> 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 Peter Jeremy wrote: > Question for you: Where would you put things like the compiler back > ends (currently in /usr/libexec), ld.so -> /windows/system/peldr.vxd (version clash) libc.so -> /windows/system/crtl42.dll > various datafiles needed by things like lint and perl > (currently in /usr/libdata) and general files (/usr/share). /windows/system/user.da0 (the registry) 8-) 8-) 8-) > What about /tmp? If all the system executables have been moved into > /sys, how does the system get from single-user mode (with only the > root filesystem available) to multi-user mode (with all filesystems > available). /windows/system/temproary\ internet\ files /windows/system/temp013987 8-) 8-) > >I'm suggesting this because it is confusing to have so many bin & sbin > >directories. > > The distinction between /bin and /usr/bin (& /sbin and /usr/sbin) is > now fairly arbitrary. Originally, the root filesystem was fairly > small due to physical disk sizes. This was continued after disk sizes > grew because a small (and mostly static) filesystem was less likely to > be damaged by a crash. The root file system (including /bin and > /sbin) included the utilities necessary to validate and recover the > system. On many modern Unices, /bin is a symbolic link to /usr/bin. > If you look back through the archives, you will find that this has > been discussed fairly recently. The intent was to allow "diskless" and "dataless" configurations using NFS servers to boot the OS, which leads to every machine in the building having an identical configuration, except for any local work areas. SunOS 4.x did this beautifully, and any stale organization here is a bug. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 16:15:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by hub.freebsd.org (Postfix) with ESMTP id 8347437B417; Thu, 24 Jan 2002 16:15:40 -0800 (PST) Received: from vicor-nb.com (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 49FCA1B221; Thu, 24 Jan 2002 16:15:40 -0800 (PST) Message-ID: <3C50A3AC.8E9650F8@vicor-nb.com> Date: Thu, 24 Jan 2002 16:15:40 -0800 From: Julian Elischer Organization: VICOR X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Daniel Eischen Cc: deischen@freebsd.org, arch@freebsd.org Subject: Re: KSE question References: 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 Daniel Eischen wrote: > > On Thu, 24 Jan 2002, Julian Elischer wrote: > > Do you have in the normal uthreads package an assembler routine to load > > and save the registers? Or do you use longjmp? > > In libc_r, we just use _setjmp and _longjmp. For KSE pthreads > I wanted to use getcontext and setcontext, and was the reason > I added them to -current. I have to turn them into system > calls to satisfy Peter Wemm, but I plan on moving the assembler > files in libc to libpthread. > > Why don't you try using these with your KSE test program? It'll > save you from having to munge trapframes into jmp_bufs, since > getcontext/setcontext operate on trapframes. > > -- > Dan Eischen ah great.. I just wrote loadthread and savethread that load and save a trapframe. but I'll look for get/setcontext. (now I know what they are called) I hope to try out the first KSE-style threads tonight.. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Jan 24 19:58:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 8DE2337B400; Thu, 24 Jan 2002 19:58:47 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020125035847.JRLY26243.rwcrmhc51.attbi.com@peter3.wemm.org>; Fri, 25 Jan 2002 03:58:47 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0P3wls25057; Thu, 24 Jan 2002 19:58:47 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id D37AB3A9A; Thu, 24 Jan 2002 19:58:46 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Daniel Eischen , deischen@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C50A3AC.8E9650F8@vicor-nb.com> Date: Thu, 24 Jan 2002 19:58:46 -0800 From: Peter Wemm Message-Id: <20020125035846.D37AB3A9A@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 Julian Elischer wrote: > Daniel Eischen wrote: > > > > On Thu, 24 Jan 2002, Julian Elischer wrote: > > > Do you have in the normal uthreads package an assembler routine to load > > > and save the registers? Or do you use longjmp? > > > > In libc_r, we just use _setjmp and _longjmp. For KSE pthreads > > I wanted to use getcontext and setcontext, and was the reason > > I added them to -current. I have to turn them into system > > calls to satisfy Peter Wemm, but I plan on moving the assembler > > files in libc to libpthread. > > > > Why don't you try using these with your KSE test program? It'll > > save you from having to munge trapframes into jmp_bufs, since > > getcontext/setcontext operate on trapframes. > > > > -- > > Dan Eischen > > > ah great.. > I just wrote loadthread and savethread that load and save a trapframe. > but I'll look for get/setcontext. (now I know what they are called) Dont worry too much about this yet.. whatever is required to get a minimal proof-of-concept up is what we need. When we worked on the whiteboard we discovered that FP handling was going to be rather complex to say the least. That is far beyond the scope of a proof-of-concept test :-). > I hope to try out the first KSE-style threads tonight.. > :-) Whee.. :-) Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "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 Thu Jan 24 22:23: 8 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 1F8E237B402 for ; Thu, 24 Jan 2002 22:23:06 -0800 (PST) Received: from dialup-209.245.139.214.dial1.sanjose1.level3.net ([209.245.139.214] helo=blossom.cjclark.org) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16TzlJ-0001qf-00 for arch@freebsd.org; Thu, 24 Jan 2002 22:23:01 -0800 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.3) id g0P6MTB94008 for arch@freebsd.org; Thu, 24 Jan 2002 22:22:29 -0800 (PST) (envelope-from cjc) Date: Thu, 24 Jan 2002 22:22:25 -0800 From: "Crist J. Clark" To: arch@freebsd.org Subject: Changing rc.conf(5) firewall_enable Message-ID: <20020124222225.O87663@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ 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 Patrick Greenwell brought up a good point on -stable. The rc.conf(5) knob, firewall_enable, does not exactly behave in the manner the novice (or not-so-novice) might expect. When it is set to "YES," the ipfw.ko module is loaded if firewalling is not built into the kernel, and the firewall configuration scripts are run. However, if 'firewall_enable="NO",' it does not disable the firewall. I do not see any reason why 'firewall_enable="NO"' should not actually disable firewalling built into the kernel by setting, sysctl net.inet.ip.fw.enable=0 This seems to make more sense given the name, firewall_enable, and it also seems more useful. IMHO, this should be the behavior in -CURRENT for sure. In -STABLE, I think it would be OK too. A machine with firewalling built into the kernel and firewall_enable not "YES" is almost useless (if it is not built with IPFIREWALL_DEFAULT_TO_ACCEPT). I don't think there are an machines out there running with firewalling built into the kernel with 'firewall_enable="NO"' who will have their security affected by such a change. Other opinions? Pro? Con? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@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 Jan 24 23:54:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 76D9637B400; Thu, 24 Jan 2002 23:54:30 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g0P7sLP58478; Fri, 25 Jan 2002 09:54:21 +0200 (EET) (envelope-from ru) Date: Fri, 25 Jan 2002 09:54:21 +0200 From: Ruslan Ermilov To: "Crist J. Clark" Cc: arch@FreeBSD.ORG Subject: Re: Changing rc.conf(5) firewall_enable Message-ID: <20020125095421.B57703@sunbay.com> References: <20020124222225.O87663@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020124222225.O87663@blossom.cjclark.org> User-Agent: Mutt/1.3.23i 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, Jan 24, 2002 at 10:22:25PM -0800, Crist J. Clark wrote: > Patrick Greenwell brought up a good point > on -stable. The rc.conf(5) knob, firewall_enable, does not exactly > behave in the manner the novice (or not-so-novice) might expect. When > it is set to "YES," the ipfw.ko module is loaded if firewalling is not > built into the kernel, and the firewall configuration scripts are run. > However, if 'firewall_enable="NO",' it does not disable the > firewall. > > I do not see any reason why 'firewall_enable="NO"' should not actually > disable firewalling built into the kernel by setting, > > sysctl net.inet.ip.fw.enable=0 > > This seems to make more sense given the name, firewall_enable, and it > also seems more useful. > > IMHO, this should be the behavior in -CURRENT for sure. In -STABLE, I > think it would be OK too. A machine with firewalling built into the > kernel and firewall_enable not "YES" is almost useless (if it is > not built with IPFIREWALL_DEFAULT_TO_ACCEPT). I don't think there are > an machines out there running with firewalling built into the kernel > with 'firewall_enable="NO"' who will have their security affected by > such a change. > > Other opinions? Pro? Con? > Please count me in for this change. Seems you've managed to get rid of that extra space. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 0:28:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from web14005.mail.yahoo.com (web14005.mail.yahoo.com [216.136.175.121]) by hub.freebsd.org (Postfix) with SMTP id 6A75C37B404 for ; Fri, 25 Jan 2002 00:28:27 -0800 (PST) Message-ID: <20020125082827.88543.qmail@web14005.mail.yahoo.com> Received: from [216.103.213.142] by web14005.mail.yahoo.com via HTTP; Fri, 25 Jan 2002 00:28:27 PST Date: Fri, 25 Jan 2002 00:28:27 -0800 (PST) From: k Macy Subject: Re: KSE question To: Peter Wemm , Julian Elischer Cc: Daniel Eischen , deischen@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <20020125035846.D37AB3A9A@overcee.wemm.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 > > > In libc_r, we just use _setjmp and _longjmp. > For KSE pthreads > > > I wanted to use getcontext and setcontext, and > was the reason > > > I added them to -current. I have to turn them > into system > > > calls to satisfy Peter Wemm, but I plan on > moving the assembler > > > files in libc to libpthread. > > > I apologize in advance if this is a stupid question, but would it be possible to make it a compile time option, or a pthread_set* function to have getcontext and setcontext be user-level functions for programs that don't use floating point? __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 3:11: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by hub.freebsd.org (Postfix) with ESMTP id EBACE37B400; Fri, 25 Jan 2002 03:11:05 -0800 (PST) Received: from blackbox.pacbell.net ([64.166.84.36]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GQH00GJ0R2GJZ@mta6.snfc21.pbi.net>; Fri, 25 Jan 2002 03:11:05 -0800 (PST) Received: (from mikem@localhost) by blackbox.pacbell.net (8.11.6/8.11.6) id g0PBBTp18677; Fri, 25 Jan 2002 03:11:29 -0800 (PST envelope-from mikem) Date: Fri, 25 Jan 2002 03:11:29 -0800 From: Mike Makonnen Subject: Re: Changing rc.conf(5) firewall_enable In-reply-to: <20020124222225.O87663@blossom.cjclark.org> To: "Crist J. Clark" Cc: arch@freebsd.org Message-id: <200201251111.g0PBBTp18677@blackbox.pacbell.net> MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i386--freebsd5.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20020124222225.O87663@blossom.cjclark.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 Thu, 24 Jan 2002 22:22:25 -0800 "Crist J. Clark" wrote: > ... I don't think there are > an machines out there running with firewalling built into the kernel > with 'firewall_enable="NO"' who will have their security affected by > such a change. This should probably be mentioned in UPDATING. Although the current behaviour sounds counter-intuitive, who knows how many people have been relying on it (explicitly or without knowing it). I know when I first started using it I had the firewall compiled into the kernel, and it was only after I started using the loadable module that I realized I had to explicitly override firewall_enable in my rc.conf. cheers, mike makonnen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 3:54: 6 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 106CD37B402; Fri, 25 Jan 2002 03:54:03 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 16U4yG-000FL2-00; Fri, 25 Jan 2002 13:56:40 +0200 From: Sheldon Hearn To: Mike Makonnen Cc: "Crist J. Clark" , arch@freebsd.org Subject: Re: Changing rc.conf(5) firewall_enable In-reply-to: Your message of "Fri, 25 Jan 2002 03:11:29 PST." <200201251111.g0PBBTp18677@blackbox.pacbell.net> Date: Fri, 25 Jan 2002 13:56:40 +0200 Message-ID: <58963.1011959800@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 On Fri, 25 Jan 2002 03:11:29 PST, Mike Makonnen wrote: > This should probably be mentioned in UPDATING. And if firewall_enable="NO" changes to mean "turn off firewalling" in 4.5-RELEASE, that's probably okay too, because Bruce does such a brilliant job with the release notes. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 5:22:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 7656D37B402; Fri, 25 Jan 2002 05:22:08 -0800 (PST) Received: from vigrid.com (pm3-pt15.pcnet.net [206.105.29.89]) by pcnet1.pcnet.com (8.12.1/8.12.1) with ESMTP id g0PDKgDk026784; Fri, 25 Jan 2002 08:20:42 -0500 (EST) Message-ID: <3C515DC8.536C556@vigrid.com> Date: Fri, 25 Jan 2002 08:29:44 -0500 From: Dan Eischen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: k Macy Cc: Peter Wemm , Julian Elischer , deischen@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: KSE question References: <20020125082827.88543.qmail@web14005.mail.yahoo.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 k Macy wrote: > > > > > In libc_r, we just use _setjmp and _longjmp. For KSE pthreads > > > > I wanted to use getcontext and setcontext, and was the reason > > > > I added them to -current. I have to turn them into system > > > > calls to satisfy Peter Wemm, but I plan on moving the assembler > > > > files in libc to libpthread. > > I apologize in advance if this is a stupid question, > but would it be possible to make it a compile time > option, or a pthread_set* function to have getcontext > and setcontext be user-level functions for programs > that don't use floating point? In non-threaded programs, getcontext, setcontext, and swapcontext always save and restore the signal mask, so they would result in system call anyways. The rationale is that if you have to make a system call to set the mask, you might as well make the whole function a system call (and get/set the FPU state as well to avoid a subsequent trap when trying to do it in userland). See the long thread in -arch about this. In the threads library, we will probably have to overload these functions anyways since they get and set the signal mask (which have to be thread signal masks, not the process signal mask). They shouldn't result in system calls, though they may cause a trap to the kernel when trying to restore FPU state (but this should be limited to once per timeslice). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 13:40:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id EB49337B402; Fri, 25 Jan 2002 13:40:33 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UE4x-0001Hz-00; Fri, 25 Jan 2002 13:40:11 -0800 Message-ID: <3C51D0B6.F6E04EBC@mindspring.com> Date: Fri, 25 Jan 2002 13:40:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Eischen Cc: k Macy , Peter Wemm , Julian Elischer , deischen@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: KSE question References: <20020125082827.88543.qmail@web14005.mail.yahoo.com> <3C515DC8.536C556@vigrid.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 Dan Eischen wrote: > k Macy wrote: > > I apologize in advance if this is a stupid question, > > but would it be possible to make it a compile time > > option, or a pthread_set* function to have getcontext > > and setcontext be user-level functions for programs > > that don't use floating point? > > In non-threaded programs, getcontext, setcontext, and > swapcontext always save and restore the signal mask, so > they would result in system call anyways. The rationale > is that if you have to make a system call to set the mask, > you might as well make the whole function a system call > (and get/set the FPU state as well to avoid a subsequent > trap when trying to do it in userland). See the long > thread in -arch about this. Can't you handle this with a user space glue trampoline, with signals being delivered to the process *always*, but delivered to the user's code based on user space masking/trapping registrations with the signal code? VMS was POSIX compliant, and this is how it implemented signals in the context of its own facilities. It seems to me that signals are rare enough that doing the OS-based delivery always, and then doing delivery to user soce based on conditional user code would be a real possible approach to this. Basically, there would be a trampoline to user space, and then all of the signal related system calls, save the _xxx registration for the user space glue code, and the kill(2) (only when invoked on another process!) could be in user space. Then the get/set context would be capable of being in user space, always, with the exception of programs that use the FPU. The FPU usage is problematic, but is also resolvable, as a tools issue. Specifically, if an ELF section were generated whenever the compiler generated FPU code (let's call this section "flags", for the sake of argument), then the flag "FPU=1" could be set there. If *any* object file during a link process had this flag set in it, then a .init could cause replacement of soft pointers used to implement FPU context save code, as opposed to non-save code. Since the FPU code could be in a .so file that is later dlopen(3)'ed, then there would need to be additional work so that ld.so (really, the wrong place for dlopen's implementation, anyway), could set the flag while there were outstanding context saves already in progress. Thus there would be: o A flag on the object, to indicate the presence of FPU code from the code generator o A flag/code predicate that indicated this to the executable, via a procedural interface of some kind, so that function pointers could be overriden at load time o A flag in the saved contexts generated by the {set|get}context function in user space to indicate a saved context without FPU state, so that a switch from not saving FPU state to saving FPU state could be handled on a setcontext() of a context created via a getcontext() prior to FPU code being present could work subsequent to its presence. In other words, to answer the original question, the answer is "Yes, with appropriate effort". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 13:43:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from androcles.com (androcles.com [204.57.240.10]) by hub.freebsd.org (Postfix) with ESMTP id 1653237B400 for ; Fri, 25 Jan 2002 13:43:22 -0800 (PST) Received: (from alex@localhost) by androcles.com (8.11.6/8.11.3) id g0PLh6W90454; Fri, 25 Jan 2002 13:43:06 -0800 (PST) (envelope-from alex) Message-Id: <200201252143.g0PLh6W90454@androcles.com> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020125071750.F72285@gsmx07.alcatel.com.au> Date: Fri, 25 Jan 2002 13:43:06 -0800 (PST) From: "Duane H. Hesser" To: Peter Jeremy Subject: Re: a suggestion Cc: arch@FreeBSD.ORG, Nathan Arun 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 This thread offers me an opportunity to ask a question of this august group, which question has been on my mind for a year or two, and surfaces every time filesystem structure threads appear in these lists. The question has to do with a UC Berkeley posting to USENET in the late eighties, but I will ask it (more or less in context) toward the end of this reply. Peter, please forgive me if I slice up your replies too mercilessly; I just have a couple of things to add. On 24-Jan-02 Peter Jeremy wrote: > On Thu, Jan 24, 2002 at 12:18:02AM +0000, Nathan Arun wrote: >>Section 3.3 of the handbook outlines the directory structure. How about >>changing the structure to something akin to windows? > > The Unix filesystem layout predates the Windows layout and is more > logical so I'd suggest you write to Microsoft and get them to change > the Windows filesystem layout :-). > I tend to agree that the current basic directory hierarchy layout is logical and fundamentally useful; it is certainly not the result of arbitrary, random decisions. There are likely an infinite number of layouts which might serve as well, but please (Nathan) don't assume that the current design was arrived at by a thousand monkeys pounding on keyboards (it's more like tens of thousands :-). Regardless the number of monkeys, there is a method to the madness. It wasn't clear to me from your original posting how long you (Nathan) have spent attempting to understand the current method (or madness), but I'm willing to bet that it's much less than you've spent with "Windows". I have often thought that folks who talk about the "intuitive" nature of windows simply don't realize the investment of time they have in learning what they know about it. A common problem for new Unix users is the problem of "finding things" in a hierarchy which may contain tens of thousands of files. If this is a factor in your displeasure, I will suggest what I would suggest to all new Unix users...scout out the 'locate' command (/usr/bin/locate) and 'locate.updatedb' (in /usr/libexec) and learn to use them effectively. (At a minimum, they will allow you to find where you *don't* want a file to be :=). [snip] >>So there will be only 4 file systems: /, /sys, /apps, /usr. Don't confuse "filesystems" with the namespace represented by the directory hierarchy. That just muddys the waters. The association of disks/partitions with branches of the directory tree is a separate issue, and one which should be considered carefully (and *designed* carefully) for each and every platform to which an OS is installed. >>I'm suggesting this because it is confusing to have so many bin & sbin >>directories. It need not be. Learn to set up your PATH in your chosen shell, and forget about it. Put as many (or as few) 'bin', 'sbin', or 'etc' directories in your PATH as you need. If you don't want to forget about it, use 'which'. > > The distinction between /bin and /usr/bin (& /sbin and /usr/sbin) is > now fairly arbitrary. Originally, the root filesystem was fairly > small due to physical disk sizes. This was continued after disk sizes > grew because a small (and mostly static) filesystem was less likely to > be damaged by a crash. The root file system (including /bin and > /sbin) included the utilities necessary to validate and recover the > system. On many modern Unices, /bin is a symbolic link to /usr/bin. > If you look back through the archives, you will find that this has > been discussed fairly recently. > > As for the distinction between /bin and /sbin: /sbin (and /usr/sbin) > is for commands that are only needed for system administration. > Normal users shouldn't need to access any of these files. (In a > tightly secured environment you might prevent normal users accessing > them). > What he said. Although I think there's a bit more to it. ... >> This may sound trivial to experienced UNIX users like you, but >>if you want to grow your user base, you should target the OS at more naive >>developers like me. Many developers feel that windows is easy >>and want to try something more challenging, but UNIX is too difficult. > If you want to have, or want your users to have, a more familiar "Windows-like" experience, try KDE. It's huge, and needs extraordinary resources (much like Windows), but the FreeBSD "ports" or "packages" systems will install it for you, and it will allow Windows users to feel at home rather rapidly, I think. The major difference is that they will have far more power at their fingertips. Unix isn't just for us (OLD) command-line users anymore! Of course nothing stops US from having a dozen or so 'xterms' running on six or eight KDE desktops. Nothing would stop *you* either (once you figure out where 'xterm' is :-). Some would suggest Gnome rather than KDE; or you can make disk suppliers happy, and install both. Some, of course, would say I'm crazy to suggest either... > The Window's filesystem structure is definitely not intuitively > obvious. You must have expended significant time and effort in > learning the Windows structure, I fail to see why you expect that you > should be able to migrate to Unix without expending any effort. > Yeah, that's what I meant... .... > > One final point: FreeBSD is mostly a volunteer project. If you want > something done, the best person to do it is yourself. If you > seriously want to re-arrange the filesystem, provide the necessary > patches - a complete list of all the changes that would be necessary > to implement your approach. If you want to get other people on-board, > you will need to provide a more detailed proposal that defines the new > location for every object in the FreeBSD filesystem (and doesn't gloss > over things like /usr/share and /var) and justifies the change (better > than "because Windows does it that way"). > > Peter > That brings me to the QUESTION I threatened at the beginning to ask. Many of you on these lists are aware that, up until at least the "late eighties" most Unix distributions presented a file hierarchy largely based upon the Version 7 filesystem, save for "cultural differences" (e.g a '/usr/ucb' here, or an '/etc/init' there) between the BSD and Sys V camps. Somewhere in that timeframe, just after BSD 4.3, a posting to USENET by UC Berkeley (Mr. McKusick, was that you?) presented a new filesystem layout. The posting included postscript graphics of the filesystem tree, and included consise descriptions of the intended use and rationale for all features of the new layout. In short, they did just what peter said..."provide a more detailed proposal". It was, as I recall, pretty much the layout you see before you on FreeBSD (and the other BSDs), and the layout to which Nathan Arun is objecting. It is also in use (in one bastardized form or another) on many commercial Unix systems. I still have, somewhere in my piles...ummm..*files*, printouts of the graphics, but I have long since lost the accompanying text. So my question is...does anyone out there have a copy of the original posting? If so, I would love to have a copy; it would be interesting to measure current usage against original intent. I have often felt that there has been some "drift", possibly due to the absence of the original design rationales (and other effects). It might be nice to compare it to the Filesystem Hierarchy Standard currently touted at http://www.pathname.com/fhs/, and to the 'hier' (7) man page. It might even be nice to place a copy in /usr/share/doc/history... Mostly, though, I'd just like to do a refresh cycle on my memory, which seems to be coming up with a lot of hard errors these days. -------------- Duane H. Hesser dhh@androcles.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 14: 4:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 90AC037B400 for ; Fri, 25 Jan 2002 14:04:44 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0PM3ZJi028118; Fri, 25 Jan 2002 17:03:35 -0500 (EST) Date: Fri, 25 Jan 2002 17:03:35 -0500 (EST) From: Daniel Eischen To: Terry Lambert Cc: Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51D0B6.F6E04EBC@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 Fri, 25 Jan 2002, Terry Lambert wrote: > Dan Eischen wrote: > > k Macy wrote: > > > I apologize in advance if this is a stupid question, > > > but would it be possible to make it a compile time > > > option, or a pthread_set* function to have getcontext > > > and setcontext be user-level functions for programs > > > that don't use floating point? > > > > In non-threaded programs, getcontext, setcontext, and > > swapcontext always save and restore the signal mask, so > > they would result in system call anyways. The rationale > > is that if you have to make a system call to set the mask, > > you might as well make the whole function a system call > > (and get/set the FPU state as well to avoid a subsequent > > trap when trying to do it in userland). See the long > > thread in -arch about this. > > Can't you handle this with a user space glue trampoline, > with signals being delivered to the process *always*, > but delivered to the user's code based on user space > masking/trapping registrations with the signal code? It's not signal delivery that is the problem, it is the process signal mask. Signals are always delivered to the threads library signal handler which then delivers them to the correct thread. But the threads library keeps track of the process signal mask (as well as installed signal handlers, sa_masks, etc) and can't have the application change them with getcontext/setcontext (since the signal mask is part of ucontext_t). > Then the get/set context would be capable of being in user > space, always, with the exception of programs that use the > FPU. Yes, that is the plan. > The FPU usage is problematic, but is also resolvable, as a > tools issue. > > Specifically, if an ELF section were generated whenever > the compiler generated FPU code (let's call this section > "flags", for the sake of argument), then the flag "FPU=1" > could be set there. [ ... ] Interesting. I think we only care about FPU state during signal deliver and preemptions though, and in that case, the kernel can just pass us the "FPU used" flag and/or "FPU format" along with the interrupted context. When the context is resumed, it can look at the flag/format and see whether it needs to restore the FPU state. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 14:26:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from hawk.prod.itd.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id B433F37B41B for ; Fri, 25 Jan 2002 14:26:10 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by hawk.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UEnF-0005wC-00; Fri, 25 Jan 2002 14:25:58 -0800 Message-ID: <3C51DB71.5CE2010F@mindspring.com> Date: Fri, 25 Jan 2002 14:25:53 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Eischen Cc: Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: 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 Daniel Eischen wrote: > > Can't you handle this with a user space glue trampoline, > > with signals being delivered to the process *always*, > > but delivered to the user's code based on user space > > masking/trapping registrations with the signal code? > > It's not signal delivery that is the problem, it is the > process signal mask. Signals are always delivered to > the threads library signal handler which then delivers > them to the correct thread. But the threads library > keeps track of the process signal mask (as well as > installed signal handlers, sa_masks, etc) and can't have > the application change them with getcontext/setcontext > (since the signal mask is part of ucontext_t). I understand this. I was suggesting moving the process signal masking into user space code, instead, so that there was not system call requirement for manipulating the mask. In other words, always deliver all signals to user space, and then have a user space signal dispatcher that looks at the user space mask, and decides whether to queue a suspended signal deliver, blackhole a blocked one, or invoke a handler. I guess my VMS reference was too obscure. 8-). They did not have signals, per se, in the OS, and so had to use their event delivery mechanisms to emulate them. So there was *only* the user space signal dispatcher. > > The FPU usage is problematic, but is also resolvable, as a > > tools issue. > > > > Specifically, if an ELF section were generated whenever > > the compiler generated FPU code (let's call this section > > "flags", for the sake of argument), then the flag "FPU=1" > > could be set there. > > [ ... ] > > Interesting. I think we only care about FPU state > during signal deliver and preemptions though, and in > that case, the kernel can just pass us the "FPU used" > flag and/or "FPU format" along with the interrupted > context. When the context is resumed, it can look > at the flag/format and see whether it needs to restore > the FPU state. I think this ignores intentional non-signal use of the {s|g}etcontext(), mixed with signal use. I fear that it will not be possible to ignore the state in the case of a setcontext() following a getcontext without the "FPU used" flag, after a later getcontext with the "FPU used" flag. If you can see a way to make this work -- an attempt to setcontext() with the FPU state a context from a prior getcontext() without -- I'd like to understand it. Maybe I'm implying a symmetry that I shouldn't be? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 14:37:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 889C237B41E for ; Fri, 25 Jan 2002 14:37:13 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA19932; Fri, 25 Jan 2002 15:36:49 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0PMamB46264; Fri, 25 Jan 2002 15:36:48 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.56832.170618.611705@caddis.yogotech.com> Date: Fri, 25 Jan 2002 15:36:48 -0700 To: Daniel Eischen Cc: Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: References: <3C51D0B6.F6E04EBC@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 FPU usage is problematic, but is also resolvable, as a > > tools issue. > > > > Specifically, if an ELF section were generated whenever > > the compiler generated FPU code (let's call this section > > "flags", for the sake of argument), then the flag "FPU=1" > > could be set there. > > [ ... ] > > Interesting. I think we only care about FPU state > during signal deliver and preemptions though, and in > that case, the kernel can just pass us the "FPU used" > flag and/or "FPU format" along with the interrupted > context. There's lots of talk about using this 'FPU used' flag, but at least my read of things from the long discussion before was that it may not be possible to implement this on the x86 architectures we currently support. It sounds like a great idea, *IF* if can be done. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 14:57:10 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CE43637B400 for ; Fri, 25 Jan 2002 14:57:07 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0PMtkUA005818; Fri, 25 Jan 2002 17:55:46 -0500 (EST) Date: Fri, 25 Jan 2002 17:55:46 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <15441.56832.170618.611705@caddis.yogotech.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 Fri, 25 Jan 2002, Nate Williams wrote: > > > The FPU usage is problematic, but is also resolvable, as a > > > tools issue. > > > > > > Specifically, if an ELF section were generated whenever > > > the compiler generated FPU code (let's call this section > > > "flags", for the sake of argument), then the flag "FPU=1" > > > could be set there. > > > > [ ... ] > > > > Interesting. I think we only care about FPU state > > during signal deliver and preemptions though, and in > > that case, the kernel can just pass us the "FPU used" > > flag and/or "FPU format" along with the interrupted > > context. > > There's lots of talk about using this 'FPU used' flag, but at least my > read of things from the long discussion before was that it may not be > possible to implement this on the x86 architectures we currently > support. > > It sounds like a great idea, *IF* if can be done. The kernel knows if the FPU has been used and it also knows the format (x87 vs SSE/XMM). As long as the FPU context comes from the kernel, then it can also tell us whether it is valid and it's format. I'm reworking [gs]etcontext; let's hold off on this for a bit and I'll post the changes. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15: 0: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 4EDD037B417 for ; Fri, 25 Jan 2002 14:59:58 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA20828; Fri, 25 Jan 2002 15:59:26 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0PMxOC46426; Fri, 25 Jan 2002 15:59:24 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.58187.656443.659186@caddis.yogotech.com> Date: Fri, 25 Jan 2002 15:59:23 -0700 To: Daniel Eischen Cc: Nate Williams , Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: References: <15441.56832.170618.611705@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 FPU usage is problematic, but is also resolvable, as a > > > > tools issue. > > > > > > > > Specifically, if an ELF section were generated whenever > > > > the compiler generated FPU code (let's call this section > > > > "flags", for the sake of argument), then the flag "FPU=1" > > > > could be set there. > > > > > > [ ... ] > > > > > > Interesting. I think we only care about FPU state > > > during signal deliver and preemptions though, and in > > > that case, the kernel can just pass us the "FPU used" > > > flag and/or "FPU format" along with the interrupted > > > context. > > > > There's lots of talk about using this 'FPU used' flag, but at least my > > read of things from the long discussion before was that it may not be > > possible to implement this on the x86 architectures we currently > > support. > > > > It sounds like a great idea, *IF* if can be done. > > The kernel knows if the FPU has been used and it also knows > the format (x87 vs SSE/XMM). As long as the FPU context > comes from the kernel, then it can also tell us whether > it is valid and it's format. Right, but this has a huge effect on the userlands threads scheduler, since multiple threads can be active during one time-slice, so the userland scheduler will have no way of knowing which thread used the FPU. (At least, not w/out making a system call, defeating most of the advantages of having userland threads...) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15: 4: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from grendel.twistedbit.com (grendel.twistedbit.com [199.79.183.5]) by hub.freebsd.org (Postfix) with ESMTP id 6B1C237B402 for ; Fri, 25 Jan 2002 15:03:58 -0800 (PST) Received: from grendel.twistedbit.com (cp@localhost.tiwstedbit.com [127.0.0.1]) by grendel.twistedbit.com (8.11.3/8.9.3) with ESMTP id g0PN36P13616; Fri, 25 Jan 2002 16:03:07 -0700 (MST) (envelope-from cp@grendel.twistedbit.com) Message-Id: <200201252303.g0PN36P13616@grendel.twistedbit.com> To: nate@yogotech.com (Nate Williams) Cc: Daniel Eischen , Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-reply-to: Your message of "Fri, 25 Jan 2002 15:36:48 MST." <15441.56832.170618.611705@caddis.yogotech.com> From: Chuck Paterson Date: Fri, 25 Jan 2002 16:03:06 -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 You could allow a user process post and address to the kernel for the kernel to update when the FPU goes into the used state. Or for that matter arrange for 1 or more page of kernel space to hold this type of stuff that an a libray to look at them This way you can get at the used bit without the cost of a system call. Chuck ----- Begin Included Message ----- There's lots of talk about using this 'FPU used' flag, but at least my read of things from the long discussion before was that it may not be possible to implement this on the x86 architectures we currently support. It sounds like a great idea, *IF* if can be done. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message ----- End Included Message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:22:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 579D537B400 for ; Fri, 25 Jan 2002 15:22:07 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UFfI-0000mb-00; Fri, 25 Jan 2002 15:21:49 -0800 Message-ID: <3C51E888.FD13A18D@mindspring.com> Date: Fri, 25 Jan 2002 15:21:44 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.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 Nate Williams wrote: > There's lots of talk about using this 'FPU used' flag, but at least my > read of things from the long discussion before was that it may not be > possible to implement this on the x86 architectures we currently > support. > > It sounds like a great idea, *IF* if can be done. Yes, that was my reservation as well. You can do it from first principles using the tool chain, but runtime detection is much, much harder. 8-(. I suggested the toolchain approach in the email to which he was replying to work around this exact problem, in fact. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:24:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 313F037B404 for ; Fri, 25 Jan 2002 15:24:10 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0PNN2Ro009811; Fri, 25 Jan 2002 18:23:02 -0500 (EST) Date: Fri, 25 Jan 2002 18:23:02 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <15441.58187.656443.659186@caddis.yogotech.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 Fri, 25 Jan 2002, Nate Williams wrote: > > > > Interesting. I think we only care about FPU state > > > > during signal deliver and preemptions though, and in > > > > that case, the kernel can just pass us the "FPU used" > > > > flag and/or "FPU format" along with the interrupted > > > > context. > > > > > > There's lots of talk about using this 'FPU used' flag, but at least my > > > read of things from the long discussion before was that it may not be > > > possible to implement this on the x86 architectures we currently > > > support. > > > > > > It sounds like a great idea, *IF* if can be done. > > > > The kernel knows if the FPU has been used and it also knows > > the format (x87 vs SSE/XMM). As long as the FPU context > > comes from the kernel, then it can also tell us whether > > it is valid and it's format. > > Right, but this has a huge effect on the userlands threads scheduler, > since multiple threads can be active during one time-slice, so the > userland scheduler will have no way of knowing which thread used the > FPU. (At least, not w/out making a system call, defeating most of the > advantages of having userland threads...) I think it only matters when threads are preempted or trap. As long as the kernel can tell the difference between preempted/trapped (kernel) threads, then it can copy or not copy the FPU state out to the per-thread mailbox and flag the FPU state accordingly. Can't we treat normal system calls as we would library routines (if you call a function then shouldn't the compiler assume the FPU state could be trashed and be forced to save and restore FPU state that it needs?). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:24:51 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 5218137B426 for ; Fri, 25 Jan 2002 15:24:39 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA21831; Fri, 25 Jan 2002 16:24:30 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0PNOTL46567; Fri, 25 Jan 2002 16:24:29 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.59691.361172.394760@caddis.yogotech.com> Date: Fri, 25 Jan 2002 16:24:27 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51E888.FD13A18D@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > There's lots of talk about using this 'FPU used' flag, but at least my > > read of things from the long discussion before was that it may not be > > possible to implement this on the x86 architectures we currently > > support. > > > > It sounds like a great idea, *IF* if can be done. > > Yes, that was my reservation as well. You can do it from > first principles using the tool chain Not easily. The toolchain may not know the software is using the FPU in interpreted languages (at least, in any effecient manner). You could stick in all sorts of funky hooks, but because threads can be intererupted at any time, the amount of checking that still needs to occur at runtime would make a compile-time solution un-necessarily slow. (MHO of course). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:26:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 6793737B427 for ; Fri, 25 Jan 2002 15:26:47 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id QAA21931; Fri, 25 Jan 2002 16:26:39 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0PNQct46601; Fri, 25 Jan 2002 16:26:38 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.59822.481182.325298@caddis.yogotech.com> Date: Fri, 25 Jan 2002 16:26:38 -0700 To: Daniel Eischen Cc: Nate Williams , Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: References: <15441.58187.656443.659186@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > > > Interesting. I think we only care about FPU state > > > > > during signal deliver and preemptions though, and in > > > > > that case, the kernel can just pass us the "FPU used" > > > > > flag and/or "FPU format" along with the interrupted > > > > > context. > > > > > > > > There's lots of talk about using this 'FPU used' flag, but at least my > > > > read of things from the long discussion before was that it may not be > > > > possible to implement this on the x86 architectures we currently > > > > support. > > > > > > > > It sounds like a great idea, *IF* if can be done. > > > > > > The kernel knows if the FPU has been used and it also knows > > > the format (x87 vs SSE/XMM). As long as the FPU context > > > comes from the kernel, then it can also tell us whether > > > it is valid and it's format. > > > > Right, but this has a huge effect on the userlands threads scheduler, > > since multiple threads can be active during one time-slice, so the > > userland scheduler will have no way of knowing which thread used the > > FPU. (At least, not w/out making a system call, defeating most of the > > advantages of having userland threads...) > > I think it only matters when threads are preempted or trap. With KSE's, won't threads be pre-empted? (I guess they won't unless you get an upcall from the kernel, so the flag could get set.) > As long as the kernel can tell the difference between > preempted/trapped (kernel) threads, then it can copy > or not copy the FPU state out to the per-thread mailbox > and flag the FPU state accordingly. Good point. > Can't we treat normal system calls as we would library routines (if > you call a function then shouldn't the compiler assume the FPU state > could be trashed and be forced to save and restore FPU state that it > needs?). This is much less effecient, since the kernel normally doesn't touch the FPU state. (FPU operations in the kernel are illegal currently.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:39:15 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 21D5F37B400 for ; Fri, 25 Jan 2002 15:39:12 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UFvs-0005wg-00; Fri, 25 Jan 2002 15:38:57 -0800 Message-ID: <3C51EC04.D99E8491@mindspring.com> Date: Fri, 25 Jan 2002 15:36:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <15441.56832.170618.611705@caddis.yogotech.com> <15441.58187.656443.659186@caddis.yogotech.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 Nate Williams wrote: > > The kernel knows if the FPU has been used and it also knows > > the format (x87 vs SSE/XMM). As long as the FPU context > > comes from the kernel, then it can also tell us whether > > it is valid and it's format. > > Right, but this has a huge effect on the userlands threads scheduler, > since multiple threads can be active during one time-slice, so the > userland scheduler will have no way of knowing which thread used the > FPU. (At least, not w/out making a system call, defeating most of the > advantages of having userland threads...) I agree. The worst case scenario is: 1) Multithreaded program on SMP system 2) FPU thread runs on CPU #1 and causes, but does not reap exception 3) Non-FPU thread runs on CPU #1 4) Original FPU thread resumes running on CPU #2; no exception is correctly signalled Really, you must know at the point of context switch, so you can force the exception delivery at the point of thread migration to another processor. This means it has to be done at the KSE granularity, which means (potentially) mapping up to the thread granularity, rather than at a simple process granularity. With threads but without SMP, the other approach works, and without threads but with SMP, the other approach also works (in fact, it is the basis of the lazy task switching code in the current non-threaded case). But when you have a program with threads with SMP, then you are screwed, unless you know that it's an FPU using program *beforehand* (i.e. it is possible for one CPU to know that a threaded FPU using program is running, while the other CPU does not yet know this, and thus lose an exception or FPU context when migrating a thread in a signle process from the CPU that knows to the one that doesn't (yet) know). If there's a flaw in my reasoning, I'd be happy to have it pointed out to me... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:44: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0316537B400 for ; Fri, 25 Jan 2002 15:44:02 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0PNgs1l012307; Fri, 25 Jan 2002 18:42:54 -0500 (EST) Date: Fri, 25 Jan 2002 18:42:54 -0500 (EST) From: Daniel Eischen To: Nate Williams Cc: Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <15441.59822.481182.325298@caddis.yogotech.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 Fri, 25 Jan 2002, Nate Williams wrote: > > > > The kernel knows if the FPU has been used and it also knows > > > > the format (x87 vs SSE/XMM). As long as the FPU context > > > > comes from the kernel, then it can also tell us whether > > > > it is valid and it's format. > > > > > > Right, but this has a huge effect on the userlands threads scheduler, > > > since multiple threads can be active during one time-slice, so the > > > userland scheduler will have no way of knowing which thread used the > > > FPU. (At least, not w/out making a system call, defeating most of the > > > advantages of having userland threads...) > > > > I think it only matters when threads are preempted or trap. > > With KSE's, won't threads be pre-empted? (I guess they won't unless you > get an upcall from the kernel, so the flag could get set.) I'm not sure, but if you resume a preempted thread without running any other threads or signal handlers in between, then you don't have to restore the FPU state anyways. It'll still be in the pcb and the next trap will load it into the FPU. Unless the thread is allowed to migrate between KSEs... > > As long as the kernel can tell the difference between > > preempted/trapped (kernel) threads, then it can copy > > or not copy the FPU state out to the per-thread mailbox > > and flag the FPU state accordingly. > > Good point. > > > Can't we treat normal system calls as we would library routines (if > > you call a function then shouldn't the compiler assume the FPU state > > could be trashed and be forced to save and restore FPU state that it > > needs?). > > This is much less effecient, since the kernel normally doesn't touch the > FPU state. (FPU operations in the kernel are illegal currently.) A system call looks the same way to an application as any other library routine doesn't it? The compiler doesn't know that sigprocmask() is different than scanf(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 15:49:19 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 8A58537B41D for ; Fri, 25 Jan 2002 15:49:11 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UG5U-0002Dy-00; Fri, 25 Jan 2002 15:48:52 -0800 Message-ID: <3C51EEDF.E1439C5B@mindspring.com> Date: Fri, 25 Jan 2002 15:48:47 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chuck Paterson Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <200201252303.g0PN36P13616@grendel.twistedbit.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 Chuck Paterson wrote: > You could allow a user process post and address to the kernel for the > kernel to update when the FPU goes into the used state. Or for that > matter arrange for 1 or more page of kernel space to hold this type > of stuff that an a libray to look at them > > This way you can get at the used bit without the cost of a system > call. Consider the following case, where you are doing this: You are running on two CPUs with a combination of FPU using and non-FPU using threads. An FPU using thread is running on one machine, enters the user space threads scheduler, and there is a time slice based invluntary context switch, leaving that instance of the backing KSE associated with code that is in the user space scheduler. Now some FPU using threads tasks which were running on the suspended-in-the-scheduler CPU complete (e.g. disk or network I/O waits), and are resumed on the second CPU. What happens if there was an FPU exception pending, but not delivered at the time of the involuntary context switch, such that the copy out of the FPU state does not end up where it was expected? Then once again, you are screwed. I don't see a way to get around this, without locking, or an IPI between CPUs running the threads of a single program, to notify one scheduler from the other that the program has started using the FPU. Even doing this would require setting the FPU disable bit, taking the fault, handling by enabling it on a per process basis, and doing an IPI to any other CPU also serving the thread, *before* returning from handling the fault. Any other approach leaves large race windows. I think if you *knew*, up front, that the program was capable of using the FPU, or if you *knew* when it loaded code that would be capable of using it, that you would be covered. The only case this would break down would be code that could generate FPU code and execute it, all by itself (this might be a JIT/JVM issue: Nate should comment ...though I think it unlikely that you would generate FPU instructions without having any yourself). The fix for this would be to have a compiler or linker flag to force the setting of the "FPU=1" flag, even if no FPU instructions are generated by the compiler. In fact, a more elegant way to handle this would be to put a "#pragma flagsection("FPU=1")" into the code where it generates the offending FPU instructions; you could use it for other nifty flags, later, as well. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16: 0:36 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 32B7037B402 for ; Fri, 25 Jan 2002 16:00:29 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UGGV-0003Nn-00; Fri, 25 Jan 2002 16:00:16 -0800 Message-ID: <3C51F18A.C0D8D6B1@mindspring.com> Date: Fri, 25 Jan 2002 16:00:10 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.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 Nate Williams wrote: > > Yes, that was my reservation as well. You can do it from > > first principles using the tool chain > > Not easily. The toolchain may not know the software is using the FPU in > interpreted languages (at least, in any effecient manner). #pragma flagsection("FPU=1") Ugly, I know. The other option is a linker flag. > You could stick in all sorts of funky hooks, but because threads can be > intererupted at any time, the amount of checking that still needs to > occur at runtime would make a compile-time solution un-necessarily > slow. (MHO of course). Actually, the runtime checking is incredibly easy, if you *know* the program can use the FPU: just switch totally away from lazy binding at all. The reason it exists at all is "in case someone uses the FPU". If you know they won't, it makes the rest of the code run faster, which is probably an acceptable tradeoff. The signalling overhead in the "didn't-use-it-now-I-do" case is a real PITA to ensure that multiple CPU threded programs DTRT. 8-(. Better to eat the overhead by default, and optimize later. I think flagging the programs at the toolchain level is "low hanging fruit", where doing a full on dynamic binding of FPU state might end up being a very long term project. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16: 5: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 721F337B416 for ; Fri, 25 Jan 2002 16:04:38 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA23439; Fri, 25 Jan 2002 17:04:30 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q04TG46751; Fri, 25 Jan 2002 17:04:29 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.62092.864056.841853@caddis.yogotech.com> Date: Fri, 25 Jan 2002 17:04:28 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51F18A.C0D8D6B1@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > You could stick in all sorts of funky hooks, but because threads can be > > intererupted at any time, the amount of checking that still needs to > > occur at runtime would make a compile-time solution un-necessarily > > slow. (MHO of course). > > Actually, the runtime checking is incredibly easy, if you > *know* the program can use the FPU: just switch totally > away from lazy binding at all. This is extremely inefficient for interpreted languages, where they *may* use the FPU, but it's not obvious until runtime whether or not they *will* use the FPU. (FPU usage is till a rarity in comparison to the total runtime of the program.) And, when you have threaded interpreted languages it gets even more exciting, since now you take the hit for every userland context switch, even though you probably didn't use the FPU (since you didn't know). This is the state of the art in the current x86/unix JVMs (not just in FreeBSD, but in Solaris and Linux as well). > The reason it exists at all is "in case someone uses the FPU". If you > know they won't, it makes the rest of the code run faster, which is > probably an acceptable tradeoff. I still don't consider this a workable solution, since there are as many exceptions as there are standard cases. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16:13:21 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 5513F37B416 for ; Fri, 25 Jan 2002 16:13:15 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UGT1-0003a3-00; Fri, 25 Jan 2002 16:13:11 -0800 Message-ID: <3C51F492.CB0FB69E@mindspring.com> Date: Fri, 25 Jan 2002 16:13:06 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.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 Nate Williams wrote: > > > You could stick in all sorts of funky hooks, but because threads can be > > > intererupted at any time, the amount of checking that still needs to > > > occur at runtime would make a compile-time solution un-necessarily > > > slow. (MHO of course). > > > > Actually, the runtime checking is incredibly easy, if you > > *know* the program can use the FPU: just switch totally > > away from lazy binding at all. > > This is extremely inefficient for interpreted languages, where they > *may* use the FPU, but it's not obvious until runtime whether or not > they *will* use the FPU. (FPU usage is till a rarity in comparison to > the total runtime of the program.) I think the way I would handle this for Java, for example, is to do the swicth when the JNI code for the FPU access code is loaded. This would only happen when you actually go to JIT FPU code out. > And, when you have threaded interpreted languages it gets even more > exciting, since now you take the hit for every userland context switch, > even though you probably didn't use the FPU (since you didn't know). This is the real problem: you can't safely do mixed FPU and non-FPU access, if your threads can move between processors without user space threads scheduler interaction in this case. I really don't want to mandate that that happen, for obvious reasons. It's possible to lazy-bind FPU use to the first use in a program, if you use IPI signalling between the user space threads schedulers running on multiple CPUs. I really can't see a way around getting rid of the lazy binding in the FPU using case on multiple threads on multiple CPUs. You might be able to squeak by, if you *knew* that there was only one thread doing the FPU access, but it would be a bear to get right. Hence my punting to "optimize later". 8-(. > This is the state of the art in the current x86/unix JVMs (not just in > FreeBSD, but in Solaris and Linux as well). Yes, understood. > > The reason it exists at all is "in case someone uses the FPU". If you > > know they won't, it makes the rest of the code run faster, which is > > probably an acceptable tradeoff. > > I still don't consider this a workable solution, since there are as many > exceptions as there are standard cases. Unfortunately, we can't fix the base problem, which is "delayed exception signalling on x86 FPUs sucks". 8-). I think the only thing we can do is guarantee correctness. Right now, I'm just trying to avoid dragging everyone down with the FPU using code, which I think, *has* to drag down, at this point. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16:15:57 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 F335737B402 for ; Fri, 25 Jan 2002 16:15:54 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UGVb-0006ng-00; Fri, 25 Jan 2002 16:15:51 -0800 Message-ID: <3C51F532.87ADF4A5@mindspring.com> Date: Fri, 25 Jan 2002 16:15:46 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.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 Replying to myself... Terry Lambert wrote: > Unfortunately, we can't fix the base problem, which is > "delayed exception signalling on x86 FPUs sucks". 8-). > > I think the only thing we can do is guarantee correctness. > > Right now, I'm just trying to avoid dragging everyone down > with the FPU using code, which I think, *has* to drag down, > at this point. 8-(. It occurs to me that if we could limit the FPU using code to the model where there is one KSE per user space thread, then we get what Linux threads has now, and can do lazy binding. Obviously, there's a performance penalty to that approach, as well, but I think we are going to have to pay the piper one way or the other, if we use the FPU. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16:17: 1 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3826337B41D for ; Fri, 25 Jan 2002 16:16:54 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA23957; Fri, 25 Jan 2002 17:16:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q0Gk746863; Fri, 25 Jan 2002 17:16:46 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.62830.180895.121111@caddis.yogotech.com> Date: Fri, 25 Jan 2002 17:16:46 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51F492.CB0FB69E@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > > You could stick in all sorts of funky hooks, but because threads can be > > > > intererupted at any time, the amount of checking that still needs to > > > > occur at runtime would make a compile-time solution un-necessarily > > > > slow. (MHO of course). > > > > > > Actually, the runtime checking is incredibly easy, if you > > > *know* the program can use the FPU: just switch totally > > > away from lazy binding at all. > > > > This is extremely inefficient for interpreted languages, where they > > *may* use the FPU, but it's not obvious until runtime whether or not > > they *will* use the FPU. (FPU usage is till a rarity in comparison to > > the total runtime of the program.) > > I think the way I would handle this for Java, for example, > is to do the swicth when the JNI code for the FPU access > code is loaded. What JNI code? It's an interpreted language, so you just make 'normal' function calls as you would a normal program. Are you implying that we hack up the Java code to set a flag saying we've used the FPU anytime a call is done? How do we know when to clear this flag? This is a complete and utter hack (IMO). > > And, when you have threaded interpreted languages it gets even more > > exciting, since now you take the hit for every userland context switch, > > even though you probably didn't use the FPU (since you didn't know). > > This is the real problem: you can't safely do mixed FPU and > non-FPU access, if your threads can move between processors > without user space threads scheduler interaction in this case. > > I really don't want to mandate that that happen, for obvious > reasons. But it will, whether you like it or not. Part of the responsibility in being a 'general purpose OS' is that you don't get to dictate what people use it for. [ SNIP ] > Hence my punting to "optimize later". 8-(. Otherwise known as not having a complete solution to the problem, hence not having a solution at all. :( > > > The reason it exists at all is "in case someone uses the FPU". If you > > > know they won't, it makes the rest of the code run faster, which is > > > probably an acceptable tradeoff. > > > > I still don't consider this a workable solution, since there are as many > > exceptions as there are standard cases. > > Unfortunately, we can't fix the base problem, which is > "delayed exception signalling on x86 FPUs sucks". 8-). On the money! We are in violent agreement for once. :) :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16:30:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 3D40437B400 for ; Fri, 25 Jan 2002 16:30:52 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UGji-0006Z8-00; Fri, 25 Jan 2002 16:30:27 -0800 Message-ID: <3C51F89E.78DAD01D@mindspring.com> Date: Fri, 25 Jan 2002 16:30:22 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.com> <15441.62830.180895.121111@caddis.yogotech.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 Nate Williams wrote: > > I think the way I would handle this for Java, for example, > > is to do the swicth when the JNI code for the FPU access > > code is loaded. > > What JNI code? It's an interpreted language, so you just make 'normal' > function calls as you would a normal program. Are you implying that we > hack up the Java code to set a flag saying we've used the FPU anytime a > call is done? How do we know when to clear this flag? You never clear it, once it is set. > This is a complete and utter hack (IMO). Yes. See my reply to myself, for a possible workaround. > > > And, when you have threaded interpreted languages it gets even more > > > exciting, since now you take the hit for every userland context switch, > > > even though you probably didn't use the FPU (since you didn't know). > > > > This is the real problem: you can't safely do mixed FPU and > > non-FPU access, if your threads can move between processors > > without user space threads scheduler interaction in this case. > > > > I really don't want to mandate that that happen, for obvious > > reasons. > > But it will, whether you like it or not. Part of the responsibility in > being a 'general purpose OS' is that you don't get to dictate what > people use it for. A "might use FPU" flag is about as general purpose as you can get and still segregate non-FPU from FPU use. The only other alternative is to not segrgate it at all, and then you incur the overhead everywhere, rather than just in programs that offend the gods of bad FPU design. > [ SNIP ] > > > Hence my punting to "optimize later". 8-(. > > Otherwise known as not having a complete solution to the problem, hence > not having a solution at all. :( It maps the problem space, so it's a complete solution. I admit is a far cry from an optimal solution, if you risk the FPU at all, since you pay to get into the part of the theme park where the roller coaster is located, whether or not you actually get on the roller coaster, or just ride the bumper cars. One way around this would be to compile your Java programs to native code, but that's ugly, too, and has corner cases when you grab serialized objects out of a directory or whereever, and have to fall back to the JVM to access the member functions, which might use the FPU. 8-(. > > > > The reason it exists at all is "in case someone uses the FPU". If you > > > > know they won't, it makes the rest of the code run faster, which is > > > > probably an acceptable tradeoff. > > > > > > I still don't consider this a workable solution, since there are as many > > > exceptions as there are standard cases. > > > > Unfortunately, we can't fix the base problem, which is > > "delayed exception signalling on x86 FPUs sucks". 8-). > > On the money! We are in violent agreement for once. :) :) :) :) Cool! Let's just dike the thing out! I know, we can compile the FPU emulation library into user space, and not use the hardware FPU at all. Then we can fix the emulated FPU, and the problem goes away. 8-) 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16:34:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 0503D37B404 for ; Fri, 25 Jan 2002 16:34:24 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA24644; Fri, 25 Jan 2002 17:34:13 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q0YCe46916; Fri, 25 Jan 2002 17:34:12 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.63876.271856.290838@caddis.yogotech.com> Date: Fri, 25 Jan 2002 17:34:12 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51F89E.78DAD01D@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.com> <15441.62830.180895.121111@caddis.yogotech.com> <3C51F89E.78DAD01D@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > [ SNIP ] > > > > > Hence my punting to "optimize later". 8-(. > > > > Otherwise known as not having a complete solution to the problem, hence > > not having a solution at all. :( > > It maps the problem space, so it's a complete solution. No, it doesn't. It's a 75% solution, and the remaining 25% is extremely common. Not an acceptable solution. > One way around this would be to compile your Java programs > to native code, but that's ugly, too, and has corner cases > when you grab serialized objects out of a directory or > whereever, and have to fall back to the JVM to access the > member functions, which might use the FPU. 8-(. Plus, it's not possible to do, since there are no 'Good' java->native code compilers for FreeBSD. (There is only one decent compiler out, and it isn't ported to FreeBSD. And, GCC is *NOT* that compiler, as it's Java stuff isn't useful for anything real.) > > > Unfortunately, we can't fix the base problem, which is > > > "delayed exception signalling on x86 FPUs sucks". 8-). > > > > On the money! We are in violent agreement for once. :) :) :) :) > > Cool! Let's just dike the thing out! > > I know, we can compile the FPU emulation library into user > space, and not use the hardware FPU at all. Then we can fix > the emulated FPU, and the problem goes away. 8-) 8-) 8-). Yeah, sure. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 16:58:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by hub.freebsd.org (Postfix) with ESMTP id DF64537B404 for ; Fri, 25 Jan 2002 16:58:08 -0800 (PST) Received: from pool0218.cvx21-bradley.dialup.earthlink.net ([209.179.192.218] helo=mindspring.com) by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UHAF-000484-00; Fri, 25 Jan 2002 16:57:52 -0800 Message-ID: <3C51FF0A.9ACAC316@mindspring.com> Date: Fri, 25 Jan 2002 16:57:46 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.com> <15441.62830.180895.121111@caddis.yogotech.com> <3C51F89E.78DAD01D@mindspring.com> <15441.63876.271856.290838@caddis.yogotech.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 Nate Williams wrote: > > > Otherwise known as not having a complete solution to the problem, hence > > > not having a solution at all. :( > > > > It maps the problem space, so it's a complete solution. > > No, it doesn't. It's a 75% solution, and the remaining 25% is extremely > common. Not an acceptable solution. FPU usage is uncommon. If it were 51% common, we'd just pay the cost of switching it all the time, and this discussion would not have started. The problem with any interpreted language that permits the use of the FPU is that you have a hard time knowing ahead of time whether or not you need to pay the penalty. If we exclude these languages as being sufficiently slow because they are interpreted that the FPU overhead will be comparatively miniscule, then we are left with caching JITed languages, which include LISP and Java, among other things, and Java is incredibly popular. I don't know how to answer the question except to say that there is a trade-off between FPU lazy binding, and full quantum utilization achieved by not having a 1:1 mapping between kernel and user space threads. I think that the trade-off is going to have to be made, one way or the other. I can see beaing able to deal with this using a vastly more complex user space scheduler. At this point, I'd say that such a scheduler was a LISP and Java specific problem, and not a general problem for optimization of the system. > > One way around this would be to compile your Java programs > > to native code, but that's ugly, too, and has corner cases > > when you grab serialized objects out of a directory or > > whereever, and have to fall back to the JVM to access the > > member functions, which might use the FPU. 8-(. > > Plus, it's not possible to do, since there are no 'Good' java->native > code compilers for FreeBSD. (There is only one decent compiler out, and > it isn't ported to FreeBSD. And, GCC is *NOT* that compiler, as it's > Java stuff isn't useful for anything real.) 8^). We agree on two things, now. 8-) 8-). > > Cool! Let's just dike the thing out! > > > > I know, we can compile the FPU emulation library into user > > space, and not use the hardware FPU at all. Then we can fix > > the emulated FPU, and the problem goes away. 8-) 8-) 8-). > > Yeah, sure. How about this: force trigger the exception before context switching away, if the FPU has been used. There won't be an exception necessarily, but since we are in the kernel scheduler, we can do this before we switch away, and the fact that we are in the scheduler means we can do it before a migration or other dangerous event occurs. This effectively would non-lazy bind the FPU state. This can be done lazily anyway, until we know we have more than one CPU *and* are running a threaded program *and* can be scheduled on more than one CPU simlutaneously, so it only starts happening after you meet all those conditions, AND use the FPU. That pushes the overhead out into mutithreaded SMP using programs, where it's going to have to be there anyway. It has the side benefit that the force only occurs *after* use of the FPU, so a JVM running a lot of threads over a long period of time will not keep taking the overhead unless the thread being run accesses the FPU (forcing the force), so a JVM with 10,000 threads that runs one transient FPU using thread once, and never runs one again, doesn't take the overhead all the time. The downside is that extra code has to be run on task switch to (1) check if the FPU was used and (2) execute a barrier that forces pending exceptions (if any) to occur. This could be further delayed by not doing it unless the context swithc was *(away* from the program being run (i.e. using up your quantum, if you are just going to run again doesn't cause the overhead, so you aren't eating it every LBOLT interval -- this is how the lazy stuff works already, so it's not even any extra checks for that particular case). ??? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 17: 9:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 870A437B400; Fri, 25 Jan 2002 17:09:32 -0800 (PST) Received: from bmah.dyndns.org ([12.233.149.189]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020126010932.IPMD3578.rwcrmhc52.attbi.com@bmah.dyndns.org>; Sat, 26 Jan 2002 01:09:32 +0000 Received: (from bmah@localhost) by bmah.dyndns.org (8.11.6/8.11.6) id g0Q19Vo80317; Fri, 25 Jan 2002 17:09:31 -0800 (PST) (envelope-from bmah) Message-Id: <200201260109.g0Q19Vo80317@bmah.dyndns.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Sheldon Hearn Cc: Mike Makonnen , "Crist J. Clark" , arch@FreeBSD.ORG Subject: Re: Changing rc.conf(5) firewall_enable In-reply-to: <58963.1011959800@axl.seasidesoftware.co.za> References: <58963.1011959800@axl.seasidesoftware.co.za> Comments: In-reply-to Sheldon Hearn message dated "Fri, 25 Jan 2002 13:56:40 +0200." From: "Bruce A. Mah" Reply-To: bmah@FreeBSD.ORG X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jan 2002 17:09:31 -0800 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 If memory serves me right, Sheldon Hearn wrote: > On Fri, 25 Jan 2002 03:11:29 PST, Mike Makonnen wrote: > > > This should probably be mentioned in UPDATING. > > And if firewall_enable="NO" changes to mean "turn off firewalling" in > 4.5-RELEASE, that's probably okay too, because Bruce does such a > brilliant job with the release notes. :-) Thanks. Is this some kind of weird test to see how often I read my email? :-) Bruce. PS. And yes, I know you're kidding about changing the semantics of firewall_enable less than 48 hours before the release. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 17:40:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 1905C37B402 for ; Fri, 25 Jan 2002 17:40:07 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020126014006.JLOW3578.rwcrmhc52.attbi.com@InterJet.elischer.org> for ; Sat, 26 Jan 2002 01:40:06 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA34240 for ; Fri, 25 Jan 2002 17:25:53 -0800 (PST) Date: Fri, 25 Jan 2002 17:25:52 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: KSE milestone 3 ALMOST there. 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 I just hought I'd share with everyone here the following extract from ddb's "ps" command. (sorry about any linewrap). db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 566 ce7b8580 cf1d1000 0 313 566 000c002 Normal (threaded) ksetest . . . . . . . . thread 0xcdb589c0 . . . --not blocked-- . . . . . . . . thread 0xcdb59140 . . . --not blocked-- 313 ce7b8080 cf1e1000 0 1 313 2004002 Normal pause cf1e1000 csh 312 ce7b9200 cf196000 0 1 312 0004002 Normal ttyin c2633010 getty 311 ce7b7e00 cf1e6000 0 1 311 0004002 Normal ttyin c2558e10 getty 269 ce7b8800 cf1c2000 0 1 269 0000000 Normal select c0405308 sshd [...] Of course I got into ddb because of a page fault :-) so it's not quite there yet. but...... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 21:28: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 634C137B402 for ; Fri, 25 Jan 2002 21:28:06 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.12.1/8.12.1) id g0Q5QsMQ025339; Sat, 26 Jan 2002 00:26:54 -0500 (EST) Date: Sat, 26 Jan 2002 00:26:54 -0500 (EST) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: KSE milestone 3 ALMOST there. 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 Fri, 25 Jan 2002, Julian Elischer wrote: > > > I just hought I'd share with everyone here the following > extract from ddb's "ps" command. (sorry about any linewrap). > > db> ps > pid proc addr uid ppid pgrp flag stat wmesg wchan cmd > 566 ce7b8580 cf1d1000 0 313 566 000c002 Normal (threaded) ksetest > . . . . . . . . thread 0xcdb589c0 . . . --not blocked-- > . . . . . . . . thread 0xcdb59140 . . . --not blocked-- Nice! > Of course I got into ddb because of a page fault :-) > so it's not quite there yet. but...... Is it stable enough for non KSE'd processes to be committed? -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 21:37:30 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 27BA837B41D for ; Fri, 25 Jan 2002 21:37:17 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA06425; Fri, 25 Jan 2002 22:36:44 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q5aUD47592; Fri, 25 Jan 2002 22:36:31 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15442.16478.408033.680185@caddis.yogotech.com> Date: Fri, 25 Jan 2002 22:36:30 -0700 To: Terry Lambert Cc: Nate Williams , Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: <3C51FF0A.9ACAC316@mindspring.com> References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.com> <15441.62830.180895.121111@caddis.yogotech.com> <3C51F89E.78DAD01D@mindspring.com> <15441.63876.271856.290838@caddis.yogotech.com> <3C51FF0A.9ACAC316@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > > Otherwise known as not having a complete solution to the problem, hence > > > > not having a solution at all. :( > > > > > > It maps the problem space, so it's a complete solution. > > > > No, it doesn't. It's a 75% solution, and the remaining 25% is extremely > > common. Not an acceptable solution. > > FPU usage is uncommon. If it were 51% common, we'd just pay > the cost of switching it all the time, and this discussion > would not have started. Depends on what you consider common. I'll bet that a significant percentage of programs use the FPU. However, they use the FPU *very* little in the total amount of time used. So, even if they use it once, that's enough to cause problems if you don't handle it correctly. > > Plus, it's not possible to do, since there are no 'Good' java->native > > code compilers for FreeBSD. (There is only one decent compiler out, and > > it isn't ported to FreeBSD. And, GCC is *NOT* that compiler, as it's > > Java stuff isn't useful for anything real.) > > 8^). We agree on two things, now. 8-) 8-). Wow. Better write it on my calendar. > > > Cool! Let's just dike the thing out! > > > > > > I know, we can compile the FPU emulation library into user > > > space, and not use the hardware FPU at all. Then we can fix > > > the emulated FPU, and the problem goes away. 8-) 8-) 8-). > > > > Yeah, sure. > > How about this: force trigger the exception before context > switching away, if the FPU has been used. Again, the issue is that we can't determine *IF* the FPU has been used effeciently. All solutions assume this solution, although Daniel's may have a way of short-circuiting this in the short term. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 21:44: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id A417437B400 for ; Fri, 25 Jan 2002 21:44:05 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA06667; Fri, 25 Jan 2002 22:42:50 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0Q5gnF47638; Fri, 25 Jan 2002 22:42:49 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15442.16857.446446.208426@caddis.yogotech.com> Date: Fri, 25 Jan 2002 22:42:49 -0700 To: Daniel Eischen Cc: Nate Williams , Terry Lambert , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question In-Reply-To: References: <15441.59822.481182.325298@caddis.yogotech.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 kernel knows if the FPU has been used and it also knows > > > > > the format (x87 vs SSE/XMM). As long as the FPU context > > > > > comes from the kernel, then it can also tell us whether > > > > > it is valid and it's format. > > > > > > > > Right, but this has a huge effect on the userlands threads scheduler, > > > > since multiple threads can be active during one time-slice, so the > > > > userland scheduler will have no way of knowing which thread used the > > > > FPU. (At least, not w/out making a system call, defeating most of the > > > > advantages of having userland threads...) > > > > > > I think it only matters when threads are preempted or trap. > > > > With KSE's, won't threads be pre-empted? (I guess they won't unless you > > get an upcall from the kernel, so the flag could get set.) > > I'm not sure, but if you resume a preempted thread without > running any other threads or signal handlers in between, then > you don't have to restore the FPU state anyways. Possibly. > It'll still > be in the pcb and the next trap will load it into the FPU. > Unless the thread is allowed to migrate between KSEs... Eggsactly. :) > > > Can't we treat normal system calls as we would library routines (if > > > you call a function then shouldn't the compiler assume the FPU state > > > could be trashed and be forced to save and restore FPU state that it > > > needs?). > > > > This is much less effecient, since the kernel normally doesn't touch the > > FPU state. (FPU operations in the kernel are illegal currently.) > > A system call looks the same way to an application as any other > library routine doesn't it? Usually, but not always. But, it causes the application to give up it's current scheduling slot, which isn't optimum. > The compiler doesn't know that sigprocmask() is different than > scanf(). Right, but scanf doesn't require saving/restoring the FPU context, while system calls might. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 25 23:40:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id C8E7137B41B for ; Fri, 25 Jan 2002 23:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020126074008.XGQV26243.rwcrmhc51.attbi.com@InterJet.elischer.org>; Sat, 26 Jan 2002 07:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA35370; Fri, 25 Jan 2002 23:34:14 -0800 (PST) Date: Fri, 25 Jan 2002 23:34:13 -0800 (PST) From: Julian Elischer To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: KSE milestone 3 ALMOST there. 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 probably not. I had to change a lot of things so that they used a new algorythm that degenerated to teh same as the old alorythm in a 1:1 case. That new code is still being run in the 1:1 case. Having said that, yes it runs but I think that signals are probably at least partially broken and debugging support is probably broken too. I haven't got the 2nd thread out to userland yet.. (today's task) On Sat, 26 Jan 2002, Daniel Eischen wrote: > On Fri, 25 Jan 2002, Julian Elischer wrote: > > > > > > I just hought I'd share with everyone here the following > > extract from ddb's "ps" command. (sorry about any linewrap). > > > > db> ps > > pid proc addr uid ppid pgrp flag stat wmesg wchan cmd > > 566 ce7b8580 cf1d1000 0 313 566 000c002 Normal (threaded) ksetest > > . . . . . . . . thread 0xcdb589c0 . . . --not blocked-- > > . . . . . . . . thread 0xcdb59140 . . . --not blocked-- > > Nice! > > > Of course I got into ddb because of a page fault :-) > > so it's not quite there yet. but...... > > Is it stable enough for non KSE'd processes to be committed? > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 0:52:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 4C7C437B404 for ; Sat, 26 Jan 2002 00:52:09 -0800 (PST) Received: from pool0040.cvx40-bradley.dialup.earthlink.net ([216.244.42.40] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16UOZ0-0006QM-00; Sat, 26 Jan 2002 00:51:54 -0800 Message-ID: <3C526E25.3B72F578@mindspring.com> Date: Sat, 26 Jan 2002 00:51:49 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Daniel Eischen , Dan Eischen , k Macy , Peter Wemm , Julian Elischer , arch@FreeBSD.ORG Subject: Re: KSE question References: <3C51D0B6.F6E04EBC@mindspring.com> <15441.56832.170618.611705@caddis.yogotech.com> <3C51E888.FD13A18D@mindspring.com> <15441.59691.361172.394760@caddis.yogotech.com> <3C51F18A.C0D8D6B1@mindspring.com> <15441.62092.864056.841853@caddis.yogotech.com> <3C51F492.CB0FB69E@mindspring.com> <15441.62830.180895.121111@caddis.yogotech.com> <3C51F89E.78DAD01D@mindspring.com> <15441.63876.271856.290838@caddis.yogotech.com> <3C51FF0A.9ACAC316@mindspring.com> <15442.16478.408033.680185@caddis.yogotech.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 Nate Williams wrote: > Again, the issue is that we can't determine *IF* the FPU has been used > effeciently. All solutions assume this solution, although Daniel's may > have a way of short-circuiting this in the short term. Disable it in the processor when context switching in code that doesn't have it marked enabled (this can be lazy bound as well: the default state will be disabled. When the first access by a program occurs, it will get an instruction fault. Handle the fault by setting an "FPU used" flag, and then enabling it and restarting the instruction. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 6: 8:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from heroica.upt.edu.pe (heroica.upt.edu.pe [200.37.191.2]) by hub.freebsd.org (Postfix) with ESMTP id CA78137B417 for ; Sat, 26 Jan 2002 06:08:43 -0800 (PST) Received: from msn.com (adsl-65-71-118-145.dsl.hstntx.swbell.net [65.71.118.145]) by heroica.upt.edu.pe with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D4VX2K10; Sat, 26 Jan 2002 09:00:13 -0500 Message-ID: <00000dec1fd6$000079c6$000077c7@msn.com> To: From: lisa_seemeonline234@msn.com Subject: I SWALLOW (FREE) 27654 Date: Fri, 25 Jan 2002 08:05:29 -2000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Reply-To: lisa_semeonline555@yahoo.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 DOES NOT COST A THING TO SEE YOUR FAVORITE SITES GET INSTANT ACCESS WITHOUT PAYING A THING COME SEE YOUNG TEEN SLUTS GET HARDCORE AND NASTY http://65.119.83.82/freejoins/lnt1.html HERE ARE YOUR FAVORITE CELEBS GETTING BENT OVER AND SLAMMED http://65.119.83.82/freejoins/celeb1.html HOT ATHLETIC BABES SPORT FxxxxxG!!!!!!!!!!!!!!!! http://65.119.83.82/freejoins/hcs1.html Cum see these WOMEN PLAY at the ZOO http://65.119.83.82/freejoins/lz1.html ABSOLUTELY NO MONEY AT ALL This site contains things Mormens and Bible thumpers dont want to see. If you are not old enough and you mommy and daddy are not around close this immediately so you dont get spanked!!!!!! Do not reply to this e-mail message To be taken off this list please go to the link below and enter your e-mail address. "Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered Spam as long as the sender includes contact information and a method of removal." WE HONOR ALL REQUESTS . PLEASE SUBMIT ONE EMAIL AT A TIME OTHERWISE YOU WILL NOT BE REMOVED. PROFANITY SERVES NO PURPOSE. Please allow up to five days to be taken of this list. http://65.119.83.82/remove.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 10:22:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id EC2D737B402 for ; Sat, 26 Jan 2002 10:22:40 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA21078; Sun, 27 Jan 2002 05:17:26 +1100 Date: Sun, 27 Jan 2002 05:19:11 +1100 (EST) From: Bruce Evans X-X-Sender: To: Max Khon Cc: Cy Schubert - ITSD Open Systems Group , Poul-Henning Kamp , Subject: Re: request for review In-Reply-To: <20020121182450.A91754@iclub.nsu.ru> Message-ID: <20020127050617.N34813-100000@gamplex.bde.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 Sorry this reply is late. On Mon, 21 Jan 2002, Max Khon wrote: > hi, there! > On Mon, Jan 21, 2002 at 12:17:49AM +0600, Max Khon wrote: > > > ok, what do you think about this patch? > > > > Index: vfs_vnops.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/kern/vfs_vnops.c,v > > retrieving revision 1.126 > > diff -u -p -r1.126 vfs_vnops.c > > --- vfs_vnops.c 13 Jan 2002 11:58:03 -0000 1.126 > > +++ vfs_vnops.c 20 Jan 2002 17:45:38 -0000 > > @@ -571,17 +571,17 @@ vn_stat(vp, sb, td) > > * Default to zero to catch bogus uses of this field. > > */ > > > > - if (vap->va_type == VREG) { > > - sb->st_blksize = vap->va_blocksize; > > - } else if (vn_isdisk(vp, NULL)) { > > + if (vn_isdisk(vp, NULL)) { > > sb->st_blksize = vp->v_rdev->si_bsize_best; > > if (sb->st_blksize < vp->v_rdev->si_bsize_phys) > > sb->st_blksize = vp->v_rdev->si_bsize_phys; > > if (sb->st_blksize < BLKDEV_IOSIZE) > > sb->st_blksize = BLKDEV_IOSIZE; > > - } else { > > - sb->st_blksize = 0; > > - } > > + } else > > + sb->st_blksize = vap->va_blocksize; > > + > > + if (sb->st_blksize == 0) > > + sb->st_blksize = PAGE_SIZE; > > > > sb->st_flags = vap->va_flags; > > if (suser_xxx(td->td_proc->p_ucred, 0, 0)) I like this (better than the partial version committed in rev.1.128), except it adds 2 style bugs and doesn't remove 1: (1) The comment "Default to zero to catch bogus uses of this field." is now wrong. (The comment in rev.1.128 is not much better. It says PAGE_SIZE instead of 0, but doesn't say anything useful.) (2) The comment before the code is separated from the code by a blank line. This makes it appear to describe null code. (3) The scope of the comment is made even less clear by adding a blank line in the code. > btw NetBSD/OpenBSD have the following code in ufs_getattr(): > > /* this doesn't belong here */ > if (vp->v_type == VBLK) > vap->va_blocksize = BLKDEV_IOSIZE; > else if (vp->v_type == VCHR) > vap->va_blocksize = MAXBSIZE; > else > vap->va_blocksize = vp->v_mount->mnt_stat.f_iosize; That's because they haven't changed the 4.4BSD-Lite here code yet :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 12:42:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 84C5B37B402 for ; Sat, 26 Jan 2002 12:42:45 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA25994; Sun, 27 Jan 2002 07:42:30 +1100 Date: Sun, 27 Jan 2002 07:44:20 +1100 (EST) From: Bruce Evans X-X-Sender: To: Chad David Cc: Subject: Re: strtod() In-Reply-To: <20020124135250.A454@colnta.acns.ab.ca> Message-ID: <20020127070622.K35323-100000@gamplex.bde.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 On Thu, 24 Jan 2002, Chad David wrote: > On current (as of today) strtod() sets errno to EINVAL even when no error > actually occurs. While I understand that the value of errno is undefined > if an error does not occur, there is confusion when 0.0 is passed and the > conversion is successful. > ... > I'm not saying that just because Solaris chooses to implement the > interface in this way that FreeBSD should, but I do think that there is a > lot of room for introducing (needless) complexity when porting > applications from Solaris (like I am), and that while FreeBSD does not > have to set EINVAL when an error occurs, it should NOT set it when an > error does not occur. > > Note that on stable errno does not get set to EINVAL. I think you mean strtol(). strtod() hasn't changed significantly since RELENG_4. The integer strto*() functions now set it in the following cases: (1) if the base is weird, even if there are no weird digits. This is a bug IMO. All C standards seem to require that even negative bases just work. (2) if no input is consumed. I agree that errno shouldn't be set (by the strto* family at least) when there is no error. I think standards don't permit it (they permit gratutiously clobbering errno, but not when the setting of errno is explicitly documented). Setting it when no input is consumed is not very useful and has broken the the error handling of at least test(1) and dd(1) so far. This case can be detected easily by checking the end pointer. The breakage has been fixed in test(1). Here it is in dd/args.c: %%% errno = 0; num = strtouq(val, &expr, 0); if (errno != 0) /* Overflow or underflow. */ err(1, "%s", oper); if (expr == val) /* No valid digits. */ errx(1, "%s: illegal numeric value", oper); %%% The "Overflow or underflow" comment has rotted in 3 steps: (1) It was changed from "Overflow" to "Overflow or underflow" when strtuol() was changed to strtoq(). This was just an obfuscation. "Underflow" must be read as "overflow towards negative infinity", but it's less confusing to just say "overflow". (2) The code was wrong because strto*() may set errno, and broke when strtoq() started setting it. The "illegal numeric value" case became unreachable. (3) "Overflow or underflow" wasn't changed back to "Overflow" when strtoq() was changed to strtouq(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 13:27:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 3AFED37B416 for ; Sat, 26 Jan 2002 13:27:44 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0QLRZV11417; Sat, 26 Jan 2002 14:27:35 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0QLRZi07288; Sat, 26 Jan 2002 14:27:35 -0700 (MST) (envelope-from davidc) Date: Sat, 26 Jan 2002 14:27:34 -0700 From: Chad David To: Bruce Evans Cc: Chad David , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020126142734.A7139@colnta.acns.ab.ca> Mail-Followup-To: Bruce Evans , Chad David , arch@FreeBSD.ORG References: <20020124135250.A454@colnta.acns.ab.ca> <20020127070622.K35323-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127070622.K35323-100000@gamplex.bde.org>; from bde@zeta.org.au on Sun, Jan 27, 2002 at 07:44:20AM +1100 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 Sun, Jan 27, 2002 at 07:44:20AM +1100, Bruce Evans wrote: > On Thu, 24 Jan 2002, Chad David wrote: > > > On current (as of today) strtod() sets errno to EINVAL even when no error > > actually occurs. While I understand that the value of errno is undefined > > if an error does not occur, there is confusion when 0.0 is passed and the > > conversion is successful. > > ... > > I'm not saying that just because Solaris chooses to implement the > > interface in this way that FreeBSD should, but I do think that there is a > > lot of room for introducing (needless) complexity when porting > > applications from Solaris (like I am), and that while FreeBSD does not > > have to set EINVAL when an error occurs, it should NOT set it when an > > error does not occur. > > > > Note that on stable errno does not get set to EINVAL. > > I think you mean strtol(). strtod() hasn't changed significantly since > RELENG_4. The integer strto*() functions now set it in the following Depending on what you mean by "you mean strtol()"? strtol() is being called indirectly by strtod() via localeconv(), and it is failing (since around 1.3 or localeconv.c). strtod() given 0.0 does not set errno == EINVAL on any platform I have access to (FreeBSD stable, NetBSD, Solaris (8 and 9), Debian etc), only current does this, and it is not allowed to do that. It MAY set it if there is an error, and to me this implies that it CANNOT set it when there is no error. > cases: > (1) if the base is weird, even if there are no weird digits. This is a > bug IMO. All C standards seem to require that even negative bases > just work. > (2) if no input is consumed. > > I agree that errno shouldn't be set (by the strto* family at least) > when there is no error. I think standards don't permit it (they permit > gratutiously clobbering errno, but not when the setting of errno is > explicitly documented). Setting it when no input is consumed is not > very useful and has broken the the error handling of at least test(1) > and dd(1) so far. This case can be detected easily by checking the > end pointer. The breakage has been fixed in test(1). Here it is in > dd/args.c: I agree with you 100%. Checking errno when 0.0 is returned doesn't really get you very far. If you follow the standards, and errno == EINVAL then you can assume an error occured, but if errno == 0 you do not know anything. The only way to know for sure is to check endptr, so checking for EINVAL is a waste of time. > > %%% > errno = 0; > num = strtouq(val, &expr, 0); > if (errno != 0) /* Overflow or underflow. */ > err(1, "%s", oper); > > if (expr == val) /* No valid digits. */ > errx(1, "%s: illegal numeric value", oper); > %%% > > The "Overflow or underflow" comment has rotted in 3 steps: > (1) It was changed from "Overflow" to "Overflow or underflow" when > strtuol() was changed to strtoq(). This was just an obfuscation. > "Underflow" must be read as "overflow towards negative infinity", > but it's less confusing to just say "overflow". > (2) The code was wrong because strto*() may set errno, and broke when > strtoq() started setting it. The "illegal numeric value" case > became unreachable. > (3) "Overflow or underflow" wasn't changed back to "Overflow" when > strtoq() was changed to strtouq(). Code like this is what I'm dealing with. My point is that if you set errno == 0, and then after the function it is != 0, an error DID occur, as long as the return value == 0.0 or HUGE_VAL I guess. Am I making any sense? -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 14:49:52 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 4FC7B37B400; Sat, 26 Jan 2002 14:49:49 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g0QMnlU91392; Sat, 26 Jan 2002 17:49:47 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200201262249.g0QMnlU91392@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Chad David Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() In-Reply-To: Message from Chad David of "Sat, 26 Jan 2002 14:27:34 MST." <20020126142734.A7139@colnta.acns.ab.ca> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jan 2002 17:49:46 -0500 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 Chad David wrote: > On Sun, Jan 27, 2002 at 07:44:20AM +1100, Bruce Evans wrote: > > > > %%% > > errno = 0; > > num = strtouq(val, &expr, 0); > > if (errno != 0) /* Overflow or underflow. */ > > err(1, "%s", oper); > > > > if (expr == val) /* No valid digits. */ > > errx(1, "%s: illegal numeric value", oper); > > %%% > > > > The "Overflow or underflow" comment has rotted in 3 steps: > > (1) It was changed from "Overflow" to "Overflow or underflow" when > > strtuol() was changed to strtoq(). This was just an obfuscation. > > "Underflow" must be read as "overflow towards negative infinity", > > but it's less confusing to just say "overflow". > > (2) The code was wrong because strto*() may set errno, and broke when > > strtoq() started setting it. The "illegal numeric value" case > > became unreachable. > > (3) "Overflow or underflow" wasn't changed back to "Overflow" when > > strtoq() was changed to strtouq(). > > Code like this is what I'm dealing with. My point is that if you set > errno == 0, and then after the function it is != 0, an error DID occur, > as long as the return value == 0.0 or HUGE_VAL I guess. > > Am I making any sense? Not "as long as the return value" is anything! Why should the function be changing errno if it hasn't generated an error? These are particularly difficult functions to use in the first place, and they really shouldn't be made more-so by gratuitously changing errno. It's not hard to save errno, either, in the library call... -- 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 Sat Jan 26 15:29:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id B45DC37B404; Sat, 26 Jan 2002 15:29:30 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0QNTOV11690; Sat, 26 Jan 2002 16:29:24 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0QNTO107775; Sat, 26 Jan 2002 16:29:24 -0700 (MST) (envelope-from davidc) Date: Sat, 26 Jan 2002 16:29:24 -0700 From: Chad David To: "Brian F. Feldman" Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020126162924.A7726@colnta.acns.ab.ca> Mail-Followup-To: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <200201262249.g0QMnlU91392@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: <200201262249.g0QMnlU91392@green.bikeshed.org>; from green@FreeBSD.ORG on Sat, Jan 26, 2002 at 05:49:46PM -0500 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, Jan 26, 2002 at 05:49:46PM -0500, Brian F. Feldman wrote: > Chad David wrote: > > On Sun, Jan 27, 2002 at 07:44:20AM +1100, Bruce Evans wrote: > > > > > > %%% > > > errno = 0; > > > num = strtouq(val, &expr, 0); > > > if (errno != 0) /* Overflow or underflow. */ > > > err(1, "%s", oper); > > > > > > if (expr == val) /* No valid digits. */ > > > errx(1, "%s: illegal numeric value", oper); > > > %%% > > > > > > The "Overflow or underflow" comment has rotted in 3 steps: > > > (1) It was changed from "Overflow" to "Overflow or underflow" when > > > strtuol() was changed to strtoq(). This was just an obfuscation. > > > "Underflow" must be read as "overflow towards negative infinity", > > > but it's less confusing to just say "overflow". > > > (2) The code was wrong because strto*() may set errno, and broke when > > > strtoq() started setting it. The "illegal numeric value" case > > > became unreachable. > > > (3) "Overflow or underflow" wasn't changed back to "Overflow" when > > > strtoq() was changed to strtouq(). > > > > Code like this is what I'm dealing with. My point is that if you set > > errno == 0, and then after the function it is != 0, an error DID occur, > > as long as the return value == 0.0 or HUGE_VAL I guess. > > > > Am I making any sense? > > Not "as long as the return value" is anything! Why should the function be > changing errno if it hasn't generated an error? These are particularly > difficult functions to use in the first place, and they really shouldn't be > made more-so by gratuitously changing errno. It's not hard to save errno, > either, in the library call... I'm not sure if you are agreeing with me, or disagreeing with me :). When 0.0 is returned and errno == EINVAL a lot of code assumes there was an error, but current always returns with errno == EINVAL, which breaks this code when "0.0" is converted.. If you are suggesting that strtod() etc. should save errno on entry and then reset it on return (unless it wants to return its own error) then I think I agree with that. -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 20:54: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 915A337B402; Sat, 26 Jan 2002 20:54:03 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g0R4rwi92912; Sat, 26 Jan 2002 23:53:58 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200201270453.g0R4rwi92912@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Chad David Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() In-Reply-To: Message from Chad David of "Sat, 26 Jan 2002 16:29:24 MST." <20020126162924.A7726@colnta.acns.ab.ca> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jan 2002 23:53:58 -0500 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 Chad David wrote: > > > Code like this is what I'm dealing with. My point is that if you set > > > errno == 0, and then after the function it is != 0, an error DID occur, > > > as long as the return value == 0.0 or HUGE_VAL I guess. > > > > > > Am I making any sense? > > > > Not "as long as the return value" is anything! Why should the function be > > changing errno if it hasn't generated an error? These are particularly > > difficult functions to use in the first place, and they really shouldn't be > > made more-so by gratuitously changing errno. It's not hard to save errno, > > either, in the library call... > > I'm not sure if you are agreeing with me, or disagreeing with me :). > > When 0.0 is returned and errno == EINVAL a lot of code assumes there was > an error, but current always returns with errno == EINVAL, which breaks > this code when "0.0" is converted.. The problem is that 0.0 could be the right return value, but if errno was EINVAL before calling strtod(), the caller makes a mistake in assuming "retval == 0.0 && errno == EINVAL means failure". > If you are suggesting that strtod() etc. should save errno on entry and > then reset it on return (unless it wants to return its own error) then I > think I agree with that. If strtod() wants to use errno internally, that's fine, but I personally really expect it to not modify errno without also intending to return an error; that's why saving at entry and restoring at exit is my preference for these functions. -- 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 Sat Jan 26 21:13:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 2C25A37B404; Sat, 26 Jan 2002 21:13:22 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0R5DBV12319; Sat, 26 Jan 2002 22:13:11 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0R5DBf18715; Sat, 26 Jan 2002 22:13:11 -0700 (MST) (envelope-from davidc) Date: Sat, 26 Jan 2002 22:13:11 -0700 From: Chad David To: "Brian F. Feldman" Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020126221311.A18683@colnta.acns.ab.ca> Mail-Followup-To: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <200201270453.g0R4rwi92912@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: <200201270453.g0R4rwi92912@green.bikeshed.org>; from green@FreeBSD.ORG on Sat, Jan 26, 2002 at 11:53:58PM -0500 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, Jan 26, 2002 at 11:53:58PM -0500, Brian F. Feldman wrote: > Chad David wrote: > > > > Code like this is what I'm dealing with. My point is that if you set > > > > errno == 0, and then after the function it is != 0, an error DID occur, > > > > as long as the return value == 0.0 or HUGE_VAL I guess. > > > > > > > > Am I making any sense? > > > > > > Not "as long as the return value" is anything! Why should the function be > > > changing errno if it hasn't generated an error? These are particularly > > > difficult functions to use in the first place, and they really shouldn't be > > > made more-so by gratuitously changing errno. It's not hard to save errno, > > > either, in the library call... > > > > I'm not sure if you are agreeing with me, or disagreeing with me :). > > > > When 0.0 is returned and errno == EINVAL a lot of code assumes there was > > an error, but current always returns with errno == EINVAL, which breaks > > this code when "0.0" is converted.. > > The problem is that 0.0 could be the right return value, but if errno was > EINVAL before calling strtod(), the caller makes a mistake in assuming > "retval == 0.0 && errno == EINVAL means failure". That is true, but as I believe I stated at the beginning of this thread the Solaris strtod() man pages says: "Because 0 is returned on error and is also a valid return on success, an application wishing to check for error situa- tions should set errno to 0, then call strtod(), then check errno and if it is non-zero, assume an error has occurred." On FreeBSD current any code that does this (ie code written for Solaris) will fail everytime... but I think we are agreeing that this is wrong. I don't believe in trying to save code from itself, I just want things to work as expected. > > > If you are suggesting that strtod() etc. should save errno on entry and > > then reset it on return (unless it wants to return its own error) then I > > think I agree with that. > > If strtod() wants to use errno internally, that's fine, but I personally > really expect it to not modify errno without also intending to return an > error; that's why saving at entry and restoring at exit is my preference for > these functions. Agreed, so is there consensus enough on this for me to offer a patch that basically does this? I also want to see where this makes the most sense to do, in strtod.c or perhaps in the locale code (which is probably called by at least everything looking for a decimal point)? -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 22:51:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 9E47237B446; Sat, 26 Jan 2002 22:50:24 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0R6oG813297; Sun, 27 Jan 2002 09:50:16 +0300 (MSK) (envelope-from ache) Date: Sun, 27 Jan 2002 09:50:12 +0300 From: "Andrey A. Chernov" To: "Brian F. Feldman" Cc: Chad David , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127065011.GA13267@nagual.pp.ru> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201270453.g0R4rwi92912@green.bikeshed.org> User-Agent: Mutt/1.3.27i 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, Jan 26, 2002 at 23:53:58 -0500, Brian F. Feldman wrote: > > The problem is that 0.0 could be the right return value, but if errno was > EINVAL before calling strtod(), the caller makes a mistake in assuming > "retval == 0.0 && errno == EINVAL means failure". The caller _must_ set errno = 0 before the call, if he plan to check it afterwards. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 23: 4:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 7F1F137B41C; Sat, 26 Jan 2002 23:04:31 -0800 (PST) Received: (from ache@localhost) by nagual.pp.ru (8.11.6/8.11.6) id g0R74R613433; Sun, 27 Jan 2002 10:04:27 +0300 (MSK) (envelope-from ache) Date: Sun, 27 Jan 2002 10:04:23 +0300 From: "Andrey A. Chernov" To: "Brian F. Feldman" Cc: Chad David , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127070421.GA13415@nagual.pp.ru> References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201270453.g0R4rwi92912@green.bikeshed.org> User-Agent: Mutt/1.3.27i 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, Jan 26, 2002 at 23:53:58 -0500, Brian F. Feldman wrote: > > If strtod() wants to use errno internally, that's fine, but I personally > really expect it to not modify errno without also intending to return an > error; that's why saving at entry and restoring at exit is my preference for > these functions. Yes, it must save/restore errno and modify it only if error (in strtod's meaning) happens. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 26 23:37:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.acns.ab.ca (mail.acns.ab.ca [142.179.151.95]) by hub.freebsd.org (Postfix) with ESMTP id 73A9E37B400; Sat, 26 Jan 2002 23:37:25 -0800 (PST) Received: from colnta.acns.ab.ca (colnta.acns.ab.ca [192.168.1.2]) by mail.acns.ab.ca (8.11.6/8.11.3) with ESMTP id g0R7bJV12661; Sun, 27 Jan 2002 00:37:19 -0700 (MST) (envelope-from davidc@colnta.acns.ab.ca) Received: (from davidc@localhost) by colnta.acns.ab.ca (8.11.6/8.11.3) id g0R7bJV40281; Sun, 27 Jan 2002 00:37:19 -0700 (MST) (envelope-from davidc) Date: Sun, 27 Jan 2002 00:37:19 -0700 From: Chad David To: "Andrey A. Chernov" Cc: "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG Subject: Re: strtod() Message-ID: <20020127003719.A38420@colnta.acns.ab.ca> Mail-Followup-To: "Andrey A. Chernov" , "Brian F. Feldman" , Bruce Evans , arch@FreeBSD.ORG References: <20020126162924.A7726@colnta.acns.ab.ca> <200201270453.g0R4rwi92912@green.bikeshed.org> <20020127070421.GA13415@nagual.pp.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020127070421.GA13415@nagual.pp.ru>; from ache@nagual.pp.ru on Sun, Jan 27, 2002 at 10:04:23AM +0300 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 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jan 27, 2002 at 10:04:23AM +0300, Andrey A. Chernov wrote: > On Sat, Jan 26, 2002 at 23:53:58 -0500, Brian F. Feldman wrote: > > > > If strtod() wants to use errno internally, that's fine, but I personally > > really expect it to not modify errno without also intending to return an > > error; that's why saving at entry and restoring at exit is my preference for > > these functions. > > Yes, it must save/restore errno and modify it only if error (in strtod's > meaning) happens. I just noticed that if you call printf() (or anything that will call localeconv()) before you call strtod() etc. it works as it should. It is the first call to localeconv() that causes errno to be updated when it calls strtol(). After that localeconv() takes a short cut. So it isn't really strtod()'s problem, but localeconv()'s. The attached patch fixes this case, and probably others. Comments? -- Chad David davidc@acns.ab.ca www.FreeBSD.org davidc@freebsd.org ACNS Inc. Calgary, Alberta Canada Fourthly, The constant breeders, beside the gain of eight shillings sterling per annum by the sale of their children, will be rid of the charge of maintaining them after the first year. - Johnathan Swift --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="localeconv.patch" Index: localeconv.c =================================================================== RCS file: /mnt1/ncvs/src/lib/libc/locale/localeconv.c,v retrieving revision 1.3 diff -u -d -r1.3 localeconv.c --- localeconv.c 10 Feb 2001 02:00:56 -0000 1.3 +++ localeconv.c 27 Jan 2002 07:28:51 -0000 @@ -49,9 +49,16 @@ int __mlocale_changed = 1; int __nlocale_changed = 1; +extern int errno; /* required in cnv() */ + static char cnv(char *str) { - return (char)strtol(str, NULL, 0); + int save_errno = errno; + char ret; + + ret = (char)strtol(str, NULL, 0); + errno = save_errno; + return (ret); } /* --jI8keyz6grp/JLjh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message