From owner-freebsd-arch Sun Aug 18 9:51:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 018B237B400 for ; Sun, 18 Aug 2002 09:51:55 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id CDD4A43E75 for ; Sun, 18 Aug 2002 09:51:53 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 18 Aug 2002 17:51:52 +0100 (BST) To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: Your message of "Sun, 18 Aug 2002 07:19:07 +1000." <20020818055951.N12475-100000@gamplex.bde.org> Date: Sun, 18 Aug 2002 17:51:49 +0100 From: Ian Dowse Message-ID: <200208181751.aa29455@salmon.maths.tcd.ie> 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 <20020818055951.N12475-100000@gamplex.bde.org>, Bruce Evans writes: >enough compat code). Some compat code doesn't know this very well and >causes panics by accessing the stack gap directly. Non-broken code >would require lots more copyins and copyouts to avoid direct accesses: Yes, I noticed a lot of places where the Linux emulation code was accessing stack gap data without using copyin/copyout. Is there a disabled check for this somewhere in the vm_fault code? I seem to remember it being discussed somewhere but I can't find any references in the code. >> open(struct thread *td, struct open_args *uap) > >I would prefer this to be named something like xxx_open() and in a >translation layer between Xsyscall() and open(), with the translation >layer as null as possible. >> int sys_open(struct thread *td, char *path, enum uio_seg pathseg, >> int flags, int mode); > >I would prefer this to be named open() and take the same args as open(2). >Passing around td args seems to just lead to pessimizations and bugs, >since syscalls especially almost require td == curthread to work... The only issue with naming things this way is that all other callers of the system call (mainly other compat modules) need to be changed one way or another at the same time. I just did it this way so that syscalls could be changed over one at a time without touching their callers for now. If there is agreement on the td vs. curthread issue, then that would obviously be easy to change. Note that many system calls are not as simple as open(2), so having the same arguments for the user and kernel versions is not always practical. For example when there is a combination of user-supplied structures and buffers, the overhead of copying everything into the kernel by the compat module would be too high. For *ctl() sysctls, it may require duplicating much of the logic of the kernel syscall in the wrapper. A copyin/copyout function that takes a UIO_*SPACE argument might help. Ian (Apologies for the duplicated chunk in the previous mail BTW - I somehow didn't notice before sending that it had double-pasted.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 10:40:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B05F37B400 for ; Sun, 18 Aug 2002 10:40:13 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 257BF43E65 for ; Sun, 18 Aug 2002 10:40:13 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20020818174012.SSNU1186.rwcrmhc52.attbi.com@InterJet.elischer.org>; Sun, 18 Aug 2002 17:40: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 KAA41959; Sun, 18 Aug 2002 10:31:21 -0700 (PDT) Date: Sun, 18 Aug 2002 10:31:20 -0700 (PDT) From: Julian Elischer To: Ian Dowse Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <200208181751.aa29455@salmon.maths.tcd.ie> 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, 18 Aug 2002, Ian Dowse wrote: > > If there is agreement on the td vs. curthread issue, then that would > obviously be easy to change. A few days ago, Peter gave some comments as to the expense of using curthread. I must admit this is something where some architectureal guidance would be a good thing.... maybe something like "Use a local if you need to access a Per-cpu variable more than twice in a function", and "passing a thread pointer as an argument (is/is not) preferable to calling curtread explicitly in the child function". Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 11:12: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75FD237B400 for ; Sun, 18 Aug 2002 11:12:01 -0700 (PDT) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9681C43E72 for ; Sun, 18 Aug 2002 11:12:00 -0700 (PDT) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.5/8.12.5) with ESMTP id g7IIEK8a013641; Sun, 18 Aug 2002 14:14:20 -0400 (EDT) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.5/8.12.5/Submit) id g7IIEEvt013640; Sun, 18 Aug 2002 14:14:14 -0400 (EDT) Date: Sun, 18 Aug 2002 14:14:13 -0400 From: Jake Burkholder To: Ian Dowse Cc: Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue Message-ID: <20020818141413.E590@locore.ca> References: <20020818055951.N12475-100000@gamplex.bde.org> <200208181751.aa29455@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200208181751.aa29455@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, Aug 18, 2002 at 05:51:49PM +0100 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 Apparently, On Sun, Aug 18, 2002 at 05:51:49PM +0100, Ian Dowse said words to the effect of; > In message <20020818055951.N12475-100000@gamplex.bde.org>, Bruce Evans writes: > >enough compat code). Some compat code doesn't know this very well and > >causes panics by accessing the stack gap directly. Non-broken code > >would require lots more copyins and copyouts to avoid direct accesses: > > Yes, I noticed a lot of places where the Linux emulation code was > accessing stack gap data without using copyin/copyout. Is there a > disabled check for this somewhere in the vm_fault code? I seem to > remember it being discussed somewhere but I can't find any references > in the code. Its in trap_pfault; i386 allows faults on any user address in kernel mode without using copyin/out, alpha allows faults on the stack gap. I think there's more code that does this, possibly in the i386 floating point emulation. Accessing user memory directly from kernel mode only works on architectures where both are in the same address space, so this doesn't work at all on sparc64, don't know about others. > > >> open(struct thread *td, struct open_args *uap) > > > >I would prefer this to be named something like xxx_open() and in a > >translation layer between Xsyscall() and open(), with the translation > >layer as null as possible. > > >> int sys_open(struct thread *td, char *path, enum uio_seg pathseg, > >> int flags, int mode); > > > >I would prefer this to be named open() and take the same args as open(2). > >Passing around td args seems to just lead to pessimizations and bugs, > >since syscalls especially almost require td == curthread to work... > > The only issue with naming things this way is that all other callers > of the system call (mainly other compat modules) need to be changed > one way or another at the same time. I just did it this way so that > syscalls could be changed over one at a time without touching their > callers for now. > > If there is agreement on the td vs. curthread issue, then that would > obviously be easy to change. Note that many system calls are not > as simple as open(2), so having the same arguments for the user and > kernel versions is not always practical. For example when there is > a combination of user-supplied structures and buffers, the overhead > of copying everything into the kernel by the compat module would > be too high. For *ctl() sysctls, it may require duplicating much > of the logic of the kernel syscall in the wrapper. A copyin/copyout > function that takes a UIO_*SPACE argument might help. There's copyinfrom and copyinstrfrom, copyoutto would probably be useful as well. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 12:26:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFFB637B400 for ; Sun, 18 Aug 2002 12:26:10 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 986FE43E6E for ; Sun, 18 Aug 2002 12:26:09 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 TAA20919; Sun, 18 Aug 2002 19:25:59 GMT Date: Mon, 19 Aug 2002 05:31:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ian Dowse Cc: arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <200208181751.aa29455@salmon.maths.tcd.ie> Message-ID: <20020819045750.C16172-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 Sun, 18 Aug 2002, Ian Dowse wrote: > In message <20020818055951.N12475-100000@gamplex.bde.org>, Bruce Evans writes: > >enough compat code). Some compat code doesn't know this very well and > >causes panics by accessing the stack gap directly. Non-broken code > >would require lots more copyins and copyouts to avoid direct accesses: > > Yes, I noticed a lot of places where the Linux emulation code was > accessing stack gap data without using copyin/copyout. Is there a > disabled check for this somewhere in the vm_fault code? I seem to > remember it being discussed somewhere but I can't find any references > in the code. The discussion was in response to axeing an undead version of trap_pfault(). This version was intended to be used to drop support for direct accesses. It was identical except for restructuring to clean up after remving the support, and bitrot. I hacked the active version to drop the support without cleaning it up: %%% Index: trap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.231 diff -u -2 -r1.231 trap.c --- trap.c 24 Jul 2002 23:21:05 -0000 1.231 +++ trap.c 6 Aug 2002 05:08:37 -0000 @@ -707,10 +761,26 @@ /* * This is a fault on non-kernel virtual memory. - * vm is initialized above to NULL. If curproc is NULL - * or curproc->p_vmspace is NULL the fault is fatal. + * Do not allow it in kernel mode unless it is for a + * a recognized copying function. */ - if (p != NULL) - vm = p->p_vmspace; + if (!usermode && + frame->tf_eip != (int)fubyte_access && + frame->tf_eip != (int)fuword16_access && + frame->tf_eip != (int)fuword_access && + frame->tf_eip != (int)subyte_access && + frame->tf_eip != (int)suword16_access && + frame->tf_eip != (int)suword_access && + PCPU_GET(curpcb)->pcb_onfault == NULL) { + Debugger( + "pagefault for kernel access to unmapped user memory"); + goto maygo; + goto nogo; + } +maygo: + /* + * If curproc->p_vmspace is NULL the fault is fatal. + */ + vm = p->p_vmspace; if (vm == NULL) goto nogo; %%% Only the usermode test is important here. The tf_eip stuff is for lazy of pagefaults for some functions in the copyout family (so that they don't have to set and unset pcb_onfault). The check for p == NULL is removed because p can't be NULL, especially if we are in user mode. > >> open(struct thread *td, struct open_args *uap) > > > >I would prefer this to be named something like xxx_open() and in a > >translation layer between Xsyscall() and open(), with the translation > >layer as null as possible. > > >> int sys_open(struct thread *td, char *path, enum uio_seg pathseg, > >> int flags, int mode); > > > >I would prefer this to be named open() and take the same args as open(2). > >Passing around td args seems to just lead to pessimizations and bugs, > >since syscalls especially almost require td == curthread to work... > > The only issue with naming things this way is that all other callers > of the system call (mainly other compat modules) need to be changed > one way or another at the same time. I just did it this way so that > syscalls could be changed over one at a time without touching their > callers for now. OK. There are related problems changing syscalls.master. Most of the declarations in syscall.master are wrong, since they mostly don't use "const" and mostly pun typedefed types as int, but the declarations can't simply be changed because callers and callees depend on them. Adding "const" for pathnames requires const-poisoning most callees. I think the problem is smaller for typedefed types (partly because type checking is not so strict for integral types), so you should start fixing the types in the sys_foo() versions ("mode_t mode" or maybe even varargs instead of "int mode" in the above). > If there is agreement on the td vs. curthread issue, then that would > obviously be easy to change. Note that many system calls are not > as simple as open(2), so having the same arguments for the user and > kernel versions is not always practical. For example when there is > a combination of user-supplied structures and buffers, the overhead > of copying everything into the kernel by the compat module would > be too high. For *ctl() sysctls, it may require duplicating much > of the logic of the kernel syscall in the wrapper. A copyin/copyout > function that takes a UIO_*SPACE argument might help. Even copying in pathnames is not such a good idea then. The copying would have to be done in several compat opens, not to mention in all other syscalls that take pathnames, instead of only in namei(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 12:33:44 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2475F37B400 for ; Sun, 18 Aug 2002 12:33:41 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B44843E77 for ; Sun, 18 Aug 2002 12:33:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7IJXYdc072983; Sun, 18 Aug 2002 12:33:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7IJXYC5072982; Sun, 18 Aug 2002 12:33:34 -0700 (PDT) (envelope-from dillon) Date: Sun, 18 Aug 2002 12:33:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200208181933.g7IJXYC5072982@apollo.backplane.com> To: Julian Elischer Cc: Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue 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 Sun, 18 Aug 2002, Ian Dowse wrote: :> :> If there is agreement on the td vs. curthread issue, then that would :> obviously be easy to change. : :A few days ago, Peter gave some comments as to the expense of using :curthread. I must admit this is something where some architectureal :guidance would be a good thing.... maybe something like :"Use a local if you need to access a Per-cpu variable more than twice :in a function", and "passing a thread pointer as an argument (is/is not) :preferable to calling curtread explicitly in the child function". : :Julian I would consider this to be more expensive: proc1() { struct thread *td = curthread; ... proc2(td) } proc2(td) { ... } And this to be less expensive: proc1() { proc2(); } proc2() { struct thread *td = curthread; ... use td several times ... } At least for I386. Ultimately I think this will be generally true on any architecture. If a procedure uses 'curthread' multiple times loading it into a local at the top of the procedure should be a sufficient optimization. Passing td around to dozens or hundreds of procedures just for the sake of avoiding accessing 'curthread' is bad design. -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 Sun Aug 18 12:40:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A09E37B400 for ; Sun, 18 Aug 2002 12:40:41 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0273243E42 for ; Sun, 18 Aug 2002 12:40:40 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 TAA21457; Sun, 18 Aug 2002 19:40:29 GMT Date: Mon, 19 Aug 2002 05:46:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Ian Dowse , Subject: Re: Solving the stack gap issue In-Reply-To: Message-ID: <20020819053656.V16172-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 Sun, 18 Aug 2002, Julian Elischer wrote: > On Sun, 18 Aug 2002, Ian Dowse wrote: > > > > If there is agreement on the td vs. curthread issue, then that would > > obviously be easy to change. > > A few days ago, Peter gave some comments as to the expense of using > curthread. I must admit this is something where some architectureal > guidance would be a good thing.... maybe something like > "Use a local if you need to access a Per-cpu variable more than twice > in a function", and "passing a thread pointer as an argument (is/is not) > preferable to calling curtread explicitly in the child function". I think passing around pointers equal to curthread won't exactly help efficiency on most machines. I think it is slower at runtime and only faster at compile time on i386's with the current implementation. kern/*c seems to have approximately the same number of references to curthread as callers that take a td arg. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 13: 1: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C970E37B400 for ; Sun, 18 Aug 2002 13:01:07 -0700 (PDT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 8CE9543E3B for ; Sun, 18 Aug 2002 13:01:06 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 18 Aug 2002 21:01:05 +0100 (BST) To: Bruce Evans Cc: arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: Your message of "Mon, 19 Aug 2002 05:31:54 +1000." <20020819045750.C16172-100000@gamplex.bde.org> Date: Sun, 18 Aug 2002 21:01:03 +0100 From: Ian Dowse Message-ID: <200208182101.aa62911@salmon.maths.tcd.ie> 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 <20020819045750.C16172-100000@gamplex.bde.org>, Bruce Evans writes: > >The discussion was in response to axeing an undead version of >trap_pfault(). This version was intended to be used to drop support >for direct accesses. Thanks, yes, I remember now. Of course the detection of kernel accesses to user memory in trap_pfault will only trigger on unmapped addresses. To be useful for detecting this kernel code we would ideally want a way of catching all accesses, even if turning on that detection had a big performance penalty. >Even copying in pathnames is not such a good idea then. The copying >would have to be done in several compat opens, not to mention in all >other syscalls that take pathnames, instead of only in namei(). The compat modules generally want to munge paths by prepending /compat/linux for example, so all syscalls that take path arguments need to accept a kernel-space string (unless we move the path munging into namei). It is very easy to handle paths in the sys_*() functions anyway, as the uio_seg argument can be passed straight into NDINIT(). Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 17:20:20 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E84F237B400 for ; Sun, 18 Aug 2002 17:20:11 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4541043E4A for ; Sun, 18 Aug 2002 17:20:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020819002010.VVMB13899.sccrmhc02.attbi.com@InterJet.elischer.org>; Mon, 19 Aug 2002 00: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 RAA43307; Sun, 18 Aug 2002 17:05:03 -0700 (PDT) Date: Sun, 18 Aug 2002 17:05:00 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <200208181933.g7IJXYC5072982@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 Sun, 18 Aug 2002, Matthew Dillon wrote: > I would consider this to be more expensive: > > proc1() > { > struct thread *td = curthread; > ... > proc2(td) > } > > proc2(td) > { > ... > } > > And this to be less expensive: > > proc1() > { > proc2(); > } > > proc2() > { > struct thread *td = curthread; > > ... use td several times ... > } yes but what about: proc1() { struct thread *td = curthread; ... someotherfn(td) proc2(td) } proc2(td) { ... ... use td several times ... } vs proc1() { struct thread *td = curthread; ... someotherfn(td) proc2() } proc2() { struct thread *td = curthread; ... ... use td several times ... } so that proc1 needs td anyhow.. > > At least for I386. Ultimately I think this will be generally true on > any architecture. If a procedure uses 'curthread' multiple times loading > it into a local at the top of the procedure should be a sufficient > optimization. Passing td around to dozens or hundreds of procedures > just for the sake of avoiding accessing 'curthread' is bad design. > > -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 Sun Aug 18 17:40:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4581337B400 for ; Sun, 18 Aug 2002 17:40:09 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DACFD43E6E for ; Sun, 18 Aug 2002 17:40:08 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20020819004008.WVMZ1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Mon, 19 Aug 2002 00: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 RAA43374; Sun, 18 Aug 2002 17:34:40 -0700 (PDT) Date: Sun, 18 Aug 2002 17:34:37 -0700 (PDT) From: Julian Elischer To: Matthew Dillon Cc: Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue 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 duh..... restate the question.. On Sun, 18 Aug 2002, Julian Elischer wrote: > > On Sun, 18 Aug 2002, Matthew Dillon wrote: > > I would consider this to be more expensive: > > > > proc1() > > { > > struct thread *td = curthread; > > ... > > proc2(td) > > } > > > > proc2(td) > > { > > ... > > } > > > > And this to be less expensive: > > > > proc1() > > { > > proc2(); > > } > > > > proc2() > > { > > struct thread *td = curthread; > > > > ... use td several times ... > > } > > yes but what about: > > > proc1() > { > struct thread *td = curthread; > ... > someotherfn(td) > proc2(td) > } > > proc2(td) > { > ... > ... use td several times ... > } > > vs > proc1() > { > struct thread *td = curthread; > ... > someotherfn(td) > proc2(td) > } > > proc2(td) > { > ... > ... use td several times ... > } > > so that proc1 needs td anyhow.. > > > > > At least for I386. Ultimately I think this will be generally true on > > any architecture. If a procedure uses 'curthread' multiple times loading > > it into a local at the top of the procedure should be a sufficient > > optimization. Passing td around to dozens or hundreds of procedures > > just for the sake of avoiding accessing 'curthread' is bad design. > > > > -Matt > > Matthew Dillon > > > > > > > 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 Sun Aug 18 17:49:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F1A637B400 for ; Sun, 18 Aug 2002 17:49:34 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id C786643E75 for ; Sun, 18 Aug 2002 17:49:30 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0144.cvx40-bradley.dialup.earthlink.net ([216.244.42.144] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17gajN-0002f8-00; Sun, 18 Aug 2002 17:49:17 -0700 Message-ID: <3D60403B.FD09089E@mindspring.com> Date: Sun, 18 Aug 2002 17:47:55 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Matthew Dillon , Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue 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: > On Sun, 18 Aug 2002, Matthew Dillon wrote: [ ... ] This is all probably missing the boat. To my mind, the biggest efficiency issue is actually the holding of state across calls which themselves can hold state, e.g.: f1() lock a f2() f2() lock b This is probably the simplest case, compared to the code that's actually there which does this sort of thing 4 and 5 deep into the call graph. If "lock b" fails because it would result in a deadlock, then the only safe way to recover is to unwind the call graph to the point "lock a" was acquired, and release "lock a", yield, and then reacquire "lock a" and redescend the call graph to retry the "lock b" acquisition. This type of thing counts for significantly more overhead than whether or not you pass a thread pointer down vs. referencing it out of a global. I'd like to see all cases with locks being held over non-trivial function calls be fixed. It's tempting to want a way to panic based on a lock being acquired any time a function further up the call graph has a lock already (yeah, I know, it would take "magic"... I can still be tempted to want it). If there is going to be a discussion based on code refactoring, I think it's better to have the state back-out discussion before the "push/esp/pop" vs. "deref deref %FS" discussion. -- As far as the original subject discussion, I'd like to see Ian's code changes committed (since they don't seem to break anything), which would make it largely a non-issue, and I think Ian would like to see Bruce's i386 trap changes at least available via a #ifdef, so that the code could be made to complain about additional uses of the stack-gap (which is where I think Ian was headed with that question -- Ian?). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 20:20:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD2F137B400 for ; Sun, 18 Aug 2002 20:20:08 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6504D43E3B for ; Sun, 18 Aug 2002 20:20:08 -0700 (PDT) (envelope-from julian@elischer.org) 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 <20020819032007.HIQB1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Mon, 19 Aug 2002 03:20: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 UAA43876; Sun, 18 Aug 2002 20:01:44 -0700 (PDT) Date: Sun, 18 Aug 2002 20:01:42 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Matthew Dillon , Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <3D60403B.FD09089E@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 Sun, 18 Aug 2002, Terry Lambert wrote: > Julian Elischer wrote: > > On Sun, 18 Aug 2002, Matthew Dillon wrote: > [ ... ] [...] > > If "lock b" fails because it would result in a deadlock, then > the only safe way to recover is to unwind the call graph to the > point "lock a" was acquired, and release "lock a", yield, and > then reacquire "lock a" and redescend the call graph to retry > the "lock b" acquisition. you are talking (almost) about the "asleep()" faciliy that matt Dillon added for a while bus has been rmoved again.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 20:27:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FB4337B400 for ; Sun, 18 Aug 2002 20:27:31 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1294343E3B for ; Sun, 18 Aug 2002 20:27:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0278.cvx22-bradley.dialup.earthlink.net ([209.179.199.23] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17gdC7-00031o-00; Sun, 18 Aug 2002 20:27:08 -0700 Message-ID: <3D60651F.63E1A626@mindspring.com> Date: Sun, 18 Aug 2002 20:25:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Matthew Dillon , Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue 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: > On Sun, 18 Aug 2002, Terry Lambert wrote: > > Julian Elischer wrote: > > > On Sun, 18 Aug 2002, Matthew Dillon wrote: > > [ ... ] > [...] > > > > If "lock b" fails because it would result in a deadlock, then > > the only safe way to recover is to unwind the call graph to the > > point "lock a" was acquired, and release "lock a", yield, and > > then reacquire "lock a" and redescend the call graph to retry > > the "lock b" acquisition. > > you are talking (almost) about the "asleep()" faciliy that matt Dillon > added for a while bus has been rmoved again.. Almost. I think the code could be refactored to get the behaviour (e.g. by doing the locking for multiple objects in the same function that derives the data), without needing an "asleep". Anyway, you have to admit, it's much more of a problem than argument passing vs. global references for "curthread". 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Aug 18 21:20:15 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DC2537B400 for ; Sun, 18 Aug 2002 21:20:11 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9DF043E65 for ; Sun, 18 Aug 2002 21:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020819042010.IIRC11061.sccrmhc01.attbi.com@InterJet.elischer.org>; Mon, 19 Aug 2002 04: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 VAA44085; Sun, 18 Aug 2002 21:03:45 -0700 (PDT) Date: Sun, 18 Aug 2002 21:03:44 -0700 (PDT) From: Julian Elischer To: Terry Lambert Cc: Matthew Dillon , Ian Dowse , Bruce Evans , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <3D60651F.63E1A626@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 Sun, 18 Aug 2002, Terry Lambert wrote: > Anyway, you have to admit, it's much more of a problem than argument > passing vs. global references for "curthread". 8-). So is world peace but that doesn;t meant it's not a valid question.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Aug 19 4:35:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5500D37B400 for ; Mon, 19 Aug 2002 04:35:38 -0700 (PDT) Received: from relay2.kornet.net (relay2.kornet.net [211.48.62.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF6FD43E72 for ; Mon, 19 Aug 2002 04:35:36 -0700 (PDT) (envelope-from ggaggung07@kornet.net) Received: from you2-8qqrs7eqb3 (61.73.135.119) by relay2.kornet.net; 19 Aug 2002 20:35:34 +0900 Message-ID: <3d60d8073d6a2a1d@relay2.kornet.net> (added by relay2.kornet.net) From: =?ks_c_5601-1987?B?x/a068SrteU=?= To: freebsd-arch@FreeBSD.org Subject: =?ks_c_5601-1987?B?W7GksO1dIGZyZWVic2QtYXJjaLTUIMfgv+7AxyCz18DZIMWst8652b/NILq5scfAuyC15biztM+02SE=?= Date: Mon, 19 Aug 2002 19:43:27 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0197_01C0F43A.93A27C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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 This is a multi-part message in MIME format. ------=_NextPart_000_0197_01C0F43A.93A27C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 vcXDu7ytuN7Az8b7IA0KIA0KICAgDQogICAgICANCiANCiAgICAgCQkJICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICC8urjtICAJCSAgICAgwda5zrXut88gufjIoyAoIi0iwNS3 wikgDQogICAgICAgICAgICAgICAgICAgICAgICAgwffA5SDA/MitICAgICAgyN6068b5ICAN CiAgICAgICAgIA0KvcWx1CDIuL/4IL+syLi68SAguOnBpg0KIMf2tOsgwNq1v8L3ILG4wNS9 wyDG98DOxq4gx9LAziANCrG5s7vD1sPKIMHWwK8gurjH6Lmrt+EgsKHA1A0KIMGkuvEgwNq1 v8L3IL/rx7Agx9LAzg0KICAgICAgDQogIMf2tOsgIE0gxKu15Q0KICAgDQoNCiAgDQq9xbHU IMi4v/ggv6zIuLrxICC46cGmDQogseK+xiDA2rW/wvcgsbjA1L3DIMb3wM7GriDH0sDOIA0K sbmzu8PWw8ogwdbAryC6uMfouau34SCwocDUDQogwaS68SDA2rW/wvcgv+vHsCDH0sDODQog ICAgICAgseK+xiAgs+u67be5vboNCiAgIA0KDQogICANCsbyu/0gv6zIuLrxILjpwaYNCiDG 98DOxq6zs7rOLLD4sPqx3SDEq7XlsOHBpiC8rbrxvbogDQogx/a068GkwK8gp6QgtOcgNDC/ +CANCr+1yK0gv7m4xSDA5bTnIDIsMDAwv/ggx9LAziANCiAgICAgIA0KICBLVCAguvTHw7bz wNoNCiAgIA0KDQogIA0Ku+e/68fRIDAuNSW4piAgutK/7MDMv/S1vbHiDQogxvK7/SC/rMi4 uvEguOnBpiANCrHdwLa8rbrxvboNCiA1vu8guau34SC6uMfoIA0KDQoNCg0KICAgICAgILvn tvvAxyAgvNWw4cbsseINCiAgIA0KDQogICAgILHNx8/AxyAguN7Az8HWvNK0wiDApbytx87A uyDF68fYILz2wf3H0SCwzcDMuOcsILHXv9y/oSC+7rawx9EgwaS6uLW1ILCusO0gIMDWwfYg vsrAvcC7ILngyPy0z7TZLg0KICDAzCBFLW1haWzAuiC5373FwPy/68DMuOcsIL/4xKEgvsrA uL3HICCw5r/sIL7Gt6Egw6K/oSC43sDPwda80rimIMDUt8LHz7+pIMHWvcO46SC1ziC5+CC0 2b3DILjewM/AzCAgsKHB9iAgvsq1tbfPIMfPsNq9wLTPtNkuDQogICANCiAgICAgICAgICAg ICAgICAgICC6uyC43sDPwLogwaS6uMXrvcW6ziCxx7DtILvnx9e/oSDAx7DFIMGmuPG/oSBb saSw7V2287DtIMelvcO1yCCxpLDtILjewM/A1LTPtNkuDQogICAgICAgICAgICAgICAgICAg ICAgILn2xrDAuyDFrLivx8+9w7jpILz2vcWwxbrOw7O4rrChIMDMt+e+7iDB/bTPtNkuIA0K ICAgICAgICAgIElmIHlvdSB3b24ndCByZWNlaXZlIGFueSBtb3JlIG1haWwgYWJvdXQgdGhp cyBzaXRlLCANCiAgcHJlc3MgYnV0dG9uIGFuZCBmaWxsIHlvdXIgZS1tYWlsIGFkZHJlc3Mu IEFuZCB0aGVuIHdlIHdpbGwgbm90IHNlbmQgYW55IG1haWwgdG8geW91DQogICAgIA0KILq7 ILjewM/AuiDH9rTrxKu15byzsOi758DHICCws8DOIL+1vvcguN7Az8DUtM+02S4gILjewM+5 37zbwNogv6y29MOzIDogZW5leHRvcEBseWNvcy5jby5rciAgIA0KICANCiANCg== ------=_NextPart_000_0197_01C0F43A.93A27C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9ZXVjLWtyIj4NCjx0aXRsZT69xcO7vK243sDPxvsg PC90aXRsZT4NCjxTQ1JJUFQgbGFuZ3VhZ2U9amF2YXNjcmlwdD4NCjwhLS0NCmZ1bmN0aW9u IGNsaWNrTW91c2UoKQ0KCXsNCgkgIA0KCQlpZiAoKGV2ZW50LmJ1dHRvbj09MikgfHwgKGV2 ZW50LmJ1dHRvbj09Mykpew0KCQkJcmV0dXJuIChmYWxzZSk7DQoJCX0JDQoJfQ0KCQ0KCWZ1 bmN0aW9uIGNsaWNrS2V5KCkNCgl7DQoJCWlmKChldmVudC5zaGlmdEtleSkgJiYgKGV2ZW50 LmtleUNvZGUgPT0gMTIxKSkNCgkJewkJDQoJCQlyZXR1cm4gZmFsc2U7DQoJCX0JDQoJfQ0K CQ0KCWZ1bmN0aW9uIG5vQWN0aW9uKCl7DQoJCXJldHVybiBmYWxzZTsNCgl9DQoNCmRvY3Vt ZW50Lm9ubW91c2Vkb3duPWNsaWNrTW91c2UNCmRvY3VtZW50Lm9ua2V5ZG93bj1jbGlja0tl eQ0KZG9jdW1lbnQub25jb250ZXh0bWVudT1ub0FjdGlvbg0KZG9jdW1lbnQub25kcmFnc3Rh cnQ9bm9BY3Rpb24NCmRvY3VtZW50Lm9uc2VsZWN0c3RhcnQ9bm9BY3Rpb24NCi8vLS0+DQo8 L3NjcmlwdD4NCjwvaGVhZD4NCg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIHRleHQ9ImJsYWNr IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBhbGluaz0icmVkIj4NCjxwPiZuYnNwOzwv cD4NCjx0YWJsZSBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjEiIGNlbGxzcGFjaW5nPSIwIiB3 aWR0aD0iNjMyIiBib3JkZXJjb2xvcmRhcms9IndoaXRlIiBib3JkZXJjb2xvcmxpZ2h0PSJi bGFjayIgYmdjb2xvcj0id2hpdGUiPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI5 NzQiPg0KICAgICAgICAgICAgPHAgYWxpZ249ImNlbnRlciI+PGltZyBzcmM9Imh0dHA6Ly9p eWVzY2FyZC5jb20vaW1nL3RpdGxlXzMuZ2lmIiB3aWR0aD0iNjMyIiBoZWlnaHQ9IjE3NCIg Ym9yZGVyPSIwIj48L3A+DQogICAgICAgIDwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQog ICAgICAgIDx0ZCB3aWR0aD0iOTc0Ij4NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgICAg IDxwPiZuYnNwOzxpbWcgc3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2ltZy9ib3R0b202Lmdp ZiIgd2lkdGg9IjYyMyIgaGVpZ2h0PSIyMTEiIGJvcmRlcj0iMCI+PC9wPg0KICAgICAgICAg ICAgPC9mb3JtPg0KICAgICAgICA8L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAg ICA8dGQgd2lkdGg9Ijk3NCI+IA0KCQkJPGZvcm0gbmFtZT0ibWFpbGZybTEiIGFjdGlvbj0i aHR0cDovL3d3dy5peWVzY2FyZC5jb20vbWFpbC9pbnNlcnQxLmFzcCIgbWV0aG9kPSJwb3N0 IiA+DQogICAgICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBzaXplPSIy IiBjb2xvcj0iIzY2NjY2NiI+vLq47TwvZm9udD48Rk9OVCBzaXplPTI+ICANCiAgICAgICAg ICA8L0ZPTlQ+PGlucHV0IHR5cGU9InRleHQiIG5hbWU9Im5hbWUiIHNpemU9IjYiPg0KCQkg ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxmb250IHNpemU9IjIiIGNvbG9yPSIjNjY2NjY2 Ij7B1rnOte63zyC5+MijIDwvZm9udD48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0ianVtaW4i IHNpemU9IjE0IiBtYXhsZW5ndGg9IjE0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSKxvLiyIiBj b2xvcj0iIzY2NjY2NiI+KCZxdW90Oy0mcXVvdDvA1LfCKTwvZm9udD48Zm9udCBjb2xvcj0i Izk5OTk5OSI+DQogICAgICAgICAgPC9mb250Pjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiM2NjY2NjYiPsH3 wOUgwPzIrSAgDQogICAgICAgICAgPC9mb250PjxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJ0 ZWxudW0iIHNpemU9IjEzIj4NCiAgICAgICAgICAmbmJzcDsmbmJzcDsmbmJzcDs8Zm9udCBz aXplPSIyIiBjb2xvcj0iIzY2NjY2NiI+yN6068b5IDwvZm9udD48Rk9OVCBzaXplPTI+PGlu cHV0IHR5cGU9InRleHQiIG5hbWU9ImhhbmRudW0iIHNpemU9IjE1Ij4NCiAgICAgICAgICA8 L0ZPTlQ+PGlucHV0IHR5cGU9InN1Ym1pdCIgbmFtZT0iU3VibWl0MiIgdmFsdWU9Ir3Fw7si PjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvZm9ybT4NCiAgICAgICAgPC90ZD4N CiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI5NzQiPjxUQUJMRSBi b3JkZXJDb2xvcj13aGl0ZSBjZWxsU3BhY2luZz0wIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBib3JkZXJDb2xvckRhcms9d2hpdGUgY2VsbFBhZGRpbmc9MCB3aWR0aD0i NjIxIiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWxpZ249Y2VudGVyIGJv cmRlckNvbG9yTGlnaHQ9IzAwNjY5OSBib3JkZXI9MT4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPFRCT0RZPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 VFI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iMzI0Ij4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFAgYWxpZ249bGVmdD48QlI+PElN RyBoZWlnaHQ9IjY2IiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJo dHRwOi8vaXllc2NhcmQuY29tL2ltZy9jYXJkX2ltZ18yMC5naWYiIHdpZHRoPSIxMDUiIA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbGlnbj1sZWZ0IGJvcmRlcj0wPjxJ TUcgaGVpZ2h0PTcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0 cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBib3JkZXI9MD4gPFNQQU4gc3R5bGU9IkZPTlQtU0laRTog OXB0Ij69xbHUIMi4v/ggv6zIuLrxIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICC46cGmPEJSPjxJTUcgaGVpZ2h0PTcgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBib3JkZXI9MD4gx/a06yDA2rW/wvcg sbjA1L3DIMb3wM7GriDH0sDOIDxCUj48SU1HIGhlaWdodD03IA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20vaW1nL2J1XzAxLmdp ZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9yZGVyPTA+ ILG5s7vD1sPKIMHWwK8gurjH6Lmrt+EgsKHA1DxCUj48SU1HIGhlaWdodD03IA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20vaW1n L2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ym9yZGVyPTA+IMGkuvEgwNq1v8L3IL/rx7Agx9LAzjwvU1BBTj48L1A+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249bGVmdD4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCBi b3JkZXI9MD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRCT0RZPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VFI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxURCB3aWR0aD0xNTI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDxQPiZuYnNwOyZuYnNwOzxTUEFOIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPjxGT05UIGNvbG9yPSNjZDQ0MzM+PEI+ x/a06yANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTSDEq7XlPC9CPjwvRk9O VD48L1NQQU4+PC9QPjwvVEQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxU RCB3aWR0aD0xNTI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxQIGFsaWdu PWxlZnQ+ICZuYnNwOzwvUD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvRElWPjwvVEQ+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxURCB3aWR0aD0iMjkxIj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFAgYWxpZ249bGVmdD48QlI+PElNRyBo ZWlnaHQ9IjYzIiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRw Oi8vaXllc2NhcmQuY29tL2ltZy9jYXJkX2ltZ18yMS5naWYiIHdpZHRoPSI5OSIgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFsaWduPWxlZnQgYm9yZGVyPTA+PElNRyBo ZWlnaHQ9NyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8v aXllc2NhcmQuY29tL2ltZy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGJvcmRlcj0wPiA8U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQi Pr3FsdQgyLi/+CC/rMi4uvEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgILjp waY8QlI+PElNRyBoZWlnaHQ9NyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2ltZy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvcmRlcj0wPiCx4r7GJm5ic3A7wNq1v8L3 ILG4wNS9wyDG98DOxq4gx9LAziA8QlI+PElNRyANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgaGVpZ2h0PTcgc3JjPSLAzLnMwfYvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBib3JkZXI9MD4gsbmzu8PWw8ogwdbAryC6 uMfouau34SCwocDUPEJSPjxJTUcgaGVpZ2h0PTcgDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0 aD00IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBib3JkZXI9MD4gwaS68SDA 2rW/wvcgv+vHsCDH0sDOPC9TUEFOPjwvUD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPERJViBhbGlnbj1sZWZ0Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIGJvcmRlcj0wPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8VEJPRFk+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxUUj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRE IHdpZHRoPTE0MT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFAgYWxpZ249 bGVmdD48U1BBTiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9IkZP TlQtU0laRTogOXB0Ij48Rk9OVCBjb2xvcj0jY2Q0NDMzPjxCPiZuYnNwO7HivsYgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgILPruu23ub26PC9CPjwvRk9OVD48L1NQQU4+ PC9QPjwvVEQ+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxURCB3aWR0aD0x NDE+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxQIGFsaWduPWxlZnQ+ICZu YnNwOzwvUD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvRElWPjwvVEQ+PC9UUj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRSPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8VEQgd2lkdGg9IjMyNCI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxQIGFsaWduPWxlZnQ+PEJSPjxJTUcgaGVpZ2h0PSI3MiIgDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcv cGFydG5lcjE1X2NhcmRfaW1nLmpwZyIgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHdpZHRoPSIxMTMiIGFsaWduPWxlZnQgYm9yZGVyPTA+PElNRyBoZWlnaHQ9NyANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vaXllc2NhcmQuY29t L2ltZy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGJvcmRlcj0wPiA8U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPsbyu/0mbmJzcDu/ rMi4uvEguOnBpjxCUj48SU1HIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo ZWlnaHQ9NyBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20vaW1nL2J1XzAxLmdpZiIgd2lkdGg9 NCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9yZGVyPTA+IMb3wM7GrrOz us4ssPiw+rHdIMSrteWw4cGmILytuvG9uiZuYnNwOzxCUj48SU1HIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBoZWlnaHQ9NyBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20v aW1nL2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgYm9yZGVyPTA+IMf2tOvBpMCvIKekILTnIDQwv/ggPEJSPjxJTUcgaGVpZ2h0PTcgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNv bS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBib3JkZXI9MD4gv7XIrSC/ubjFIMDltOcgMiwwMDC/+CDH0sDOIDwvU1BBTj48L1A+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxESVYgYWxpZ249bGVmdD4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2Vs bFBhZGRpbmc9MCBib3JkZXI9MD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PFRCT0RZPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8VFI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxURCB3aWR0aD0xNTIgaGVpZ2h0PTE3Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8UD4mbmJzcDsmbmJzcDs8U1BBTiANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogOXB0Ij48 Rk9OVCBjb2xvcj0jY2Q0NDMzPjxCPktUIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICC69MfDtvPA2jwvQj48L0ZPTlQ+PC9TUEFOPjwvUD48L1REPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTUyIGhlaWdodD0xNz4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPFAgYWxpZ249bGVmdD4gJm5ic3A7PC9QPjwvVEQ+ PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9ESVY+PC9URD4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPFREIHdpZHRoPSIyOTEiPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8UCBhbGlnbj1sZWZ0Pjxicj48SU1HIGhlaWdodD0iNjgiIA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly9peWVzY2FyZC5jb20vaW1nL2Nh cmRfaW1nXzExLmdpZiIgd2lkdGg9IjEwNiIgDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFsaWduPWxlZnQgYm9yZGVyPTA+PElNRyBoZWlnaHQ9NyANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8vaXllc2NhcmQuY29tL2ltZy9idV8w MS5naWYiIHdpZHRoPTQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvcmRl cj0wPiA8U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPrvnv+vH0SAwLjUluKYgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgILrSv+zAzL/0tb2x4jxCUj48SU1HIGhlaWdo dD03IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcmM9Imh0dHA6Ly9peWVz Y2FyZC5jb20vaW1nL2J1XzAxLmdpZiIgd2lkdGg9NCANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgYm9yZGVyPTA+IMbyu/0mbmJzcDu/rMi4uvEguOnBpiA8QlI+PElNRyBo ZWlnaHQ9NyANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3JjPSJodHRwOi8v aXllc2NhcmQuY29tL2ltZy9idV8wMS5naWYiIHdpZHRoPTQgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGJvcmRlcj0wPiCx3cC2vK268b26PEJSPjxJTUcgaGVpZ2h0PTcg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNyYz0iaHR0cDovL2l5ZXNjYXJk LmNvbS9pbWcvYnVfMDEuZ2lmIiB3aWR0aD00IA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBib3JkZXI9MD4gNb7vILmrt+EgurjH6CA8YnI+PGJyPjxicj48L1NQQU4+PC9Q Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8RElWIGFsaWduPWxlZnQ+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxUQUJMRSBjZWxsU3BhY2luZz0wIGNl bGxQYWRkaW5nPTAgYm9yZGVyPTA+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxUQk9EWT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPFRSPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTQzPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8UCBhbGlnbj1sZWZ0PjxTUEFOIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiA5cHQiPjxGT05UIGNvbG9y PSNjZDQ0MzM+PEI+Jm5ic3A7u+e2+8DHIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICC81bDhxuyx4jwvQj48L0ZPTlQ+PC9TUEFOPjwvUD48L1REPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8VEQgd2lkdGg9MTQzPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8UCBhbGlnbj1sZWZ0PiAmbmJzcDs8L1A+PC9URD48L1RSPjwvVEJP RFk+PC9UQUJMRT48L0RJVj48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPiAgICAgICAgPC90 ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgICAgPHRkIHdpZHRoPSI5NzQiPjxwIGFs aWduPSJsZWZ0Ij48Zm9udCBzaXplPSIyIiBmYWNlPSKxvLiyIiBjb2xvcj0iIzY2NjY2NiI+ Jm5ic3A7sc3Hz8DHIA0KICAgICAgICAgICAguN7Az8HWvNK0wiDApbytx87AuyDF68fYILz2 wf3H0SCwzcDMuOcsILHXv9y/oSC+7rawx9EgwaS6uLW1ILCusO0gDQogICAgICAgICAgICDA 1sH2IL7KwL3AuyC54Mj8tM+02S48YnI+ICZuYnNwO8DMIEUtbWFpbMC6ILnfvcXA/L/rwMy4 5ywgv/jEoSC+ysC4vccgDQogICAgICAgICAgICCw5r/sIL7Gt6Egw6K/oSC43sDPwda80rim IMDUt8LHz7+pIMHWvcO46SC1ziC5+CC02b3DILjewM/AzCANCiAgICAgICAgICAgILChwfYg Jm5ic3A7vsq1tbfPIMfPsNq9wLTPtNkuPGJyPiAmbmJzcDsmbmJzcDs8YnI+ICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvZm9udD48 Rk9OVCBmYWNlPSKxvLiyIiBjb2xvcj0iIzY2NjY2NiIgc2l6ZT0yPrq7ILjewM/AuiDBpLq4 xeu9xbrOILHHsO0gu+fH17+hIMDHsMUgwaa48b+hIA0KPC9GT05UPjxGT05UIGZhY2U9IrG8 uLIiIGNvbG9yPSJyZWQiIHNpemU9IjIiPluxpLDtXTwvRk9OVD48Rk9OVCBmYWNlPSKxvLiy IiBjb2xvcj0iIzY2NjY2NiIgc2l6ZT0yPrbzsO0gx6W9w7XIILGksO0guN7Az8DUtM+02S48 L0ZPTlQ+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxCUj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9mb250Pjxh IGhyZWY9Imh0dHA6Ly9peWVzY2FyZC5jb20vcmVzZnVsLmh0bWwiPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48aW1nIHNyYz0iaHR0cDovL2l5ZXNjYXJkLmNvbS9pbWcvYnV0dG9uXzMuZ2lm IiB3aWR0aD0iNzEiIGhlaWdodD0iMjUiIGJvcmRlcj0iMCI+PC9mb250PjwvYT48Zm9udCBj b2xvcj0iIzY2NjY2NiI+IA0KICAgICAgICAgICAgPC9mb250PjxGT05UIGNvbG9yPSIjNjY2 NjY2IiANCnNpemU9Mj659sawwLsgxay4r8fPvcO46SC89r3FsMW6zsOzuK6woSDAzLfnvu4g wf20z7TZLjwvRk9OVD48Zm9udCBjb2xvcj0iIzY2NjY2NiI+IDwvZm9udD48L3A+DQogICAg ICAgIDwvdGQ+DQogICAgPC90cj4NCiAgICA8dHI+DQogICAgICAgIDx0ZCB3aWR0aD0iOTc0 Ij4NCiAgICAgICAgICAgIDxwIGFsaWduPSJjZW50ZXIiPjxmb250IGNvbG9yPSIjNjY2NjY2 Ij4mbmJzcDs8L2ZvbnQ+PEZPTlQgZmFjZT0isby4siIgY29sb3I9IiM2NjY2NjYiIHNpemU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJZiB5b3Ugd29uJ3QgcmVjZWl2ZSBhbnkgbW9y ZSBtYWlsIGFib3V0IHRoaXMgDQpzaXRlLCA8L0ZPTlQ+PGZvbnQgY29sb3I9IiM2NjY2NjYi PjxCUj4gJm5ic3A7Jm5ic3A7PC9mb250PjxhIGhyZWY9Imh0dHA6Ly9peWVzY2FyZC5jb20v cmVzZnVsLmh0bWwiPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48aW1nIHNyYz0iaHR0cDovL2l5 ZXNjYXJkLmNvbS9pbWcvYnV0dG9uXzQuZ2lmIiB3aWR0aD0iNzEiIGhlaWdodD0iMjUiIGJv cmRlcj0iMCI+PC9mb250PjwvYT48Rk9OVCBjb2xvcj0iIzY2NjY2NiIgDQpzaXplPTI+cHJl c3MgYnV0dG9uIGFuZCBmaWxsIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFuZCB0aGVuIHdlIHdp bGwgbm90IHNlbmQgYW55IA0KbWFpbCB0byB5b3U8L0ZPTlQ+PC9wPg0KICAgICAgICA8L3Rk Pg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgICA8dGQgd2lkdGg9Ijk3NCIgYmdjb2xv cj0iIzhCQjVFMiI+DQogICAgICAgICAgICA8cD4mbmJzcDs8Zm9udCBzaXplPSIyIiBmYWNl PSKxvLiyIiBjb2xvcj0iIzMzMzMzMyI+ursguN7Az8C6IMf2tOvEq7XlvLOw6LvnwMcgDQog ICAgICAgICAgICCws8DOIL+1vvcguN7Az8DUtM+02S4gJm5ic3A7uN7Az7nfvNvA2iC/rLb0 w7MgOiA8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmVuZXh0b3BAbHljb3MuY28ua3IiPjxmb250 IHNpemU9IjIiIGZhY2U9IrG8uLIiIGNvbG9yPSIjMzMzMzMzIj5lbmV4dG9wQGx5Y29zLmNv LmtyPC9mb250PjwvYT48Zm9udCBzaXplPSIyIiBmYWNlPSKxvLiyIiBjb2xvcj0iIzMzMzMz MyI+IA0KICAgICAgICAgICAgJm5ic3A7PC9mb250PjwvcD4NCiAgICAgICAgPC90ZD4NCiAg ICA8L3RyPg0KPC90YWJsZT4NCjxwPiZuYnNwOzwvcD4NCjwvYm9keT4NCg0KPC9odG1sPg0K ------=_NextPart_000_0197_01C0F43A.93A27C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 4:32:34 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A265837B400 for ; Tue, 20 Aug 2002 04:32:31 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BFD643E65 for ; Tue, 20 Aug 2002 04:32:30 -0700 (PDT) (envelope-from Alexander@Leidinger.net) Received: from fwd01.sul.t-online.de by mailout03.sul.t-online.com with smtp id 17h7FM-0005ON-0M; Tue, 20 Aug 2002 13:32:28 +0200 Received: from Andro-Beta.Leidinger.net (520065502893-0001@[217.229.217.127]) by fmrl01.sul.t-online.com with esmtp id 17h7FD-1OJhpoC; Tue, 20 Aug 2002 13:32:19 +0200 Received: from Magelan.Leidinger.net (Magelan [192.168.1.1]) by Andro-Beta.Leidinger.net (8.11.6/8.11.6) with ESMTP id g7KBWGx88900 for ; Tue, 20 Aug 2002 13:32:16 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magelan.Leidinger.net (netchild@localhost [127.0.0.1]) by Magelan.Leidinger.net (8.12.5/8.12.5) with SMTP id g7KBWFc1009455 for ; Tue, 20 Aug 2002 13:32:15 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Tue, 20 Aug 2002 13:32:15 +0200 From: Alexander Leidinger To: arch@freebsd.org Subject: timestamping kernel messages Message-Id: <20020820133215.0545063d.Alexander@Leidinger.net> Organization: Independend X-Mailer: Sylpheed version 0.8.1claws (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Sender: 520065502893-0001@t-dialin.net 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, what do you think about using timestamps in kernel messages? Long: I think it would be useful to have timestamps in kernel warnings, e.g. (sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state should be prefixed by a timestamp to be able to determine the importance of messages / make it easier to correlate this messages with other events just by looking at the console. I know, this breaks syslogs ability to group messages ("last message repeated X times") and the timestamp already exits in e.g. /var/log/messages, but I think it may be useful in some scenarios (e.g. only remote syslog available but you have to hurry, or emergency failure diagnostics with a reboot slave on the phone while you are sitting in the bath tub) to at least make it a kernel option. Is there enough support for this feature to get it into the tree, and if yes, where should I start to look to implement this feature? I don't mind if someone else is interested enough to do it on their own, I have enough on my TODO list already, but feel free to contact me for my feature requests if you want to do the work. Bye, Alexander. -- "One world, one web, one program" -- Microsoft promotional ad "Ein Volk, ein Reich, ein Fuehrer" -- Adolf Hitler http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 4:38:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A741737B400 for ; Tue, 20 Aug 2002 04:38:51 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBF3943E75 for ; Tue, 20 Aug 2002 04:38:50 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g7KBZMRo024057; Tue, 20 Aug 2002 13:35:37 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alexander Leidinger Cc: arch@FreeBSD.ORG Subject: Re: timestamping kernel messages In-Reply-To: Your message of "Tue, 20 Aug 2002 13:32:15 +0200." <20020820133215.0545063d.Alexander@Leidinger.net> Date: Tue, 20 Aug 2002 13:35:22 +0200 Message-ID: <24056.1029843322@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020820133215.0545063d.Alexander@Leidinger.net>, Alexander Leidinger wr ites: >Hi, > >what do you think about using timestamps in kernel messages? > >Long: >I think it would be useful to have timestamps in kernel warnings, e.g. >(sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state >should be prefixed by a timestamp to be able to determine the importance >of messages / make it easier to correlate this messages with other >events just by looking at the console. I think we need to revamp the console/logging system in toto. I think we should have a pseudo-device for console/log use, which stores thing in a circular buffer. Syslogd would then retreive stuff from that buffer, somewhat like what it does today. For tty console usage, we should have a kernel thread which picks things out of the buffer and prints it on the chosen console, and putting a timestamp on it would be a Good Thing. This would also give us a good architecture for hooking up ethernet consoles. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 6:32:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AF4037B400 for ; Tue, 20 Aug 2002 06:32:27 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8512843E4A for ; Tue, 20 Aug 2002 06:32:26 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) 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 JAA07142; Tue, 20 Aug 2002 09:32:19 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KDVnv27112; Tue, 20 Aug 2002 09:31:49 -0400 (EDT) (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: <15714.17605.575558.398279@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 09:31:49 -0400 (EDT) To: Bruce Evans Cc: Ian Dowse , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <20020818055951.N12475-100000@gamplex.bde.org> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> 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 Bruce Evans writes: > > I'd like normal calls to have a fast path. We're already 1 or 2 layers > slower than Linux. (Linux on i386's does something like > "pushal; call syscalltable(,%eax,4)" for the fast path, so it goes directly > from the lowest layer to sys_foo(), but FreeBSD calls syscall() from the > lowest label and syscall() does lots of relatively slow things.) Is there any chance of getting this fastpath? Or at least making syscall() more streamlined? For example, why do we check MPSAFE and conditionally grab and release GIANT in syscall instead of just grabbing/releasing it in the syscall itself? A few thousand instructions worth of bloat might be worth 2 compares in the critical path.. Also, if the copyin fails, why do we not just set the ret value and jump past the call, rather than setting error and doing an extra compare a few lines later? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 8:35:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE3BB37B400 for ; Tue, 20 Aug 2002 08:35:15 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE64B43E3B for ; Tue, 20 Aug 2002 08:35:15 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 822BFAE165; Tue, 20 Aug 2002 08:35:15 -0700 (PDT) Date: Tue, 20 Aug 2002 08:35:15 -0700 From: Alfred Perlstein To: Andrew Gallatin Cc: Bruce Evans , Ian Dowse , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue Message-ID: <20020820153515.GL75574@elvis.mu.org> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15714.17605.575558.398279@grasshopper.cs.duke.edu> 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 * Andrew Gallatin [020820 06:32] wrote: > > For example, why do we check MPSAFE and conditionally grab and release > GIANT in syscall instead of just grabbing/releasing it in the syscall > itself? A few thousand instructions worth of bloat might be worth 2 > compares in the critical path.. Also, if the copyin fails, why do we > not just set the ret value and jump past the call, rather than setting > error and doing an extra compare a few lines later? Grunt work that just needs to be done. I can take a shot at it if no one else is currently. -- -Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 10:44:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 338AD37B400 for ; Tue, 20 Aug 2002 10:44:33 -0700 (PDT) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B9243E6E for ; Tue, 20 Aug 2002 10:44:32 -0700 (PDT) (envelope-from wkb@xs4all.nl) Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.80]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g7KHiO3i094702; Tue, 20 Aug 2002 19:44:25 +0200 (CEST) Received: (from wkb@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) id g7KHiOr97301; Tue, 20 Aug 2002 19:44:24 +0200 (CEST) (envelope-from wkb) Date: Tue, 20 Aug 2002 19:44:24 +0200 From: Wilko Bulte To: Poul-Henning Kamp Cc: Alexander Leidinger , arch@FreeBSD.ORG Subject: Re: timestamping kernel messages Message-ID: <20020820174424.GA97190@xs4all.nl> References: <20020820133215.0545063d.Alexander@Leidinger.net> <24056.1029843322@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24056.1029843322@critter.freebsd.dk> User-Agent: Mutt/1.4i X-OS: FreeBSD 4.5-RELEASE-p3 X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 20, 2002 at 01:35:22PM +0200, Poul-Henning Kamp wrote: > In message <20020820133215.0545063d.Alexander@Leidinger.net>, Alexander Leidinger wr > ites: > >Hi, > > > >what do you think about using timestamps in kernel messages? > > > >Long: > >I think it would be useful to have timestamps in kernel warnings, e.g. > >(sa0:ahc0:0:1:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM command to clear this state > >should be prefixed by a timestamp to be able to determine the importance > >of messages / make it easier to correlate this messages with other > >events just by looking at the console. > > I think we need to revamp the console/logging system in toto. > > I think we should have a pseudo-device for console/log use, which stores > thing in a circular buffer. Didn't do SysV something like that? > Syslogd would then retreive stuff from that buffer, somewhat like what > it does today. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 11:51:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7A9D37B401; Tue, 20 Aug 2002 11:51:13 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D748A43EC2; Tue, 20 Aug 2002 11:46:26 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id A7A73AE1EE; Tue, 20 Aug 2002 11:46:24 -0700 (PDT) Date: Tue, 20 Aug 2002 11:46:24 -0700 From: Maxime Henrion To: arch@freebsd.org Cc: bright@mu.org, bde@freebsd.org, iedowse@freebsd.org, gallatin@freebsd.org Subject: Re: Solving the stack gap issue Message-ID: <20020820184624.GB86074@elvis.mu.org> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020820153515.GL75574@elvis.mu.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 Alfred Perlstein wrote: > * Andrew Gallatin [020820 06:32] wrote: > > > > For example, why do we check MPSAFE and conditionally grab and release > > GIANT in syscall instead of just grabbing/releasing it in the syscall > > itself? A few thousand instructions worth of bloat might be worth 2 > > compares in the critical path.. Also, if the copyin fails, why do we > > not just set the ret value and jump past the call, rather than setting > > error and doing an extra compare a few lines later? > > Grunt work that just needs to be done. I can take a shot at it > if no one else is currently. I've already started working on this in my mux_giant branch. I was very busy with nmount these days so I didn't touch it since quite long, but I knon jhb has been IFC'ing it not so long ago. This branch removes the acquiring and releasing of Giant in syscall() and let the syscalls lock it if they need to. It also removes the 'M' prefix from the syscalls.master file. Feel free to use that branch if you want to work on this stuff. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 12:33:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7004237B400 for ; Tue, 20 Aug 2002 12:33:09 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDEE943E6A for ; Tue, 20 Aug 2002 12:33:08 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g7KJX6dc084638; Tue, 20 Aug 2002 12:33:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g7KJX37j084635; Tue, 20 Aug 2002 12:33:03 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Aug 2002 12:33:03 -0700 (PDT) From: Matthew Dillon Message-Id: <200208201933.g7KJX37j084635@apollo.backplane.com> To: Alfred Perlstein Cc: Andrew Gallatin , Bruce Evans , Ian Dowse , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@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 :* Andrew Gallatin [020820 06:32] wrote: :> :> For example, why do we check MPSAFE and conditionally grab and release :> GIANT in syscall instead of just grabbing/releasing it in the syscall :> itself? A few thousand instructions worth of bloat might be worth 2 :> compares in the critical path.. Also, if the copyin fails, why do we :> not just set the ret value and jump past the call, rather than setting :> error and doing an extra compare a few lines later? : :Grunt work that just needs to be done. I can take a shot at it :if no one else is currently. : :-- :-Alfred Perlstein [alfred@freebsd.org] [#bsdcode/efnet/irc.prison.net] : Please feel free to proceed, Alfred. I think we are at the point where we can get rid of the MPSAFE flag and shift Giant operation from the syscall trap code to the individual syscall procedures. It is, as you say, just a lot of grunt work. I originally put the MPSAFE code in the syscall trap handler because it was the most convenient solution, and performance wasn't an issue back then. I doubt people will notice the performance difference with Giant shifted to the syscalls but from an engineering perspective I think it's a good cleanup to make because it makes it easier for people working on the syscalls to shift Giant inward. -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 Aug 20 15: 1:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D1D537B401 for ; Tue, 20 Aug 2002 15:01:14 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A54743E4A for ; Tue, 20 Aug 2002 15:01:13 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 WAA22667; Tue, 20 Aug 2002 22:00:57 GMT Date: Wed, 21 Aug 2002 08:06:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Andrew Gallatin Cc: Ian Dowse , Subject: Re: Solving the stack gap issue In-Reply-To: <15714.17605.575558.398279@grasshopper.cs.duke.edu> Message-ID: <20020821073943.W25211-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 Tue, 20 Aug 2002, Andrew Gallatin wrote: > Bruce Evans writes: > > > > I'd like normal calls to have a fast path. We're already 1 or 2 layers > > slower than Linux. (Linux on i386's does something like > > "pushal; call syscalltable(,%eax,4)" for the fast path, so it goes directly > > from the lowest layer to sys_foo(), but FreeBSD calls syscall() from the > > lowest label and syscall() does lots of relatively slow things.) > > Is there any chance of getting this fastpath? Or at least making > syscall() more streamlined? It's harder than it was before syscall() accumulated a lot of cruft. Linux starts a little cleaner by passing the first few args in registers so that we don't have to do copyin()s to read them. I've thought about doing the copyin()s more efficiently. Iterated fuword()'s may be faster, especially if there is only 1 iteration. On i386's, the fuword()'s can easily be optimized to 1 bounds check (the one at the beginning of fuword()) and direct accesses plus lazy trap handling. So passing args on the user stack instead of in registers need not be significantly worse than passing args on the stack for general function calls, at least on i386's. > For example, why do we check MPSAFE and conditionally grab and release > GIANT in syscall instead of just grabbing/releasing it in the syscall > itself? A few thousand instructions worth of bloat might be worth 2 > compares in the critical path.. Well, it's better not to grab it at all. The syscall path is not as critical as some. See other replies about how we are almost ready to finish pushing down Giant locking to individual syscalls and removing MPSAFE. I counted about 130 syscalls which still depend on syscall() handling Giant. > Also, if the copyin fails, why do we > not just set the ret value and jump past the call, rather than setting > error and doing an extra compare a few lines later? This is an error case, so it is not in the fast path. Actually, handling errors lazily like this seems to introduce bugs. We call ktrsyscall() unconditionally in the error case, but the args are stack garbage if the copyin() failed. Quite a bit of the non-fast-pathness in syscall() is caused by wanting to fall through through to do things ktrace checks in all cases. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 16:14:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72C3637B400 for ; Tue, 20 Aug 2002 16:14:43 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F45D43EA9 for ; Tue, 20 Aug 2002 16:14:41 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 XAA30888; Tue, 20 Aug 2002 23:14:11 GMT Date: Wed, 21 Aug 2002 09:19:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp Cc: Alexander Leidinger , Subject: Re: timestamping kernel messages In-Reply-To: <24056.1029843322@critter.freebsd.dk> Message-ID: <20020821085414.O25287-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 Tue, 20 Aug 2002, Poul-Henning Kamp wrote: > In message <20020820133215.0545063d.Alexander@Leidinger.net>, Alexander Leidinger wr > >what do you think about using timestamps in kernel messages? I think this would be useful for some cases (mainly when syslogd is blocked or not running). > I think we need to revamp the console/logging system in toto. > > I think we should have a pseudo-device for console/log use, which stores > thing in a circular buffer. > > Syslogd would then retreive stuff from that buffer, somewhat like what > it does today. > > For tty console usage, we should have a kernel thread which picks things out > of the buffer and prints it on the chosen console, and putting a timestamp > on it would be a Good Thing. This would only help for broken console drivers. Non-broken ones must be able to do output at almost any time, including in the middle of message buffer pointer update (which should be locked somehow), since they may be invoked then when the code is traced using ddb. I wouldn't want to do the buffering in a device driver. The current message buffer has never been locked correctly for writing despite it being very simple and low level. But read accesses are easy provided the reader doesn't try to lock the writer. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 16:37:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C01537B400; Tue, 20 Aug 2002 16:37:50 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1607043E6A; Tue, 20 Aug 2002 16:37:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0108.cvx21-bradley.dialup.earthlink.net ([209.179.192.108] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17hIZI-0001CW-00; Tue, 20 Aug 2002 16:37:49 -0700 Message-ID: <3D62D292.D0F3FEE6@mindspring.com> Date: Tue, 20 Aug 2002 16:36:50 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxime Henrion Cc: arch@freebsd.org, bright@mu.org, bde@freebsd.org, iedowse@freebsd.org, gallatin@freebsd.org Subject: Re: Solving the stack gap issue References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org> <20020820184624.GB86074@elvis.mu.org> 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 Maxime Henrion wrote: > I've already started working on this in my mux_giant branch. I was very > busy with nmount these days so I didn't touch it since quite long, but I > knon jhb has been IFC'ing it not so long ago. This branch removes the > acquiring and releasing of Giant in syscall() and let the syscalls lock > it if they need to. It also removes the 'M' prefix from the > syscalls.master file. Feel free to use that branch if you want to work > on this stuff. I thought this was already do-able on a call by call basis? From sysent.h: struct sysent { /* system call table */ int sy_narg; /* number of arguments */ sy_call_t *sy_call; /* implementing function */ }; #define SYF_ARGMASK 0x0000FFFF #define SYF_MPSAFE 0x00010000 It seems to me that SYF_MPSAFE is the flag you want to look at to decide whether you want to grab giant or not? If not, it'd be really easy to add up to 15 more flags... one I had been considering was interruptability, and another was a 2 bit hint as to whether the call was non-blocking, might block, or would block (for use by the new threads code, to decide on whether to allocate a fake, delayed, or up-front blocking context). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 17: 0: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77C1C37B400 for ; Tue, 20 Aug 2002 17:00:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC1CD43E7B for ; Tue, 20 Aug 2002 17:00:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA87638 for ; Tue, 20 Aug 2002 16:45:34 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7KNioV03523 for freebsd-arch@freebsd.org; Tue, 20 Aug 2002 16:44:50 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208202344.g7KNioV03523@arch20m.dellroad.org> Subject: NULL To: freebsd-arch@freebsd.org Date: Tue, 20 Aug 2002 16:44:50 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Simple question... Why isn't NULL defined to be "((void *)0)" instead of "0" ? You get more useful warnings from 'cc -Wall' with "((void *)0)". -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 17:21:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7791437B400 for ; Tue, 20 Aug 2002 17:21:24 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3C4043E3B for ; Tue, 20 Aug 2002 17:21:23 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g7L0LH27033274; Tue, 20 Aug 2002 17:21:17 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g7L0LGoZ033273; Tue, 20 Aug 2002 17:21:16 -0700 (PDT) Date: Tue, 20 Aug 2002 17:21:16 -0700 From: "David O'Brien" To: Archie Cobbs Cc: freebsd-arch@freebsd.org Subject: Re: NULL Message-ID: <20020821002116.GA33223@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <200208202344.g7KNioV03523@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208202344.g7KNioV03523@arch20m.dellroad.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 20, 2002 at 04:44:50PM -0700, Archie Cobbs wrote: > Simple question... > Why isn't NULL defined to be "((void *)0)" instead of "0" ? In C++ this is not legal: void blah(void) { int *foo; void *bar; bar = foo; foo = bar; } it is in C, but we share the definition. A benefit of "(void *)0" is that this would be caught: char c = NULL; rather than the correct: char c = '\0'; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 17:54:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B77537B400 for ; Tue, 20 Aug 2002 17:54:15 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D14E43E6E for ; Tue, 20 Aug 2002 17:54:15 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id EE801AE216; Tue, 20 Aug 2002 17:54:14 -0700 (PDT) Date: Tue, 20 Aug 2002 17:54:14 -0700 From: Jon Mini To: Poul-Henning Kamp Cc: Alexander Leidinger , arch@FreeBSD.ORG Subject: Re: timestamping kernel messages Message-ID: <20020821005414.GJ3751@elvis.mu.org> References: <20020820133215.0545063d.Alexander@Leidinger.net> <24056.1029843322@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24056.1029843322@critter.freebsd.dk> 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 Poul-Henning Kamp [phk@critter.freebsd.dk] wrote : > I think we need to revamp the console/logging system in toto. > > I think we should have a pseudo-device for console/log use, > which stores thing in a circular buffer. > > Syslogd would then retreive stuff from that buffer, somewhat > like what it does today. > > For tty console usage, we should have a kernel thread which > picks things out of the buffer and prints it on the chosen > console, and putting a timestamp on it would be a Good Thing. I, also, am not happy with the current console code. It has several problems that really irritate me, such as the fact that messages are sent to the console one character at a time, resulting in jumbled messages like: | MSoMuPn:t iAnPg CrPoUo t# 1f rLoamu nucfhse:d/!d | ev/ad0a It would be very nice to at least see printf() and friends insert messages into per-cpu line buffers that are sent to the console at every newline (of course we'd have to toggle that behaviour while taking input from the console). Funneling console activity through a circular buffer with one write channel and several read channels could be useful, especially if its also available from userland. I've got patches that do this to klog (I would like to see the msgbuf stuff go). Being able to "tail -f /var/klog" and get a trace of console activity is nice. > This would also give us a good architecture for hooking up > ethernet consoles. Do you mean console over TCP? I'd really like to see gdb -k over TCP, and asynchronous, too. It would be nice to only tie one kernel thread to a gdb process and not the entire system. -- Jonathan Mini http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:12: 3 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EEAB37B400 for ; Tue, 20 Aug 2002 18:12:02 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C47E43E72 for ; Tue, 20 Aug 2002 18:12:02 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id F2AE5AE147; Tue, 20 Aug 2002 18:12:01 -0700 (PDT) Date: Tue, 20 Aug 2002 18:12:01 -0700 From: Maxime Henrion To: arch@freebsd.org Cc: tlambert2@mindspring.com Subject: Re: Solving the stack gap issue Message-ID: <20020821011201.GC86074@elvis.mu.org> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org> <20020820184624.GB86074@elvis.mu.org> <3D62D292.D0F3FEE6@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D62D292.D0F3FEE6@mindspring.com> 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 Terry Lambert wrote: > Maxime Henrion wrote: > > I've already started working on this in my mux_giant branch. I was very > > busy with nmount these days so I didn't touch it since quite long, but I > > knon jhb has been IFC'ing it not so long ago. This branch removes the > > acquiring and releasing of Giant in syscall() and let the syscalls lock > > it if they need to. It also removes the 'M' prefix from the > > syscalls.master file. Feel free to use that branch if you want to work > > on this stuff. > > I thought this was already do-able on a call by call basis? From > sysent.h: [ripped code] I'm aware of this flag, the subject of this thread was about *removing* it and let the syscalls acquire Giant on an invidual basis. > It seems to me that SYF_MPSAFE is the flag you want to look at to > decide whether you want to grab giant or not? If not, it'd be > really easy to add up to 15 more flags... one I had been considering > was interruptability, and another was a 2 bit hint as to whether the > call was non-blocking, might block, or would block (for use by the > new threads code, to decide on whether to allocate a fake, delayed, > or up-front blocking context). Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:15: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 194B137B400; Tue, 20 Aug 2002 18:15:06 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CD7343E42; Tue, 20 Aug 2002 18:15:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA88061; Tue, 20 Aug 2002 18:01:43 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7L110m03801; Tue, 20 Aug 2002 18:01:00 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208210101.g7L110m03801@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821002116.GA33223@dragon.nuxi.com> "from David O'Brien at Aug 20, 2002 05:21:16 pm" To: obrien@freebsd.org Date: Tue, 20 Aug 2002 18:01:00 -0700 (PDT) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 David O'Brien writes: > > Simple question... > > Why isn't NULL defined to be "((void *)0)" instead of "0" ? > > In C++ this is not legal: > > void blah(void) { > int *foo; > void *bar; > bar = foo; > foo = bar; > } > > it is in C, but we share the definition. > A benefit of "(void *)0" is that this would be caught: > > char c = NULL; > > rather than the correct: > char c = '\0'; > When you say "not legal" do you mean it causes an error or a warning? If it's just a warning, then are you saying the reason we don't use (void *)0 is because we would lose the C++ warning to gain the C warning? Seems like a fair trade to me :-) FYI, this question came up when porting some code to redhat Linux, where NULL is defined as (void *)0. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:28:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E486C37B400; Tue, 20 Aug 2002 18:28:49 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC34C43E6A; Tue, 20 Aug 2002 18:28:49 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id 7A2EBAE163; Tue, 20 Aug 2002 18:28:49 -0700 (PDT) Date: Tue, 20 Aug 2002 18:28:49 -0700 From: Jon Mini To: Archie Cobbs Cc: obrien@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: NULL Message-ID: <20020821012849.GK3751@elvis.mu.org> References: <20020821002116.GA33223@dragon.nuxi.com> <200208210101.g7L110m03801@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208210101.g7L110m03801@arch20m.dellroad.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 Archie Cobbs [archie@dellroad.org] wrote : > When you say "not legal" do you mean it causes an error or a warning? > > FYI, this question came up when porting some code to redhat Linux, where > NULL is defined as (void *)0. "Not legal" refers to the fact that C is a standardised language, and this violates that standard. Whether or not it works in gcc is irrellevant. Also, NULL is defined as 0 in the standard, because this: void *p; p = 0; Is guaranteed to produce an invalid pointer, and this: ((p != 0) || (p == 0)) Tests for a valid pointer and an invalid pointer, respectively. The fact that pointers are linear addresses in FreeBSD and Linux and that the address value 0x0 is used for NULL are just some of the happy coincidences that the relevant standards can't rely on, and must define as "implementation dependant." On a related note, this : p = 1; Is illegal. I hope this makes sense. -- Jonathan Mini http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:29: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C144137B401 for ; Tue, 20 Aug 2002 18:29:03 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0277243E75 for ; Tue, 20 Aug 2002 18:29:03 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g7L1T127034105; Tue, 20 Aug 2002 18:29:01 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g7L1T1qM034104; Tue, 20 Aug 2002 18:29:01 -0700 (PDT) Date: Tue, 20 Aug 2002 18:29:01 -0700 From: "David O'Brien" To: Archie Cobbs Cc: freebsd-arch@freebsd.org Subject: Re: NULL Message-ID: <20020821012901.GA34047@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20020821002116.GA33223@dragon.nuxi.com> <200208210101.g7L110m03801@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208210101.g7L110m03801@arch20m.dellroad.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 20, 2002 at 06:01:00PM -0700, Archie Cobbs wrote: > > In C++ this is not legal: > > > > void blah(void) { > > int *foo; > > void *bar; > > bar = foo; > > foo = bar; > > } ... > When you say "not legal" do you mean it causes an error or a warning? Easy enought to try yourself (/void blah/int main/ and add return 0;) :-) $ ls -l a.out ls: a.out: No such file or directory $ CC voidp.cxx voidp.cxx: In function `int main()': voidp.cxx:6: invalid conversion from `void*' to `int*' $ ls -l a.out ls: a.out: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:45: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3FCF37B400; Tue, 20 Aug 2002 18:45:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C14543E65; Tue, 20 Aug 2002 18:45:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA88241; Tue, 20 Aug 2002 18:33:44 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7L1X0N03964; Tue, 20 Aug 2002 18:33:00 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208210133.g7L1X0N03964@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821012901.GA34047@dragon.nuxi.com> "from David O'Brien at Aug 20, 2002 06:29:01 pm" To: obrien@freebsd.org Date: Tue, 20 Aug 2002 18:33:00 -0700 (PDT) Cc: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 David O'Brien writes: > > > In C++ this is not legal: > > > > > > void blah(void) { > > > int *foo; > > > void *bar; > > > bar = foo; > > > foo = bar; > > > } > ... > > When you say "not legal" do you mean it causes an error or a warning? > > Easy enought to try yourself (/void blah/int main/ and add return 0;) :-) > > $ ls -l a.out > ls: a.out: No such file or directory > $ CC voidp.cxx > voidp.cxx: In function `int main()': > voidp.cxx:6: invalid conversion from `void*' to `int*' > $ ls -l a.out > ls: a.out: No such file or directory Thanks... So how does C++ on Linux get away with (void *)0? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:45:11 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E633837B401; Tue, 20 Aug 2002 18:45:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id E89BA43E6E; Tue, 20 Aug 2002 18:45:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA88269; Tue, 20 Aug 2002 18:40:56 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7L1eCJ03992; Tue, 20 Aug 2002 18:40:12 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208210140.g7L1eCJ03992@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821012849.GK3751@elvis.mu.org> "from Jon Mini at Aug 20, 2002 06:28:49 pm" To: Jon Mini Date: Tue, 20 Aug 2002 18:40:12 -0700 (PDT) Cc: obrien@freebsd.org, freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Jon Mini writes: > > When you say "not legal" do you mean it causes an error or a warning? > > > > FYI, this question came up when porting some code to redhat Linux, where > > NULL is defined as (void *)0. > > "Not legal" refers to the fact that C is a standardised language, > and this violates that standard. Whether or not it works in gcc is > irrellevant. You mean C++ right? That was the example being referred to. > Also, NULL is defined as 0 in the standard, because this: > > void *p; > > p = 0; > > Is guaranteed to produce an invalid pointer, and this: > > ((p != 0) || (p == 0)) > > Tests for a valid pointer and an invalid pointer, respectively. Are you saying that POSIX declares that NULL be "0"? Then I agree we must do that.. but why then doesn't Linux? Also, how does replacing "0" in your examples with "(void *)0" break anything? > The fact that pointers are linear addresses in FreeBSD and Linux > and that the address value 0x0 is used for NULL are just some of > the happy coincidences that the relevant standards can't rely on, > and must define as "implementation dependant." > > On a related note, this : > > p = 1; > > Is illegal. Agreed. > I hope this makes sense. Sortof.. :-) Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 18:45:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EBAF37B400 for ; Tue, 20 Aug 2002 18:45:44 -0700 (PDT) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9846043E70 for ; Tue, 20 Aug 2002 18:45:42 -0700 (PDT) (envelope-from erikt@midgard.homeip.net) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailg.telia.com (8.12.5/8.12.5) with ESMTP id g7L1jeGU015969 for ; Wed, 21 Aug 2002 03:45:40 +0200 (CEST) X-Original-Recipient: Received: from falcon.midgard.homeip.net (h62n2fls20o913.telia.com [212.181.163.62]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id DAA06238 for ; Wed, 21 Aug 2002 03:45:39 +0200 (CEST) Received: (qmail 5587 invoked by uid 1001); 21 Aug 2002 01:45:37 -0000 Date: Wed, 21 Aug 2002 03:45:37 +0200 From: Erik Trulsson To: Jon Mini Cc: Archie Cobbs , obrien@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: NULL Message-ID: <20020821014537.GA5553@falcon.midgard.homeip.net> Mail-Followup-To: Jon Mini , Archie Cobbs , obrien@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <20020821002116.GA33223@dragon.nuxi.com> <200208210101.g7L110m03801@arch20m.dellroad.org> <20020821012849.GK3751@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020821012849.GK3751@elvis.mu.org> User-Agent: Mutt/1.5.1i 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, Aug 20, 2002 at 06:28:49PM -0700, Jon Mini wrote: > Archie Cobbs [archie@dellroad.org] wrote : > > > When you say "not legal" do you mean it causes an error or a warning? > > > > FYI, this question came up when porting some code to redhat Linux, where > > NULL is defined as (void *)0. > > "Not legal" refers to the fact that C is a standardised language, > and this violates that standard. Whether or not it works in gcc is > irrellevant. Correction: This violates the C++ standard, not the C standard. In C NULL can be defined as either 0 or ((void*)0). In C++ only 0 is allowed. The reason for this is that C++ has stricter typechecking such that char *p = ((void*)0) is not allowed since one would assign a void pointer to a char pointer. This is allowed in C but not C++. In C you can always assign a void pointer to any other sort of pointer and it will automatically be converted to the corrct type. Not so in C++. > > Also, NULL is defined as 0 in the standard, because this: > > void *p; > > p = 0; > > Is guaranteed to produce an invalid pointer, and this: Not really invalid pointer, rather a pointer which is guaranteed not to point to any object. (And which will compare equal to any other null pointer and not equal to any valid non-null pointer.) > > ((p != 0) || (p == 0)) > > Tests for a valid pointer and an invalid pointer, respectively. Actually it tests for non-null pointer and null pointer respectively. Not all non-null pointers are valid. > > The fact that pointers are linear addresses in FreeBSD and Linux > and that the address value 0x0 is used for NULL are just some of > the happy coincidences that the relevant standards can't rely on, > and must define as "implementation dependant." True but irrelevant. > > On a related note, this : > > p = 1; > > Is illegal. Not illegal. It just causes undefined (or possibly implementation defined) behaviour. The compiler may (and usually will) accept. This is in contrast to C++ where char * p= ((void*0)) will cause a compilation error. > > I hope this makes sense. > > -- > Jonathan Mini > http://www.freebsd.org/ -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 19: 5:25 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72F4D37B400; Tue, 20 Aug 2002 19:05:21 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 111DD43E3B; Tue, 20 Aug 2002 19:05:20 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 CAA24501; Wed, 21 Aug 2002 02:05:16 GMT Date: Wed, 21 Aug 2002 12:10:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Jon Mini Cc: Archie Cobbs , , Subject: Re: NULL In-Reply-To: <20020821012849.GK3751@elvis.mu.org> Message-ID: <20020821114425.Q26007-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 Tue, 20 Aug 2002, Jon Mini wrote: > Archie Cobbs [archie@dellroad.org] wrote : > > > When you say "not legal" do you mean it causes an error or a warning? > > > > FYI, this question came up when porting some code to redhat Linux, where > > NULL is defined as (void *)0. This definition seems to be missing some parentheses. In C, 0 and ((void *)0) are just 2 of many different correct definitions of NULL. They cause different warnings and error in broken code, so it may be useful to try compiling with both in an attempt to detect more errors. > "Not legal" refers to the fact that C is a standardised language, ^ I think you mean C++ > and this violates that standard. Whether or not it works in gcc is > irrellevant. > > Also, NULL is defined as 0 in the standard, because this: > > void *p; > > p = 0; > > Is guaranteed to produce an invalid pointer, and this: > > ((p != 0) || (p == 0)) > > Tests for a valid pointer and an invalid pointer, respectively. > > The fact that pointers are linear addresses in FreeBSD and Linux > and that the address value 0x0 is used for NULL are just some of > the happy coincidences that the relevant standards can't rely on, > and must define as "implementation dependant." Address 0 has very little to do with NULL, at least in C. In C, NULL expands to an implementation-defined null pointer constant. A null pointer constant is an integer constant expression [of any integer type] with value 0, or such an expression cast to precisely (void *). C compilers can easily recognize these expressions and, if they are in pointer contexts (even despite not being pointers themselves), translate them to implementation-decided magic address values which might not be all-bits-0. > On a related note, this : > > p = 1; > > Is illegal. > > I hope this makes sense. This is invalid in C, too, basically because the integral constant expression 1 doesn't have value 0, so the magic rules for 0 don't apply. More general but stricter rules about conversions between pointers and integers apply instead. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 20:30: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 533B437B400; Tue, 20 Aug 2002 20:30:06 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBC8143E3B; Tue, 20 Aug 2002 20:30:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id UAA88840; Tue, 20 Aug 2002 20:24:14 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7L3NTR04362; Tue, 20 Aug 2002 20:23:29 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208210323.g7L3NTR04362@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821114425.Q26007-100000@gamplex.bde.org> "from Bruce Evans at Aug 21, 2002 12:10:47 pm" To: Bruce Evans Date: Tue, 20 Aug 2002 20:23:29 -0700 (PDT) Cc: Jon Mini , Archie Cobbs , obrien@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Bruce Evans writes: > In C, 0 and ((void *)0) are just 2 of many different correct definitions > of NULL. They cause different warnings and error in broken code, so > it may be useful to try compiling with both in an attempt to detect > more errors. So my vote is for NULL = "((void *)0)" when compiling C code (and leaving "0" when compiling C++, which can easily be different). This will catch such obvious bugs as "strncmp(s, t, NULL)" which are not caught as it stands now... -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 22:58: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7888037B6AB; Tue, 20 Aug 2002 22:58:02 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 147A043E3B; Tue, 20 Aug 2002 22:58:02 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0170.cvx22-bradley.dialup.earthlink.net ([209.179.198.170] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17hOV6-0000F3-00; Tue, 20 Aug 2002 22:57:53 -0700 Message-ID: <3D632BA8.45C64D10@mindspring.com> Date: Tue, 20 Aug 2002 22:56:56 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxime Henrion Cc: arch@freebsd.org Subject: Re: Solving the stack gap issue References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org> <20020820184624.GB86074@elvis.mu.org> <3D62D292.D0F3FEE6@mindspring.com> <20020821011201.GC86074@elvis.mu.org> 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 Maxime Henrion wrote: > Terry Lambert wrote: > > I thought this was already do-able on a call by call basis? From > > sysent.h: > [ripped code] > > I'm aware of this flag, the subject of this thread was about *removing* > it and let the syscalls acquire Giant on an invidual basis. I think you've misinterpreted. Can't this be done one function at a time *using this flag*? I don't see what the big deal is about, if this can be done incrementally, is all. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 23:25:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C35D037B400 for ; Tue, 20 Aug 2002 23:25:44 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6916C43E72 for ; Tue, 20 Aug 2002 23:25:44 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7L6PcIb053994; Tue, 20 Aug 2002 23:25:38 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7L6PcuU053993; Tue, 20 Aug 2002 23:25:38 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 23:25:38 -0700 From: Luigi Rizzo To: arch@freebsd.org Subject: ugliness in rc.* scripts Message-ID: <20020820232538.A53816@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 various rc.* scripts we have multiple instances of constructs like this: case ${some_config_variable} in [Mm][Ii][Xx][Ed]_[Cc][Aa][Ss][Ee]_[Ss][Tt][Rr][Ii][Nn][Gg]) .... which is not the most desirable thing in terms of readability. This would be easily fixed by moving /usr/bin/tr to /bin/tr (statically linked) and doing tolower() { echo `tr A-Z a-z <<_EOF $*` } case `tolower ${some_config_variable}` in mixed_case_string) ... (btw, i am not sure why, in the above example the _EOF delimited is not required nor i can find any place to put it without being processed as stdin. Perhaps a bug in /bin/sh ?) Anyways, should we go for this ? I believe our scripts would be greatly improved. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 23:31:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89FC737B400 for ; Tue, 20 Aug 2002 23:31:52 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BCF643E75 for ; Tue, 20 Aug 2002 23:31:51 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7L6VmFl020993; Wed, 21 Aug 2002 00:31:48 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Aug 2002 00:31:12 -0600 (MDT) Message-Id: <20020821.003112.86889670.imp@bsdimp.com> To: archie@dellroad.org Cc: freebsd-arch@FreeBSD.ORG Subject: Re: NULL From: "M. Warner Losh" In-Reply-To: <200208210140.g7L1eCJ03992@arch20m.dellroad.org> References: <20020821012849.GK3751@elvis.mu.org> <200208210140.g7L1eCJ03992@arch20m.dellroad.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <200208210140.g7L1eCJ03992@arch20m.dellroad.org> Archie Cobbs writes: : Are you saying that POSIX declares that NULL be "0"? Then I agree : we must do that.. but why then doesn't Linux? ISO-C99 says that '#define NULL 0' is standards compliant. Looks like (void *) 0 is also legal in 'C' for NULL (per 6.3.2.1.#3). NULL is *A* null pointer constant, and both '0' and '(void *) 0' are null pointer constants. However, for C++ NULL must be 0. It can't be (void *) 0 because int *a = NULL; would break and people expect that to work. We have to define NULL in 7 headers: 7.11 Localization 7.17 Common definitions 7.19 Input/output 7.20 General utilities 7.21 String handling 7.23 Date and time 7.24 Extended multibyte and wide-character utilities We could find _BSD_NULL_ the same place we define _BSD_SIZE_T_ and then define NULL to _BSD_NULL_, but that sounds like overkill to me. From the C-99 draft standard: 6.3.2.1 #3: [#3] An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.46) If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. 46)The macro NULL is defined in as a null pointer constant; see 7.17. ... K.3 Implementation-defined behavior [#1] A conforming implementation shall document its choice of behavior in each of the areas listed in this subclause. The following are implementation-defined: ... -- The null pointer constant to which the macro NULL expands (7.17). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Aug 20 23:37:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81B9A37B400 for ; Tue, 20 Aug 2002 23:37:08 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57EF843E6A for ; Tue, 20 Aug 2002 23:37:07 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7L6b5Fl021023; Wed, 21 Aug 2002 00:37:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Aug 2002 00:36:28 -0600 (MDT) Message-Id: <20020821.003628.52042275.imp@bsdimp.com> To: archie@dellroad.org Cc: freebsd-arch@FreeBSD.ORG Subject: Re: NULL From: "M. Warner Losh" In-Reply-To: <200208210323.g7L3NTR04362@arch20m.dellroad.org> References: <20020821114425.Q26007-100000@gamplex.bde.org> <200208210323.g7L3NTR04362@arch20m.dellroad.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <200208210323.g7L3NTR04362@arch20m.dellroad.org> Archie Cobbs writes: : So my vote is for NULL = "((void *)0)" when compiling C code : (and leaving "0" when compiling C++, which can easily be different). That leaves just 7 files to ifdef. Well, 9 files from the egrep: dirent.h:#define NULL 0 locale.h:#define NULL 0 stddef.h:#define NULL 0 stdio.h:#define NULL 0 stdlib.h:#define NULL 0 string.h:#define NULL 0 time.h:#define NULL 0 wchar.h:#define NULL 0 Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 0:12: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F25C537B400 for ; Wed, 21 Aug 2002 00:12:03 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6E2D43E3B for ; Wed, 21 Aug 2002 00:12:03 -0700 (PDT) (envelope-from baka@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1921) id 85592AE027; Wed, 21 Aug 2002 00:12:03 -0700 (PDT) Date: Wed, 21 Aug 2002 00:12:03 -0700 From: Jon Mini To: "M. Warner Losh" Cc: archie@dellroad.org, freebsd-arch@FreeBSD.ORG Subject: Re: NULL Message-ID: <20020821071203.GL3751@elvis.mu.org> References: <20020821012849.GK3751@elvis.mu.org> <200208210140.g7L1eCJ03992@arch20m.dellroad.org> <20020821.003112.86889670.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020821.003112.86889670.imp@bsdimp.com> 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 M. Warner Losh [imp@bsdimp.com] wrote : > From the C-99 draft standard: > > 6.3.2.1 #3: > [#3] An integer constant expression with the value 0, or > such an expression cast to type void *, is called a null > pointer constant.46) If a null pointer constant is assigned > to or compared for equality to a pointer, the constant is > converted to a pointer of that type. Such a pointer, called > a null pointer, is guaranteed to compare unequal to a > pointer to any object or function. I stand corrected. -- Jonathan Mini http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 0:19:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34FD637B400 for ; Wed, 21 Aug 2002 00:19:20 -0700 (PDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF5143E4A for ; Wed, 21 Aug 2002 00:19:19 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0170.cvx22-bradley.dialup.earthlink.net ([209.179.198.170] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17hPlc-0002bb-00; Wed, 21 Aug 2002 00:19:00 -0700 Message-ID: <3D633EA2.102EBC0C@mindspring.com> Date: Wed, 21 Aug 2002 00:17:54 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "M. Warner Losh" Cc: archie@dellroad.org, freebsd-arch@FreeBSD.ORG Subject: Re: NULL References: <20020821114425.Q26007-100000@gamplex.bde.org> <200208210323.g7L3NTR04362@arch20m.dellroad.org> <20020821.003628.52042275.imp@bsdimp.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 "M. Warner Losh" wrote: > That leaves just 7 files to ifdef. Well, 9 files from the egrep: > > dirent.h:#define NULL 0 > locale.h:#define NULL 0 > stddef.h:#define NULL 0 > stdio.h:#define NULL 0 > stdlib.h:#define NULL 0 > string.h:#define NULL 0 > time.h:#define NULL 0 > wchar.h:#define NULL 0 We could split the difference and call it "8"... 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 Wed Aug 21 0:47: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF57C37B400 for ; Wed, 21 Aug 2002 00:46:59 -0700 (PDT) Received: from infinitive.futureperfectcorporation.com (infinitive.futureperfectcorporation.com [196.25.137.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF4743E4A for ; Wed, 21 Aug 2002 00:46:57 -0700 (PDT) (envelope-from nbm@gerund.futureperfectcorporation.com) Received: (qmail 79150 invoked by uid 0); 21 Aug 2002 07:46:47 -0000 Received: from gerund.futureperfectcorporation.com (196.25.137.65) by infinitive.futureperfectcorporation.com with DES-CBC3-SHA encrypted SMTP; 21 Aug 2002 07:46:47 -0000 Received: (qmail 58237 invoked by uid 1001); 21 Aug 2002 07:48:19 -0000 Date: Wed, 21 Aug 2002 09:48:19 +0200 From: Neil Blakey-Milner To: Luigi Rizzo Cc: arch@freebsd.org Subject: Re: ugliness in rc.* scripts Message-ID: <20020821074819.GA58163@mithrandr.moria.org> References: <20020820232538.A53816@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020820232538.A53816@iguana.icir.org> User-Agent: Mutt/1.3.27i Organization: iTouch Technical and Architectural Services X-Operating-System: FreeBSD 4.3-RELEASE i386 X-URL: http://mithrandr.moria.org/nbm/ 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 2002-08-20 (23:25), Luigi Rizzo wrote: > Hi, > in various rc.* scripts we have multiple instances of > constructs like this: > > case ${some_config_variable} in > [Mm][Ii][Xx][Ed]_[Cc][Aa][Ss][Ee]_[Ss][Tt][Rr][Ii][Nn][Gg]) > .... > > which is not the most desirable thing in terms of readability. > This would be easily fixed by moving /usr/bin/tr to /bin/tr (statically > linked) and doing > > tolower() { > echo `tr A-Z a-z <<_EOF > $*` > } > > case `tolower ${some_config_variable}` in > mixed_case_string) > ... > > > (btw, i am not sure why, in the above example the _EOF delimited > is not required nor i can find any place to put it without being > processed as stdin. Perhaps a bug in /bin/sh ?) > > Anyways, should we go for this ? I believe our scripts would be > greatly improved. I believe the argument for 'case' and those mixed case strings is that it doesn't spawn a process, whereas "if [ " did at the time. Using 'echo' and 'tr' and two ``'s will spawn four shells (or something like that). Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 0:49: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF1B537B400 for ; Wed, 21 Aug 2002 00:49:01 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3403A43E7B for ; Wed, 21 Aug 2002 00:49:01 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g7L7mp27085667; Wed, 21 Aug 2002 00:48:51 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g7L7mp1e085662; Wed, 21 Aug 2002 00:48:51 -0700 (PDT) Date: Wed, 21 Aug 2002 00:48:51 -0700 From: "David O'Brien" To: Luigi Rizzo Cc: arch@freebsd.org Subject: Re: ugliness in rc.* scripts Message-ID: <20020821074851.GA82634@dragon.nuxi.com> Reply-To: developers@freebsd.org Mail-Followup-To: David O'Brien , Luigi Rizzo , arch@freebsd.org References: <20020820232538.A53816@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020820232538.A53816@iguana.icir.org> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Aug 20, 2002 at 11:25:38PM -0700, Luigi Rizzo wrote: > which is not the most desirable thing in terms of readability. Agreed. > This would be easily fixed by moving /usr/bin/tr to /bin/tr (statically > linked) and doing > > tolower() { > echo `tr A-Z a-z <<_EOF > $*` > } > > case `tolower ${some_config_variable}` in > mixed_case_string) > ... This is an interesting idea. For boolean knobs, I'd really like to see us use the NetBSD way: # checkyesno var # Test $1 variable, and warn if not set to YES or NO. # Return 0 if it's "yes" (et al), nonzero otherwise. # checkyesno() { eval _value=\$${1} debug "checkyesno: $1 is set to $_value." case $_value in # "yes", "true", "on", or "1" [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) return 0 ;; # "no", "false", "off", or "0" [Nn][Oo]|[Ff][Aa][Ll][Ss][Ee]|[Oo][Ff][Ff]|0) return 1 ;; *) warn "\$${1} is not set properly." return 1 ;; esac } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 5:26:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5743037B400 for ; Wed, 21 Aug 2002 05:26:21 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B95243E6E for ; Wed, 21 Aug 2002 05:26:21 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id D6C87AE165; Wed, 21 Aug 2002 05:26:20 -0700 (PDT) Date: Wed, 21 Aug 2002 05:26:20 -0700 From: Maxime Henrion To: arch@FreeBSD.org Cc: tlambert2@mindspring.com Subject: Re: Solving the stack gap issue Message-ID: <20020821122620.GD86074@elvis.mu.org> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> <15714.17605.575558.398279@grasshopper.cs.duke.edu> <20020820153515.GL75574@elvis.mu.org> <20020820184624.GB86074@elvis.mu.org> <3D62D292.D0F3FEE6@mindspring.com> <20020821011201.GC86074@elvis.mu.org> <3D632BA8.45C64D10@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D632BA8.45C64D10@mindspring.com> 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 Terry Lambert wrote: > Maxime Henrion wrote: > > Terry Lambert wrote: > > > I thought this was already do-able on a call by call basis? From > > > sysent.h: > > [ripped code] > > > > I'm aware of this flag, the subject of this thread was about *removing* > > it and let the syscalls acquire Giant on an invidual basis. > > I think you've misinterpreted. > > Can't this be done one function at a time *using this flag*? > > I don't see what the big deal is about, if this can be done > incrementally, is all. In the p4 branch I was talking about, all the syscalls have been taken care of already. That's why the SYF_MPSAFE flag has been removed. Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 6:18:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 797BC37B43D for ; Wed, 21 Aug 2002 06:18:26 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3253743E70 for ; Wed, 21 Aug 2002 06:18:26 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7LDIOIb056596; Wed, 21 Aug 2002 06:18:24 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7LDIN85056595; Wed, 21 Aug 2002 06:18:23 -0700 (PDT) (envelope-from rizzo) Date: Wed, 21 Aug 2002 06:18:22 -0700 From: Luigi Rizzo To: Neil Blakey-Milner Cc: arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts Message-ID: <20020821061822.A56560@iguana.icir.org> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020821074819.GA58163@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Wed, Aug 21, 2002 at 09:48:19AM +0200 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, Aug 21, 2002 at 09:48:19AM +0200, Neil Blakey-Milner wrote: ... > > This would be easily fixed by moving /usr/bin/tr to /bin/tr (statically > > linked) and doing > > > > tolower() { > > echo `tr A-Z a-z <<_EOF > > $*` > > } > > > > case `tolower ${some_config_variable}` in > > mixed_case_string) ... > I believe the argument for 'case' and those mixed case strings is that > it doesn't spawn a process, whereas "if [ " did at the time. Using > 'echo' and 'tr' and two ``'s will spawn four shells (or something like > that). i think it is only one process -- echo is a builtin, tolower is a shell function. In any case, we never cared about performance in the rc scripts, not spawning processes (e.g. calling scripts with . instead of sh) has only to do with letting variable assignements be visible in the caller. cheers luigi > Neil > -- > Neil Blakey-Milner > nbm@mithrandr.moria.org > > 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 Aug 21 8:41:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 568B037B401 for ; Wed, 21 Aug 2002 08:41:56 -0700 (PDT) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6838F43E4A for ; Wed, 21 Aug 2002 08:41:55 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [::1]) by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet6 id g7LFfe343125; Thu, 22 Aug 2002 00:41:41 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) Cc: arch@FreeBSD.ORG In-Reply-To: <20020821061822.A56560@iguana.icir.org> References: <20020821074819.GA58163@mithrandr.moria.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821061822.A56560@iguana.icir.org> X-User-Agent: Mew/1.94.2 XEmacs/21.5 (bamboo) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 11 From: Makoto Matsushita To: rizzo@icir.org Subject: Re: ugliness in rc.* scripts Date: Thu, 22 Aug 2002 00:41:37 +0900 Message-Id: <20020822004137T.matusita@jp.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 rizzo> In any case, we never cared about performance in the rc rizzo> scripts, not spawning processes (e.g. calling scripts with . rizzo> instead of sh) has only to do with letting variable rizzo> assignements be visible in the caller. tr(1) is in /usr/bin, and we can't assume that /usr partition is always available while system startup. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 8:43:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EEBD37B400 for ; Wed, 21 Aug 2002 08:43:18 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27C1043E3B for ; Wed, 21 Aug 2002 08:43:18 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7LFhHIb059142; Wed, 21 Aug 2002 08:43:17 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7LFhHJb059141; Wed, 21 Aug 2002 08:43:17 -0700 (PDT) (envelope-from rizzo) Date: Wed, 21 Aug 2002 08:43:17 -0700 From: Luigi Rizzo To: Makoto Matsushita Cc: arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts Message-ID: <20020821084317.A59085@iguana.icir.org> References: <20020821074819.GA58163@mithrandr.moria.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821061822.A56560@iguana.icir.org> <20020822004137T.matusita@jp.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020822004137T.matusita@jp.FreeBSD.org>; from matusita@jp.FreeBSD.org on Thu, Aug 22, 2002 at 12:41:37AM +0900 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, Aug 22, 2002 at 12:41:37AM +0900, Makoto Matsushita wrote: > > rizzo> In any case, we never cared about performance in the rc > rizzo> scripts, not spawning processes (e.g. calling scripts with . > rizzo> instead of sh) has only to do with letting variable > rizzo> assignements be visible in the caller. > > tr(1) is in /usr/bin, and we can't assume that /usr partition is > always available while system startup. this is why in the original message i mentioned the need to move it to /bin luigi > -- - > Makoto `MAR' Matsushita > > 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 Aug 21 8:53:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 890AB37B400 for ; Wed, 21 Aug 2002 08:53:24 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FB4443E6E for ; Wed, 21 Aug 2002 08:53:23 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7LFrLFl023276; Wed, 21 Aug 2002 09:53:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Aug 2002 09:52:52 -0600 (MDT) Message-Id: <20020821.095252.61131232.imp@bsdimp.com> To: nbm@mithrandr.moria.org Cc: rizzo@icir.org, arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts From: "M. Warner Losh" In-Reply-To: <20020821074819.GA58163@mithrandr.moria.org> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20020821074819.GA58163@mithrandr.moria.org> Neil Blakey-Milner writes: : On Tue 2002-08-20 (23:25), Luigi Rizzo wrote: : > Hi, : > in various rc.* scripts we have multiple instances of : > constructs like this: : > : > case ${some_config_variable} in : > [Mm][Ii][Xx][Ed]_[Cc][Aa][Ss][Ee]_[Ss][Tt][Rr][Ii][Nn][Gg]) : > .... : > : > which is not the most desirable thing in terms of readability. : > This would be easily fixed by moving /usr/bin/tr to /bin/tr (statically : > linked) and doing : > : > tolower() { : > echo `tr A-Z a-z <<_EOF : > $*` : > } : > : > case `tolower ${some_config_variable}` in : > mixed_case_string) : > ... : > : > : > (btw, i am not sure why, in the above example the _EOF delimited : > is not required nor i can find any place to put it without being : > processed as stdin. Perhaps a bug in /bin/sh ?) : > : > Anyways, should we go for this ? I believe our scripts would be : > greatly improved. : : I believe the argument for 'case' and those mixed case strings is that : it doesn't spawn a process, whereas "if [ " did at the time. Using : 'echo' and 'tr' and two ``'s will spawn four shells (or something like : that). Why not just have case -i ${some_config_variable} in to do the case folding. This would be a backwards compatible extension: The syntax of the case command is case word in pattern) list ;; ... esac where word is singular, not plural (like in the for loop syntax). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 8:57:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 976AA37B400 for ; Wed, 21 Aug 2002 08:57:55 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A681643E4A for ; Wed, 21 Aug 2002 08:57:54 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7LFvrFl023295; Wed, 21 Aug 2002 09:57:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Aug 2002 09:57:26 -0600 (MDT) Message-Id: <20020821.095726.109035410.imp@bsdimp.com> To: rizzo@icir.org Cc: nbm@mithrandr.moria.org, arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts From: "M. Warner Losh" In-Reply-To: <20020821061822.A56560@iguana.icir.org> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821061822.A56560@iguana.icir.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <20020821061822.A56560@iguana.icir.org> Luigi Rizzo writes: : On Wed, Aug 21, 2002 at 09:48:19AM +0200, Neil Blakey-Milner wrote: : ... : > > This would be easily fixed by moving /usr/bin/tr to /bin/tr (statically : > > linked) and doing : > > : > > tolower() { : > > echo `tr A-Z a-z <<_EOF : > > $*` : > > } : > > : > > case `tolower ${some_config_variable}` in : > > mixed_case_string) : ... : > I believe the argument for 'case' and those mixed case strings is that : > it doesn't spawn a process, whereas "if [ " did at the time. Using : > 'echo' and 'tr' and two ``'s will spawn four shells (or something like : > that). : : i think it is only one process -- echo is a builtin, tolower is a shell : function. In any case, we never cared about performance in the rc scripts, : not spawning processes (e.g. calling scripts with . instead of sh) has : only to do with letting variable assignements be visible in the caller. Actually, we have cared about the performance of shell scripts in the past. NetBSD got a nasty surprise when they went to their new rc system when they started greatly increasing the number of forks in the boot process. Some machines went from taking 10 seconds to boot to taking 30 minutes. They fixed this in two ways: 1) by reducing the number of forks in the rc scripts and 2) by fixing bugs in that architecture that make fork insanely slow. We still need to boot fast enough that things aren't insanely slow on a 32MB 66MHz 486. There's enough embedded people doing embedded things that will likely want 5.0 that we have to keep that in mind. The company I work for has systems with 133MHz 486-class CPUs that we ship with 32MB RAM. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 9:19:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 482A337B400 for ; Wed, 21 Aug 2002 09:19:46 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7DA343E6A for ; Wed, 21 Aug 2002 09:19:45 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7LGJhIb059428; Wed, 21 Aug 2002 09:19:43 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7LGJgqc059427; Wed, 21 Aug 2002 09:19:42 -0700 (PDT) (envelope-from rizzo) Date: Wed, 21 Aug 2002 09:19:42 -0700 From: Luigi Rizzo To: "M. Warner Losh" Cc: nbm@mithrandr.moria.org, arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts Message-ID: <20020821091942.B59085@iguana.icir.org> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821061822.A56560@iguana.icir.org> <20020821.095726.109035410.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020821.095726.109035410.imp@bsdimp.com>; from imp@bsdimp.com on Wed, Aug 21, 2002 at 09:57:26AM -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 On Wed, Aug 21, 2002 at 09:57:26AM -0600, M. Warner Losh wrote: > In message: <20020821061822.A56560@iguana.icir.org> > Luigi Rizzo writes: ... > : i think it is only one process -- echo is a builtin, tolower is a shell > : function. In any case, we never cared about performance in the rc scripts, > : not spawning processes (e.g. calling scripts with . instead of sh) has > : only to do with letting variable assignements be visible in the caller. > > Actually, we have cared about the performance of shell scripts in the > past. NetBSD got a nasty surprise when they went to their new rc ... oh man, should i always include a track record when i make a posting ? sure, we do care about performance everywhere (except perhaps in -current :). I have spent a huge amount of time doing performance improvements in FreeBSD all across the board, and i do care about embedded things, as witnessed by my work on picobsd... my point is that a few occasional process forks during startup because of judiciously called external processes (i certainly don't plan to put these things within a loop) won't hurt too much. I would say that the impact would be much lower than what we currently pay by having statically-linked, non-crunched binaries in /bin and /sbin. Also, following your previous suggestion about a "case -i" : the problem is that then our scripts would then become non-portable. If we have to go to non-standard approach, i would rather implement some commands as shell builtins so that we do not pay the fork overhead in a fully transparent way. E.g. 'tr' could be one, expr another one, rm another one (it is run within a couple of loops in /etc/rc ...) I would also look for some way to implement (cheaply) associative arrays... cheers luigi > boot process. Some machines went from taking 10 seconds to boot to > taking 30 minutes. They fixed this in two ways: 1) by reducing the > number of forks in the rc scripts and 2) by fixing bugs in that > architecture that make fork insanely slow. > > We still need to boot fast enough that things aren't insanely slow on > a 32MB 66MHz 486. There's enough embedded people doing embedded > things that will likely want 5.0 that we have to keep that in mind. > The company I work for has systems with 133MHz 486-class CPUs that we > ship with 32MB RAM. > > Warner > > 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 Aug 21 10:19:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6351637B408 for ; Wed, 21 Aug 2002 10:19:52 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 893F743E70 for ; Wed, 21 Aug 2002 10:19:48 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 56779 invoked by uid 1000); 21 Aug 2002 17:19:49 -0000 Date: Wed, 21 Aug 2002 10:19:49 -0700 (PDT) From: Nate Lawson To: Jon Mini Cc: arch@FreeBSD.ORG Subject: Re: timestamping kernel messages In-Reply-To: <20020821005414.GJ3751@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, 20 Aug 2002, Jon Mini wrote: > > This would also give us a good architecture for hooking up > > ethernet consoles. > > Do you mean console over TCP? > > I'd really like to see gdb -k over TCP, and asynchronous, too. It would be > nice to only tie one kernel thread to a gdb process and not the entire > system. I'd prefer UDP since interrupts are disabled and thus TCP's timers would need to be polled. A couple of related messages: <15677.32896.256029.156431@grasshopper.cs.duke.edu> -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 11: 3:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5C2237B400 for ; Wed, 21 Aug 2002 11:03:57 -0700 (PDT) Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C285943EA3 for ; Wed, 21 Aug 2002 11:03:56 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh by axl.seasidesoftware.co.za with local (Exim 4.10) id 17hZpY-000ABS-00; Wed, 21 Aug 2002 20:03:44 +0200 Date: Wed, 21 Aug 2002 20:03:44 +0200 From: Sheldon Hearn To: "M. Warner Losh" Cc: nbm@mithrandr.moria.org, rizzo@icir.org, arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts Message-ID: <20020821180344.GB33546@starjuice.net> Mail-Followup-To: "M. Warner Losh" , nbm@mithrandr.moria.org, rizzo@icir.org, arch@FreeBSD.ORG References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821.095252.61131232.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020821.095252.61131232.imp@bsdimp.com> User-Agent: Mutt/1.5.1i 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/08/21 09:52), M. Warner Losh wrote: > Why not just have > > case -i ${some_config_variable} in > > to do the case folding. This would be a backwards compatible extension: I don't think the ugliness involved in the rc scripts justifies any of the proposed hack-arounds yet. And if you _were_ going to hack around, you'd want to introduce a form of parameter expansion that did lower-case transliteration for you, e.g. ${parameter:lc} Much more useful, but non-portable. But I digress. I don't think the ugliness is ugly enough. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 12:38:55 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C89E437B400; Wed, 21 Aug 2002 12:38:51 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07E3543E81; Wed, 21 Aug 2002 12:38:51 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g7LJZQRo059065; Wed, 21 Aug 2002 21:35:26 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jon Mini Cc: Alexander Leidinger , arch@freebsd.org Subject: Re: timestamping kernel messages In-Reply-To: Your message of "Tue, 20 Aug 2002 17:54:14 PDT." <20020821005414.GJ3751@elvis.mu.org> Date: Wed, 21 Aug 2002 21:35:26 +0200 Message-ID: <59064.1029958526@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020821005414.GJ3751@elvis.mu.org>, Jon Mini writes: >Poul-Henning Kamp [phk@critter.freebsd.dk] wrote : > >> I think we need to revamp the console/logging system in toto. >It has several problems that really irritate me, such as the fact >that messages are sent to the console one character at a time, >resulting in jumbled messages like: > > | MSoMuPn:t iAnPg CrPoUo t# 1f rLoamu nucfhse:d/!d > | ev/ad0a I think we need to recognize that "_the_ console" is not an appropriate metaphor anymore. We have, at least the following roles: The place we print the kernels bootstrap information. The place the kernel can ask questions during bootstrap. The place we print panics The place we print kernel debugging information. The place we interract with gdb The place we print the single-user to multi-user information The place we print certain run-time error/log messages In addition to this we have at least: The channel for sending kernel log events to syslogd I have no idea what the right solution looks like, but the current code isn't it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 14:39:59 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B62B437B400 for ; Wed, 21 Aug 2002 14:39:54 -0700 (PDT) Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by mx1.FreeBSD.org (Postfix) with SMTP id 5BB4B43E42 for ; Wed, 21 Aug 2002 14:39:54 -0700 (PDT) (envelope-from jabley@felix.automagic.org) Received: (qmail 94630 invoked by uid 1000); 21 Aug 2002 21:39:54 -0000 Date: Wed, 21 Aug 2002 14:39:54 -0700 From: Joe Abley To: Sheldon Hearn Cc: "M. Warner Losh" , nbm@mithrandr.moria.org, rizzo@icir.org, arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts Message-ID: <20020821213954.GR92068@felix.automagic.org> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821.095252.61131232.imp@bsdimp.com> <20020821180344.GB33546@starjuice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020821180344.GB33546@starjuice.net> User-Agent: Mutt/1.4i 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, Aug 21, 2002 at 08:03:44PM +0200, Sheldon Hearn wrote: > On (2002/08/21 09:52), M. Warner Losh wrote: > > > Why not just have > > > > case -i ${some_config_variable} in > > > > to do the case folding. This would be a backwards compatible extension: > > I don't think the ugliness involved in the rc scripts justifies any of > the proposed hack-arounds yet. > > And if you _were_ going to hack around, you'd want to introduce a form > of parameter expansion that did lower-case transliteration for you, e.g. > > ${parameter:lc} > > Much more useful, but non-portable. Non-portability might be tolerable if there was some explicit switch required to turn on support for the non-portable bits. It's not as if FreeBSD startup scripts need to be run in many environments with many different sh's. If portability is a concern for reasons I am missing, then zsh and ksh both contain parametere expansion flags for case manipulation. That line of reasoning leads to quite a different bikeshed, however. > But I digress. I don't think the ugliness is ugly enough. Me neither. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 15:43:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C366637B405; Wed, 21 Aug 2002 15:43:32 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48F7243E8A; Wed, 21 Aug 2002 15:43:31 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 WAA09141; Wed, 21 Aug 2002 22:43:29 GMT Date: Thu, 22 Aug 2002 08:49:55 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: developers@FreeBSD.ORG Cc: Luigi Rizzo , Subject: Re: ugliness in rc.* scripts In-Reply-To: <20020821074851.GA82634@dragon.nuxi.com> Message-ID: <20020822084643.V764-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 Wed, 21 Aug 2002, David O'Brien wrote: > This is an interesting idea. For boolean knobs, I'd really like to see > us use the NetBSD way: > > # checkyesno var > # Test $1 variable, and warn if not set to YES or NO. > # Return 0 if it's "yes" (et al), nonzero otherwise. > # > checkyesno() > { > eval _value=\$${1} > debug "checkyesno: $1 is set to $_value." > case $_value in > > # "yes", "true", "on", or "1" > [Yy][Ee][Ss]|[Tt][Rr][Uu][Ee]|[Oo][Nn]|1) > return 0 > ;; > > # "no", "false", "off", or "0" > [Nn][Oo]|[Ff][Aa][Ll][Ss][Ee]|[Oo][Ff][Ff]|0) > return 1 > ;; > *) > warn "\$${1} is not set properly." > return 1 > ;; > esac > } This would be better if the code implemented what the comment says it does and warned about misspellings of YES and NO. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 16:30:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 834F037B405 for ; Wed, 21 Aug 2002 16:30:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23DF843E6E for ; Wed, 21 Aug 2002 16:30:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA95725; Wed, 21 Aug 2002 16:23:25 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7LNMcc08044; Wed, 21 Aug 2002 16:22:38 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208212322.g7LNMcc08044@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821.003628.52042275.imp@bsdimp.com> "from M. Warner Losh at Aug 21, 2002 00:36:28 am" To: "M. Warner Losh" Date: Wed, 21 Aug 2002 16:22:38 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 M. Warner Losh writes: > In message: <200208210323.g7L3NTR04362@arch20m.dellroad.org> > Archie Cobbs writes: > : So my vote is for NULL = "((void *)0)" when compiling C code > : (and leaving "0" when compiling C++, which can easily be different). > > That leaves just 7 files to ifdef. Well, 9 files from the egrep: The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT' work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf. Does anyone have an objection to this patch? At the minimum, I'd like to apply the fixes for the incorrect uses of 'NULL' where '0' is really meant. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com Index: include/dirent.h =================================================================== RCS file: /home/cvs/freebsd/src/include/dirent.h,v retrieving revision 1.11 diff -u -r1.11 dirent.h --- include/dirent.h 23 Mar 2002 17:24:53 -0000 1.11 +++ include/dirent.h 21 Aug 2002 23:09:04 -0000 @@ -77,7 +77,11 @@ #define __DTF_READALL 0x0008 /* everything has been read */ #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #endif /* _POSIX_SOURCE */ Index: include/locale.h =================================================================== RCS file: /home/cvs/freebsd/src/include/locale.h,v retrieving revision 1.6 diff -u -r1.6 locale.h --- include/locale.h 23 Mar 2002 17:24:53 -0000 1.6 +++ include/locale.h 21 Aug 2002 23:09:04 -0000 @@ -59,7 +59,11 @@ }; #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #define LC_ALL 0 Index: include/stddef.h =================================================================== RCS file: /home/cvs/freebsd/src/include/stddef.h,v retrieving revision 1.7 diff -u -r1.7 stddef.h --- include/stddef.h 9 Jul 2002 05:13:30 -0000 1.7 +++ include/stddef.h 21 Aug 2002 23:09:04 -0000 @@ -63,7 +63,11 @@ #endif #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #define offsetof(type, member) __offsetof(type, member) Index: include/stdio.h =================================================================== RCS file: /home/cvs/freebsd/src/include/stdio.h,v retrieving revision 1.44 diff -u -r1.44 stdio.h --- include/stdio.h 15 Aug 2002 10:28:51 -0000 1.44 +++ include/stdio.h 21 Aug 2002 23:09:04 -0000 @@ -49,7 +49,11 @@ #endif #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif typedef _BSD_OFF_T_ fpos_t; Index: include/stdlib.h =================================================================== RCS file: /home/cvs/freebsd/src/include/stdlib.h,v retrieving revision 1.38 diff -u -r1.38 stdlib.h --- include/stdlib.h 15 Aug 2002 09:25:03 -0000 1.38 +++ include/stdlib.h 21 Aug 2002 23:09:04 -0000 @@ -81,7 +81,11 @@ #endif #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #define EXIT_FAILURE 1 Index: include/string.h =================================================================== RCS file: /home/cvs/freebsd/src/include/string.h,v retrieving revision 1.14 diff -u -r1.14 string.h --- include/string.h 15 Apr 2002 03:21:21 -0000 1.14 +++ include/string.h 21 Aug 2002 23:09:04 -0000 @@ -54,7 +54,11 @@ #endif #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif __BEGIN_DECLS Index: include/time.h =================================================================== RCS file: /home/cvs/freebsd/src/include/time.h,v retrieving revision 1.27 diff -u -r1.27 time.h --- include/time.h 14 Aug 2002 23:20:48 -0000 1.27 +++ include/time.h 21 Aug 2002 23:09:04 -0000 @@ -60,7 +60,11 @@ #define CLOCKS_PER_SEC _BSD_CLOCKS_PER_SEC_ #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #ifdef _BSD_CLOCK_T_ Index: include/unistd.h =================================================================== RCS file: /home/cvs/freebsd/src/include/unistd.h,v retrieving revision 1.55 diff -u -r1.55 unistd.h --- include/unistd.h 15 Jul 2002 22:21:27 -0000 1.55 +++ include/unistd.h 21 Aug 2002 23:09:13 -0000 @@ -71,7 +71,11 @@ #define STDERR_FILENO 2 /* standard error file descriptor */ #ifndef NULL -#define NULL 0 /* null pointer constant */ +#if defined(__cplusplus) +#define NULL 0 /* null pointer constant */ +#else +#define NULL ((void *)0) /* null pointer constant */ +#endif #endif #if __XSI_VISIBLE || __POSIX_VISIBLE >= 200112 Index: include/wchar.h =================================================================== RCS file: /home/cvs/freebsd/src/include/wchar.h,v retrieving revision 1.15 diff -u -r1.15 wchar.h --- include/wchar.h 20 Aug 2002 22:44:40 -0000 1.15 +++ include/wchar.h 21 Aug 2002 23:09:13 -0000 @@ -73,7 +73,11 @@ #include #ifndef NULL +#if defined(__cplusplus) #define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #ifdef _BSD_MBSTATE_T_ Index: include/rpc/types.h =================================================================== RCS file: /home/cvs/freebsd/src/include/rpc/types.h,v retrieving revision 1.10 diff -u -r1.10 types.h --- include/rpc/types.h 19 Mar 2001 12:49:47 -0000 1.10 +++ include/rpc/types.h 21 Aug 2002 23:09:13 -0000 @@ -60,7 +60,11 @@ # define TRUE (1) #endif #ifndef NULL -# define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #define mem_alloc(bsize) calloc(1, bsize) Index: lib/libstand/stand.h =================================================================== RCS file: /home/cvs/freebsd/src/lib/libstand/stand.h,v retrieving revision 1.35 diff -u -r1.35 stand.h --- lib/libstand/stand.h 21 Aug 2002 09:30:45 -0000 1.35 +++ lib/libstand/stand.h 21 Aug 2002 23:09:27 -0000 @@ -72,7 +72,11 @@ #define PCHK(fmt, args...) {printf("%s(%d): " fmt "\n", __FUNCTION__, __LINE__ , ##args); getchar();} #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif /* Avoid unwanted userlandish components */ Index: sbin/restore/restore.c =================================================================== RCS file: /home/cvs/freebsd/src/sbin/restore/restore.c,v retrieving revision 1.12 diff -u -r1.12 restore.c --- sbin/restore/restore.c 21 Jun 2002 06:18:00 -0000 1.12 +++ sbin/restore/restore.c 21 Aug 2002 23:09:51 -0000 @@ -458,7 +458,7 @@ * for it, we discard the name knowing that it will be on the * next incremental tape. */ - case NULL: + case 0: fprintf(stderr, "%s: (inode %d) not found on tape\n", name, ino); break; Index: sys/dev/syscons/scvtb.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/dev/syscons/scvtb.c,v retrieving revision 1.8 diff -u -r1.8 scvtb.c --- sys/dev/syscons/scvtb.c 29 Jun 2001 08:24:56 -0000 1.8 +++ sys/dev/syscons/scvtb.c 21 Aug 2002 23:10:23 -0000 @@ -51,7 +51,7 @@ vtb->vtb_cols = cols; vtb->vtb_rows = rows; vtb->vtb_size = cols*rows; - vtb->vtb_buffer = NULL; + vtb->vtb_buffer = 0; vtb->vtb_tail = 0; switch (type) { @@ -62,7 +62,7 @@ (vm_offset_t)malloc(cols*rows*sizeof(u_int16_t), M_DEVBUF, (wait) ? M_WAITOK : M_NOWAIT); - if (vtb->vtb_buffer != NULL) { + if (vtb->vtb_buffer != 0) { bzero((void *)sc_vtb_pointer(vtb, 0), cols*rows*sizeof(u_int16_t)); vtb->vtb_flags |= VTB_ALLOCED; @@ -92,11 +92,11 @@ vtb->vtb_tail = 0; p = vtb->vtb_buffer; - vtb->vtb_buffer = NULL; + vtb->vtb_buffer = 0; switch (vtb->vtb_type) { case VTB_MEMORY: case VTB_RINGBUFFER: - if ((vtb->vtb_flags & VTB_ALLOCED) && (p != NULL)) + if ((vtb->vtb_flags & VTB_ALLOCED) && (p != 0)) free((void *)p, M_DEVBUF); break; default: Index: sys/dev/syscons/syscons.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/dev/syscons/syscons.c,v retrieving revision 1.387 diff -u -r1.387 syscons.c --- sys/dev/syscons/syscons.c 19 Aug 2002 16:32:09 -0000 1.387 +++ sys/dev/syscons/syscons.c 21 Aug 2002 23:10:31 -0000 @@ -867,7 +867,7 @@ hstp = scp->history->vtb_buffer + sc_vtb_tail(scp->history) * sizeof(u_int16_t) + ptr->x * sizeof(u_int16_t); else - hstp = NULL; + hstp = 0; retval = 0; for (lnum = 0; lnum < (ptr->y + ptr->ysize); lnum++) { Index: sys/i386/i386/busdma_machdep.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/i386/i386/busdma_machdep.c,v retrieving revision 1.26 diff -u -r1.26 busdma_machdep.c --- sys/i386/i386/busdma_machdep.c 19 Apr 2002 22:58:09 -0000 1.26 +++ sys/i386/i386/busdma_machdep.c 21 Aug 2002 23:10:31 -0000 @@ -571,7 +571,7 @@ dmat->lowaddr, PAGE_SIZE, 0); - if (bpage->vaddr == NULL) { + if (bpage->vaddr == 0) { free(bpage, M_DEVBUF); break; } Index: sys/i386/i386/dump_machdep.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/i386/i386/dump_machdep.c,v retrieving revision 1.3 diff -u -r1.3 dump_machdep.c --- sys/i386/i386/dump_machdep.c 4 May 2002 17:45:48 -0000 1.3 +++ sys/i386/i386/dump_machdep.c 21 Aug 2002 23:10:31 -0000 @@ -77,7 +77,7 @@ dumplo = di->mediaoffset + di->mediasize - Maxmem * (off_t)PAGE_SIZE; dumplo -= sizeof kdh * 2; - i = di->dumper(di->priv, &kdh, NULL, dumplo, sizeof kdh); + i = di->dumper(di->priv, &kdh, 0, dumplo, sizeof kdh); if (i) printf("\nDump failed writing header (%d)\n", i); dumplo += sizeof kdh; @@ -100,7 +100,7 @@ printf(" %d", count / (1024 * 1024 / PAGE_SIZE)); mb = i; } - i = di->dumper(di->priv, va, NULL, dumplo, left * PAGE_SIZE); + i = di->dumper(di->priv, va, 0, dumplo, left * PAGE_SIZE); if (i) break; count += left; @@ -114,10 +114,10 @@ } if (i) printf("\nDump failed writing data (%d)\n", i); - i = di->dumper(di->priv, &kdh, NULL, dumplo, sizeof kdh); + i = di->dumper(di->priv, &kdh, 0, dumplo, sizeof kdh); if (i) printf("\nDump failed writing trailer (%d)\n", i); - di->dumper(di->priv, NULL, NULL, 0, 0); /* tell them we are done */ + di->dumper(di->priv, NULL, 0, 0, 0); /* tell them we are done */ printf("\nDump complete\n"); return; } Index: sys/i386/i386/pmap.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/i386/i386/pmap.c,v retrieving revision 1.362 diff -u -r1.362 pmap.c --- sys/i386/i386/pmap.c 18 Aug 2002 02:13:50 -0000 1.362 +++ sys/i386/i386/pmap.c 21 Aug 2002 23:10:35 -0000 @@ -2508,7 +2508,7 @@ if (addr < starta || addr >= entry->end) continue; - if ((*pmap_pde(pmap, addr)) == NULL) + if ((*pmap_pde(pmap, addr)) == 0) continue; pte = vtopte(addr); Index: sys/kern/subr_disk.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/kern/subr_disk.c,v retrieving revision 1.55 diff -u -r1.55 subr_disk.c --- sys/kern/subr_disk.c 9 Apr 2002 15:43:22 -0000 1.55 +++ sys/kern/subr_disk.c 21 Aug 2002 23:10:35 -0000 @@ -271,7 +271,7 @@ return error; } -SYSCTL_PROC(_kern, OID_AUTO, disks, CTLTYPE_STRING | CTLFLAG_RD, 0, NULL, +SYSCTL_PROC(_kern, OID_AUTO, disks, CTLTYPE_STRING | CTLFLAG_RD, 0, 0, sysctl_disks, "A", "names of available disks"); /* Index: sys/kern/sys_pipe.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/kern/sys_pipe.c,v retrieving revision 1.117 diff -u -r1.117 sys_pipe.c --- sys/kern/sys_pipe.c 19 Aug 2002 16:59:36 -0000 1.117 +++ sys/kern/sys_pipe.c 21 Aug 2002 23:10:43 -0000 @@ -360,7 +360,7 @@ /* so pipespace()->pipe_free_kmem() doesn't follow junk pointer */ cpipe->pipe_buffer.object = NULL; #ifndef PIPE_NODIRECT - cpipe->pipe_map.kva = NULL; + cpipe->pipe_map.kva = 0; #endif /* * protect so pipeclose() doesn't follow a junk pointer @@ -1344,7 +1344,7 @@ cpipe->pipe_buffer.buffer = NULL; } #ifndef PIPE_NODIRECT - if (cpipe->pipe_map.kva != NULL) { + if (cpipe->pipe_map.kva != 0) { amountpipekva -= cpipe->pipe_buffer.size + PAGE_SIZE; kmem_free(kernel_map, cpipe->pipe_map.kva, Index: sys/sys/param.h =================================================================== RCS file: /home/cvs/freebsd/src/sys/sys/param.h,v retrieving revision 1.132 diff -u -r1.132 param.h --- sys/sys/param.h 24 Jul 2002 03:02:42 -0000 1.132 +++ sys/sys/param.h 21 Aug 2002 23:11:02 -0000 @@ -58,7 +58,11 @@ #define __FreeBSD_version 500038 /* Master, propagated to newvers */ #ifndef NULL -#define NULL 0 +#if defined(__cplusplus) +#define NULL 0 +#else +#define NULL ((void *)0) +#endif #endif #ifndef LOCORE Index: sys/vm/uma_core.c =================================================================== RCS file: /home/cvs/freebsd/src/sys/vm/uma_core.c,v retrieving revision 1.34 diff -u -r1.34 uma_core.c --- sys/vm/uma_core.c 5 Jul 2002 21:39:52 -0000 1.34 +++ sys/vm/uma_core.c 21 Aug 2002 23:11:10 -0000 @@ -835,7 +835,7 @@ vm_page_t p; int pages; - retkva = NULL; + retkva = 0; pages = zone->uz_pages; /* @@ -848,7 +848,7 @@ return (NULL); zkva = zone->uz_kva + pages * PAGE_SIZE; - if (retkva == NULL) + if (retkva == 0) retkva = zkva; pmap_qenter(zkva, &p, 1); bytes -= PAGE_SIZE; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 16:37: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32A8237B400 for ; Wed, 21 Aug 2002 16:37:03 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34BEF43E4A for ; Wed, 21 Aug 2002 16:37:02 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7LNauFl025645; Wed, 21 Aug 2002 17:36:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Aug 2002 17:36:53 -0600 (MDT) Message-Id: <20020821.173653.57449387.imp@bsdimp.com> To: archie@dellroad.org Cc: freebsd-arch@FreeBSD.ORG Subject: Re: NULL From: "M. Warner Losh" In-Reply-To: <200208212322.g7LNMcc08044@arch20m.dellroad.org> References: <20020821.003628.52042275.imp@bsdimp.com> <200208212322.g7LNMcc08044@arch20m.dellroad.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <200208212322.g7LNMcc08044@arch20m.dellroad.org> Archie Cobbs writes: : The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT' : work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf. : : Does anyone have an objection to this patch? Yes. I'm not sure that (void *)0 is the right thing to do. It can cause other problems and mask a different set of bugs, especially when you call functions that have no prototype in scope. : At the minimum, I'd like to apply the fixes for the incorrect uses : of 'NULL' where '0' is really meant. Those I don't have an objection to those fixes, since I myself have fixed some today :-) : Index: sbin/restore/restore.c I've already done this one. : Index: sys/dev/syscons/scvtb.c : Index: sys/dev/syscons/syscons.c : Index: sys/i386/i386/busdma_machdep.c : =================================================================== : RCS file: /home/cvs/freebsd/src/sys/i386/i386/busdma_machdep.c,v : retrieving revision 1.26 : diff -u -r1.26 busdma_machdep.c : --- sys/i386/i386/busdma_machdep.c 19 Apr 2002 22:58:09 -0000 1.26 : +++ sys/i386/i386/busdma_machdep.c 21 Aug 2002 23:10:31 -0000 : @@ -571,7 +571,7 @@ : dmat->lowaddr, : PAGE_SIZE, : 0); : - if (bpage->vaddr == NULL) { : + if (bpage->vaddr == 0) { : free(bpage, M_DEVBUF); : break; : } This one is conceptually OK. The problem with most of the ones in the kernel that you fixed are where we use an unsigned into to store an address. NULL is natural for thse, but wrong by some readings of the standard. I'm not sure we should be changing them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 17: 0: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00FA337B400 for ; Wed, 21 Aug 2002 17:00:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6590043E70 for ; Wed, 21 Aug 2002 17:00:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA95902; Wed, 21 Aug 2002 16:55:50 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7LNt5l08219; Wed, 21 Aug 2002 16:55:05 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208212355.g7LNt5l08219@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821.173653.57449387.imp@bsdimp.com> "from M. Warner Losh at Aug 21, 2002 05:36:53 pm" To: "M. Warner Losh" Date: Wed, 21 Aug 2002 16:55:05 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 M. Warner Losh writes: > : @@ -571,7 +571,7 @@ > : dmat->lowaddr, > : PAGE_SIZE, > : 0); > : - if (bpage->vaddr == NULL) { > : + if (bpage->vaddr == 0) { > : free(bpage, M_DEVBUF); > : break; > : } > > This one is conceptually OK. The problem with most of the ones in the > kernel that you fixed are where we use an unsigned into to store an > address. NULL is natural for thse, but wrong by some readings of the > standard. I'm not sure we should be changing them. Oops, too late... Anyway, in that situation it seems to me that a 'custom' define would be more appropriate, e.g.: #define VADDR_NULL 0 or what have you. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 17: 0:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D52E37B401 for ; Wed, 21 Aug 2002 17:00:06 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFBC943E75 for ; Wed, 21 Aug 2002 17:00:05 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id QAA95908; Wed, 21 Aug 2002 16:58:54 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7LNw8l08243; Wed, 21 Aug 2002 16:58:08 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208212358.g7LNw8l08243@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821.173653.57449387.imp@bsdimp.com> "from M. Warner Losh at Aug 21, 2002 05:36:53 pm" To: "M. Warner Losh" Date: Wed, 21 Aug 2002 16:58:08 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 M. Warner Losh writes: > : The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT' > : work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf. > : > : Does anyone have an objection to this patch? > > Yes. I'm not sure that (void *)0 is the right thing to do. It can > cause other problems and mask a different set of bugs, especially when > you call functions that have no prototype in scope. Can you elaborate? Seems like the same is true of "0".. e.g., suppose that pointers are larger than integers, and you call a variadic function with "NULL" as one of the extra parameters: printf("foo=%p num=%d\n", NULL, 123); This would get screwed with NULL=0 but work right with NULL=(void *)0. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 17:11:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD75B37B400 for ; Wed, 21 Aug 2002 17:11:36 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 597BA43E4A for ; Wed, 21 Aug 2002 17:11:36 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g7M0BH27045622; Wed, 21 Aug 2002 17:11:17 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g7M0BGmp045621; Wed, 21 Aug 2002 17:11:16 -0700 (PDT) Date: Wed, 21 Aug 2002 17:11:16 -0700 From: "David O'Brien" To: Archie Cobbs Cc: "M. Warner Losh" , freebsd-arch@FreeBSD.ORG Subject: Re: NULL Message-ID: <20020822001115.GA45577@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020821.003628.52042275.imp@bsdimp.com> <200208212322.g7LNMcc08044@arch20m.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208212322.g7LNMcc08044@arch20m.dellroad.org> User-Agent: Mutt/1.4i 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 Wed, Aug 21, 2002 at 04:22:38PM -0700, Archie Cobbs wrote: > M. Warner Losh writes: > > In message: <200208210323.g7L3NTR04362@arch20m.dellroad.org> > > Archie Cobbs writes: > > : So my vote is for NULL = "((void *)0)" when compiling C code > > : (and leaving "0" when compiling C++, which can easily be different). > > > > That leaves just 7 files to ifdef. Well, 9 files from the egrep: > > The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT' > work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf. > > Does anyone have an objection to this patch? Yes -- only because you haven't tested with the defaults of not having NO_WERROR=YES. I.e., if you commit this patch you really don't know if you will be breaking the world for the rest of us. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 17:45: 8 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC15837B400; Wed, 21 Aug 2002 17:45:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D79143E70; Wed, 21 Aug 2002 17:45:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id RAA96162; Wed, 21 Aug 2002 17:33:30 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7M0Wil08432; Wed, 21 Aug 2002 17:32:44 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208220032.g7M0Wil08432@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020822001115.GA45577@dragon.nuxi.com> "from David O'Brien at Aug 21, 2002 05:11:16 pm" To: obrien@FreeBSD.ORG Date: Wed, 21 Aug 2002 17:32:44 -0700 (PDT) Cc: Archie Cobbs , "M. Warner Losh" , freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 David O'Brien writes: > > The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT' > > work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf. > > > > Does anyone have an objection to this patch? > > Yes -- only because you haven't tested with the defaults of not having > NO_WERROR=YES. I.e., if you commit this patch you really don't know if > you will be breaking the world for the rest of us. OK. I wasn't sure what the current state of NO_WERROR was these days after reading this in UPDATING... 20020815: A "bug" in gcc(1) that was hiding warning in system headers was fixed. It's probably time to add -DNO_WERROR to your make line again. In any case, if/when this gets checked in I'll first make sure the kernel builds with -Werror. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 18:54:35 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DD4937B4AA for ; Wed, 21 Aug 2002 18:54:29 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7FD43E65 for ; Wed, 21 Aug 2002 18:54:27 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7M1sOFl026216; Wed, 21 Aug 2002 19:54:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 21 Aug 2002 18:22:25 -0600 (MDT) Message-Id: <20020821.182225.58446828.imp@bsdimp.com> To: archie@dellroad.org Cc: freebsd-arch@FreeBSD.ORG Subject: Re: NULL From: "M. Warner Losh" In-Reply-To: <200208212358.g7LNw8l08243@arch20m.dellroad.org> References: <20020821.173653.57449387.imp@bsdimp.com> <200208212358.g7LNw8l08243@arch20m.dellroad.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <200208212358.g7LNw8l08243@arch20m.dellroad.org> Archie Cobbs writes: : M. Warner Losh writes: : > : The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT' : > : work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf. : > : : > : Does anyone have an objection to this patch? : > : > Yes. I'm not sure that (void *)0 is the right thing to do. It can : > cause other problems and mask a different set of bugs, especially when : > you call functions that have no prototype in scope. : : Can you elaborate? : : Seems like the same is true of "0".. e.g., suppose that pointers : are larger than integers, and you call a variadic function with : "NULL" as one of the extra parameters: : : printf("foo=%p num=%d\n", NULL, 123); : : This would get screwed with NULL=0 but work right with NULL=(void *)0. Consider the following two files: foo.c: int foo(int a, int b) { ... } fee.c: int foo(void * a, int b) { ... } bar.c extern int foo(); /* old-style decl (not a prototype) */ ... foo(NULL, 10); /* Used to work, but now undefined */ ... Right now, bar.c + foo.c works, and bar.c + fee.c is undefined. With the change, we switch the two. On x86, this doesn't matter. Both work. But on the alpha, we've traded one set of working to the other working. printf("foo = %d", NULL); also changes in subtle ways. So I'm not sure this is the right thing to do. These abstract changes seem fairly simple, but in the context of complex programs, it could be much harder to track down. Also, we're getting kinda late in the current release cycle to be making changes this fundamental.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 19:45:18 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BCB137B400 for ; Wed, 21 Aug 2002 19:45:17 -0700 (PDT) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5C0C43E6E for ; Wed, 21 Aug 2002 19:45:16 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: from khavrinen.lcs.mit.edu (localhost [IPv6:::1]) by khavrinen.lcs.mit.edu (8.12.3/8.12.5) with ESMTP id g7M2jEVo004462 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 21 Aug 2002 22:45:14 -0400 (EDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.12.3/8.12.5/Submit) id g7M2jD8A004461; Wed, 21 Aug 2002 22:45:13 -0400 (EDT) (envelope-from wollman) Date: Wed, 21 Aug 2002 22:45:13 -0400 (EDT) From: Garrett Wollman Message-Id: <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu> To: archie@dellroad.org Subject: Re: NULL In-Reply-To: <200208212358.g7LNw8l08243@arch20m.dellroad.org> References: <20020821.173653.57449387.imp@bsdimp.com> 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 <200208212358.g7LNw8l08243@arch20m.dellroad.org> you write: >Seems like the same is true of "0".. e.g., suppose that pointers >are larger than integers, and you call a variadic function with >"NULL" as one of the extra parameters: > > printf("foo=%p num=%d\n", NULL, 123); > >This would get screwed with NULL=0 but work right with NULL=(void *)0. That's a feature. (Unfortunately, this feature is not implemented on ILP32 architectures. Is 0LL allowed as a null pointer constant? That would break everyone equally in this case.) The ultimate answer is that both definitions are useful for finding (or papering over) different bugs. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 19:58: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA6637B401 for ; Wed, 21 Aug 2002 19:58:01 -0700 (PDT) Received: from espresso.q9media.com (espresso.q9media.com [65.39.129.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B11443E6E for ; Wed, 21 Aug 2002 19:58:01 -0700 (PDT) (envelope-from mike@espresso.q9media.com) Received: by espresso.q9media.com (Postfix, from userid 1002) id 4B1699E59; Wed, 21 Aug 2002 22:52:25 -0400 (EDT) Date: Wed, 21 Aug 2002 22:52:25 -0400 From: Mike Barcroft To: Garrett Wollman Cc: archie@dellroad.org, arch@FreeBSD.org Subject: Re: NULL Message-ID: <20020821225225.B62302@espresso.q9media.com> References: <20020821.173653.57449387.imp@bsdimp.com> <200208212358.g7LNw8l08243@arch20m.dellroad.org> <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu>; from wollman@lcs.mit.edu on Wed, Aug 21, 2002 at 10:45:13PM -0400 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garrett Wollman writes: > In article <200208212358.g7LNw8l08243@arch20m.dellroad.org> you write: > >Seems like the same is true of "0".. e.g., suppose that pointers > >are larger than integers, and you call a variadic function with > >"NULL" as one of the extra parameters: > > > > printf("foo=%p num=%d\n", NULL, 123); > > > >This would get screwed with NULL=0 but work right with NULL=(void *)0. > > That's a feature. (Unfortunately, this feature is not implemented on > ILP32 architectures. Is 0LL allowed as a null pointer constant? That > would break everyone equally in this case.) > > The ultimate answer is that both definitions are useful for finding > (or papering over) different bugs. An application could always cheat and define it's own version of NULL before including any headers. This would mainly be useful for finding bugs, but of course is completely unsupported and probably wouldn't work on other platforms unless they also conditionally define NULL. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 21 21:45: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A257037B400 for ; Wed, 21 Aug 2002 21:45:04 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27E2B43E4A for ; Wed, 21 Aug 2002 21:45:04 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA97564; Wed, 21 Aug 2002 21:30:50 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7M4U3F09115; Wed, 21 Aug 2002 21:30:03 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208220430.g7M4U3F09115@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020821.182225.58446828.imp@bsdimp.com> "from M. Warner Losh at Aug 21, 2002 06:22:25 pm" To: "M. Warner Losh" Date: Wed, 21 Aug 2002 21:30:03 -0700 (PDT) Cc: freebsd-arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 M. Warner Losh writes: > So I'm not sure this is the right thing to do. These abstract changes > seem fairly simple, but in the context of complex programs, it could > be much harder to track down. Also, we're getting kinda late in the > current release cycle to be making changes this fundamental.... Sounds reasonable. I'll stop after fixing some newly discovered misuses of 'NULL' (there are lots) and we'll leave the actual changeover, if any, for further study. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 22 4:57:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F52237B400 for ; Thu, 22 Aug 2002 04:57:11 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFF7D43E6E for ; Thu, 22 Aug 2002 04:56:12 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7MBu5Ib066874; Thu, 22 Aug 2002 04:56:05 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7MBu3tb066873; Thu, 22 Aug 2002 04:56:03 -0700 (PDT) (envelope-from rizzo) Date: Thu, 22 Aug 2002 04:56:03 -0700 From: Luigi Rizzo To: "M. Warner Losh" Cc: nbm@mithrandr.moria.org, arch@FreeBSD.ORG Subject: Re: ugliness in rc.* scripts Message-ID: <20020822045603.A66453@iguana.icir.org> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821061822.A56560@iguana.icir.org> <20020821.095726.109035410.imp@bsdimp.com> <20020821091942.B59085@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020821091942.B59085@iguana.icir.org>; from rizzo@icir.org on Wed, Aug 21, 2002 at 09:19:42AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Aug 21, 2002 at 09:19:42AM -0700, Luigi Rizzo wrote: > On Wed, Aug 21, 2002 at 09:57:26AM -0600, M. Warner Losh wrote: > > In message: <20020821061822.A56560@iguana.icir.org> > > Luigi Rizzo writes: > ... > > : i think it is only one process -- echo is a builtin, tolower is a shell > > : function. In any case, we never cared about performance in the rc scripts, > > : not spawning processes (e.g. calling scripts with . instead of sh) has > > : only to do with letting variable assignements be visible in the caller. > > > > Actually, we have cared about the performance of shell scripts in the > > past. NetBSD got a nasty surprise when they went to their new rc ok, I made a few tests with /bin/sh. Funny results. Here, echo is a builtin command, /bin/echo an external one, and "f() { echo $* ; }" and f2() { /bin/echo $*; } are shell functions. echo "foo" # does not fork a=`echo "foo"` # does not fork /bin/echo "foo" # forks once. a=`/bin/echo "foo"` # forks once f "foo" # does not fork a=`f "foo"` # forks once. XXX f2 "foo" # forks once. a=`f2 "foo"` # forks twice. XXX I guess the most surprising (to me) behaviour is the handling of shell functions in backquotes -- but i suppose this is because builtins do not have side effects on the environment whereas shell functions can. In any case -- to come back to the original problem of folding strings into lowercase -- making "tr" a builtin is trivial, see the attached patches (congratulations to the designer of the builtin mechanism in /bin/sh). It would be even more useful if "tr" could handle arguments from the command line (or we hit again the problem of forking a process to provide the data to translate on stdin) cheers luigi Index: bin/sh/Makefile =================================================================== RCS file: /home/ncvs/src/bin/sh/Makefile,v retrieving revision 1.30.2.1 diff -u -r1.30.2.1 Makefile --- bin/sh/Makefile 15 Dec 2001 10:05:18 -0000 1.30.2.1 +++ bin/sh/Makefile 22 Aug 2002 11:11:01 -0000 @@ -5,7 +5,7 @@ SHSRCS= alias.c arith.y arith_lex.l cd.c echo.c error.c eval.c exec.c expand.c \ histedit.c input.c jobs.c mail.c main.c memalloc.c miscbltin.c \ mystring.c options.c output.c parser.c printf.c redir.c show.c \ - test.c trap.c var.c + str.c test.c tr.c trap.c var.c GENSRCS= builtins.c init.c nodes.c syntax.c GENHDRS= builtins.h nodes.h syntax.h token.h y.tab.h SRCS= ${SHSRCS} ${GENSRCS} ${GENHDRS} y.tab.h @@ -24,7 +24,8 @@ .PATH: ${.CURDIR}/bltin \ ${.CURDIR}/../../usr.bin/printf \ - ${.CURDIR}/../../bin/test + ${.CURDIR}/../../bin/test \ + ${.CURDIR}/../../usr.bin/tr CLEANFILES+= mkinit mkinit.o mknodes mknodes.o \ mksyntax mksyntax.o Index: bin/sh/builtins.def =================================================================== RCS file: /home/ncvs/src/bin/sh/builtins.def,v retrieving revision 1.7.2.1 diff -u -r1.7.2.1 builtins.def --- bin/sh/builtins.def 15 Dec 2001 10:05:18 -0000 1.7.2.1 +++ bin/sh/builtins.def 21 Aug 2002 19:50:15 -0000 @@ -91,3 +91,4 @@ aliascmd alias ulimitcmd ulimit testcmd test [ +trcmd tr Index: usr.bin/tr/tr.c =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/tr.c,v retrieving revision 1.8 diff -u -r1.8 tr.c --- usr.bin/tr/tr.c 28 Aug 1999 01:06:52 -0000 1.8 +++ usr.bin/tr/tr.c 21 Aug 2002 19:59:21 -0000 @@ -97,6 +97,11 @@ static void setup __P((int *, char *, STR *, int)); static void usage __P((void)); +#ifdef SHELL +#define main trcmd +#define exit return +#include "bltin/bltin.h" +#endif int main(argc, argv) int argc; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 22 5:25:42 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCDD437B408 for ; Thu, 22 Aug 2002 05:25:27 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01B8343E6A for ; Thu, 22 Aug 2002 05:25:26 -0700 (PDT) (envelope-from bde@zeta.org.au) 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 MAA18596; Thu, 22 Aug 2002 12:25:01 GMT Date: Thu, 22 Aug 2002 22:31:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Garrett Wollman Cc: archie@dellroad.org, Subject: Re: NULL In-Reply-To: <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu> Message-ID: <20020822221905.H3508-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 Wed, 21 Aug 2002, Garrett Wollman wrote: > In article <200208212358.g7LNw8l08243@arch20m.dellroad.org> you write: > >Seems like the same is true of "0".. e.g., suppose that pointers > >are larger than integers, and you call a variadic function with > >"NULL" as one of the extra parameters: > > > > printf("foo=%p num=%d\n", NULL, 123); > > > >This would get screwed with NULL=0 but work right with NULL=(void *)0. > > That's a feature. (Unfortunately, this feature is not implemented on > ILP32 architectures. Is 0LL allowed as a null pointer constant? That > would break everyone equally in this case.) I think it is not implemented on many I32LP64 arches either, since most arches with 64-bit pointers have pass all args as 64-bit. Everything between ((signed char)0) and ((uintmax_t)0) is allowed. uintmax_t would have to be > 64 bits to break the 64-bit arches equally. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 23 10:56:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A247237B405 for ; Fri, 23 Aug 2002 10:56:27 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id AACCC43E4A for ; Fri, 23 Aug 2002 10:56:26 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g7NHuPf23644 for ; Fri, 23 Aug 2002 10:56:25 -0700 (PDT) (envelope-from jdp@vashon.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.12.4/8.12.4/Submit) id g7NHuPaX087707; Fri, 23 Aug 2002 10:56:25 -0700 (PDT) (envelope-from jdp) Date: Fri, 23 Aug 2002 10:56:25 -0700 (PDT) Message-Id: <200208231756.g7NHuPaX087707@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Subject: Re: ugliness in rc.* scripts In-Reply-To: <20020821180344.GB33546@starjuice.net> References: <20020820232538.A53816@iguana.icir.org> <20020821074819.GA58163@mithrandr.moria.org> <20020821.095252.61131232.imp@bsdimp.com> <20020821180344.GB33546@starjuice.net> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [From address modified because I don't want every message in this thread to end up in my personal mailbox. I'll read them in the list, thank you very much.] In article <20020821180344.GB33546@starjuice.net>, Sheldon Hearn wrote: > I don't think the ugliness involved in the rc scripts justifies any of > the proposed hack-arounds yet. [...] > But I digress. I don't think the ugliness is ugly enough. I agree, but I'd take it one step further. Why do we have to support case-insensitive matching of words like YES and NO at all? Just proclaim that from now on, keywords in /etc/rc.conf have to be upper-case. Practically everything else in Unix is case-sensitive -- why not the rc.conf knobs? Note also that most of rc.conf is *already* case-sensitive. If you put something like "MoUsEd_ENAble=YES" in your rc.conf file, it will do exactly nothing. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 23 20:32:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E083337B400 for ; Fri, 23 Aug 2002 20:32:34 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C528343E72 for ; Fri, 23 Aug 2002 20:32:30 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g7O3WP2F001473; Fri, 23 Aug 2002 21:32:26 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 23 Aug 2002 21:31:13 -0600 (MDT) Message-Id: <20020823.213113.89131668.imp@bsdimp.com> To: wollman@lcs.mit.edu Cc: archie@dellroad.org, arch@FreeBSD.ORG Subject: Re: NULL From: "M. Warner Losh" In-Reply-To: <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu> References: <20020821.173653.57449387.imp@bsdimp.com> <200208212358.g7LNw8l08243@arch20m.dellroad.org> <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu> X-Mailer: Mew version 2.1 on Emacs 21.2 / 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: <200208220245.g7M2jD8A004461@khavrinen.lcs.mit.edu> Garrett Wollman writes: : Is 0LL allowed as a null pointer constant? Yes. Any constant integer express that evaluates to 0 is a valid 'null pointer'. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 24 11:30: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A0C837B400 for ; Sat, 24 Aug 2002 11:30:03 -0700 (PDT) Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11FDD43E6A for ; Sat, 24 Aug 2002 11:30:03 -0700 (PDT) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA19840; Sat, 24 Aug 2002 11:29:17 -0700 (PDT) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.6/8.11.6) id g7OISOR28346; Sat, 24 Aug 2002 11:28:24 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200208241828.g7OISOR28346@arch20m.dellroad.org> Subject: Re: NULL In-Reply-To: <20020823.213113.89131668.imp@bsdimp.com> "from M. Warner Losh at Aug 23, 2002 09:31:13 pm" To: "M. Warner Losh" Date: Sat, 24 Aug 2002 11:28:24 -0700 (PDT) Cc: wollman@lcs.mit.edu, arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 M. Warner Losh writes: > : Is 0LL allowed as a null pointer constant? > > Yes. Any constant integer express that evaluates to 0 is a valid > 'null pointer'. FYI- Current is now "((void *)0)-clean" and LINT compiles with -Werror. So things are ready if/when we want to try switching. These are the files that define NULL: include/dirent.h include/locale.h include/stddef.h include/stdio.h include/stdlib.h include/string.h include/time.h include/unistd.h include/wchar.h include/rpc/types.h lib/libstand/stand.h sys/boot/libstand/stand.h sys/sys/param.h -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message