From owner-freebsd-arch Mon Jul 30 8:18: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mydomain.com (1Cust57.tnt2.cph3.da.uu.net [213.116.21.57]) by hub.freebsd.org (Postfix) with ESMTP id 8CCEC37B411; Mon, 30 Jul 2001 08:17:59 -0700 (PDT) (envelope-from xxxsensation@funkytimes.com) Date: Mon, 30 Jul 2001 17:17:55 +0100 From: XXXSENSATION To: XXXSENSATION@FreeBSD.ORG Subject: THE GREATEST NO.1 SHOWS ON THE NET ! Message-Id: <20010730151759.8CCEC37B411@hub.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 Dear Ladies & Gentlemen, Welcome to the GREATEST SEX SHOW on the ENTIRE NET ! We now offer you to ENTER to world´s No.1 voted SEX-SERVER on the WEB ! By far the largest and most incredible content of LIVE SEX is now served to users WORLDWIDE! EVERYTHING is offered 100% ANONOMOUSLY & you don´t need to sign-up or have a creditcard ... The way it should be ! PLUGIN RIGHT HERE AT: http://siam.to/worldclass ... If this Site does not open properly ... please try http://cyberu.to/worldclass Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/classbabes ... If this Site does not open properly ... please try http://cyberu.to/hotbabes and get access to something you with guarantee NEVER have seen before ! Yours truly, XXXSENSATION Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 9:20:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [64.0.106.45]) by hub.freebsd.org (Postfix) with ESMTP id 47BA137B403; Mon, 30 Jul 2001 09:20:37 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id MAA20355; Mon, 30 Jul 2001 12:19:41 -0400 (EDT) Date: Mon, 30 Jul 2001 12:19:41 -0400 (EDT) From: "Matthew N. Dodd" To: Cy Schubert - ITSD Open Systems Group Cc: "Peter C. Lai" , Jeroen Massar , "'Garance A Drosihn'" , "'Matt Dillon'" , arch@FreeBSD.ORG, "'Garrett Wollman'" , brian@FreeBSD.ORG Subject: Re: Changes to utmp, wtmp & lastlog entries In-Reply-To: <200107261850.f6QIoaa04255@cwsys.cwsent.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 Thu, 26 Jul 2001, Cy Schubert - ITSD Open Systems Group wrote: > write to utmp/wtmp & utmpx/wtmpx need to be aware of any changes, hence > applications that once were portable are now not. It is my hope that > we avoid the Solaris 8 type of mess when overhauling utmp/wtmp. Except that the Krb5/Solaris 8 interaction is actually a Solaris 8 libc bug. It has nothing to do with Krb5 (except that Krb5 makes use of a public interface that just happens to have issues.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 12:10:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 7129A37B403 for ; Mon, 30 Jul 2001 12:10:06 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA30522 for ; Mon, 30 Jul 2001 14:19:14 -0700 (PDT) Date: Mon, 30 Jul 2001 14:19:13 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org Subject: Threads topics. 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 Well, I'm quite a way into doing the KSE kernel. I have changed most of the interfaces to pass threads around instead of procs and have the compile going almost all teh way through everything upto teh end of 'kern' working with anly a few minor errors. however there sre some things that need to be discussed... these include: behaviour of a multithreaded program when stopped by the debugger, and what happens when the user type ^Z on a multithreaded program. What iti comes down to is if a particular process is running on several processors, and the user hits ^Z, how do I stop the threads that are running on the other processors? My guess is that I send some sort of Inter-processor Interrupt, after having marked the process as stopped, and that on teh return from the interrupt, the kernel on teh other processor should notice this fact and deschedule its thread and run something else. I have also some really difficult times in trying to work out how to tranlate such things as teh calls to put a process on teh run queue.. here's what I have at the moment for a first cut: (For this example assume a 2 processor system) initial state: nothing on run queues, several threads on sleep queues. Two KSEs have been created in one KSE group. Thread 1 becomes runnable.. we find the last KSE it ran on, and as it is not runnable, we make THAT runnable, and put it on the run queue. We hang the runnable thread off the KSE. (note at this stage there is only one run queue). A processor picks the highest priority KSE and takes it off the run queue and starts processing the first thread hung off it. Thread 2 comes ready. It also was last run on KSE-1 so it is hung off the already running KSE-1. However since the number of runnable threads is greater than the number of runnable KSEs, but less than the number of KSEs created (2) we get another KSE at random (KSE-2) and place it on the run queue. KSE-2 starts and finding no work, steals a thread from KSE-1. [note: is it better to preserve the processor affinity or to run earlier?] Thread 1 blocks, and is saved back in the sleep queue.. A new thread is created and returns to the UTS. (thread3) Threads 4, 5 & 6 become runnable. They are placed on the queue for KSE-1 as that is where they last ran. Thread 2 blocks. KSE-2 has no more work, but, as it still has quanta, it steals thread 4 from KSE-1's queue. Thread 3 blocks. As there are runnable threads, no new thread is created (yet), but thread 5 is run instead up to the user boundary. It doesn't return top user space, but it's return state is passed to teh USer-space structure reserved for it, and it is freed, and thread 6 is loaded onto the KSE. It also runs to the userland boundary, and saved to userspace. SInce there are no further runnable threads in the kernel, control is passed up to the UTS. Quantum becomes exhauseted.. KSE-1 and KSE-2 place the presently running threads back on their queues (possibly at the tail if not in a critical section) and then are themselves placed back on the run queue. (at the tail) I have not coded the userland boundary crossing stuff yet, so at this stage there can only be as many threads as there are KSEs and the mapping is permanent. syscalls return directly instead of producing an upcall to the UTS. Basically the mechanism should be the same but it will never have the oportunity to do some of the cases. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 13:19:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3930337B405 for ; Mon, 30 Jul 2001 13:19:35 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA20220; Mon, 30 Jul 2001 16:18:49 -0400 (EDT) Date: Mon, 30 Jul 2001 16:18:45 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 30 Jul 2001, Julian Elischer wrote: > Well, I'm quite a way into doing the KSE kernel. > > I have changed most of the interfaces to pass > threads around instead of procs and have the compile > going almost all teh way through everything upto teh end of 'kern' > working with anly a few minor errors. > > however there sre some things that need to be discussed... > these include: > > behaviour of a multithreaded program when stopped by the debugger, > and what happens when the user type ^Z on a multithreaded program. > > What iti comes down to is if a particular process is running on several > processors, and the user hits ^Z, how do I stop the threads that > are running on the other > processors? > > My guess is that I send some sort of Inter-processor Interrupt, after > having marked the process as stopped, and that on teh return > from the interrupt, the kernel on teh other processor should > notice this fact and deschedule its thread and run something else. > > I have also some really difficult times in trying to work out how to > tranlate such things as teh calls to put a process on teh run queue.. > > here's what I have at the moment for a first cut: > (For this example assume a 2 processor system) > > initial state: nothing on run queues, several threads on sleep queues. > Two KSEs have been created in one KSE group. > > Thread 1 becomes runnable.. we find the last KSE it ran on, > and as it is not runnable, we make THAT runnable, and put it on the run > queue. We hang the runnable thread off the KSE. (note at this stage there > is only one run queue). > > A processor picks the highest priority KSE and takes it off the run queue > and starts processing the first thread hung off it. > > Thread 2 comes ready. It also was last run on KSE-1 so it is hung off > the already running KSE-1. However since the number of runnable threads > is greater than the number of runnable KSEs, but less than the > number of KSEs created (2) we get another KSE at random (KSE-2) > and place it on the run queue. From the UTS perspective, it may be easier to deal with unblocking of threads if notifications were only on the KSE in which the thread was running. For concurrency levels > 1 (more than 1 KSE in the KSE Group), the UTS may have 2 sets of queues -- one for each concurrency level. If KSEs may get notifications for threads running in other KSEs, it means that there will have to be some inter-KSE locking of blocked and running thread queues. And each KSE has it's own mailbox, so it might force KSEs to fiddle with mailboxes they don't own. I'm not saying we can't do it, just that we may want to postpone that for later. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 13:50:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 2E11E37B403 for ; Mon, 30 Jul 2001 13:50:05 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA30831; Mon, 30 Jul 2001 15:45:58 -0700 (PDT) Date: Mon, 30 Jul 2001 15:45:57 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 30 Jul 2001, Daniel Eischen wrote: > On Mon, 30 Jul 2001, Julian Elischer wrote: > > > > Thread 2 comes ready. It also was last run on KSE-1 so it is hung off > > the already running KSE-1. However since the number of runnable threads > > is greater than the number of runnable KSEs, but less than the > > number of KSEs created (2) we get another KSE at random (KSE-2) > > and place it on the run queue. > > From the UTS perspective, it may be easier to deal with unblocking > of threads if notifications were only on the KSE in which the thread > was running. For concurrency levels > 1 (more than 1 KSE in the > KSE Group), the UTS may have 2 sets of queues -- one for each > concurrency level. > > If KSEs may get notifications for threads running in other KSEs, > it means that there will have to be some inter-KSE locking of > blocked and running thread queues. And each KSE has it's own > mailbox, so it might force KSEs to fiddle with mailboxes they > don't own. no it would never have to fiddle with a mailbox that it didn't own, but it might find a thread on its "completed" list that it should put on the other run queue. If I don't do that then there will be times when I could run a thread but instead will sit idle. It is of course easy to do.. (comment out some code :-) In the first version it will always come back on the same KSE because there is a 1:1 relationship between threads and KSEs. I'm rewriting this stuff at the moment. I 'll make sure it can be done either way (allow or not allow a thread to change KSEs while in the kernel.) So, did the rest of what I wrote make sense? the important bit is writing the code to put things on the run queues in the new scheme that degenerates to exactly the current operation in a 1:1 situation. > > I'm not saying we can't do it, just that we may want to postpone > that for later. > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 14:24:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B1FCE37B401 for ; Mon, 30 Jul 2001 14:21:27 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f6ULLIF85487; Mon, 30 Jul 2001 15:21:23 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.4) with ESMTP id f6ULLIw41535; Mon, 30 Jul 2001 15:21:18 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200107302121.f6ULLIw41535@harmony.village.org> To: Julian Elischer Subject: Re: Threads topics. Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Mon, 30 Jul 2001 14:19:13 PDT." References: Date: Mon, 30 Jul 2001 15:21:18 -0600 From: Warner Losh Sender: owner-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 Julian Elischer writes: : Well, I'm quite a way into doing the KSE kernel. Julian, this sounds like cool stuff. How is it related to the perforce branches that jhb has setup? p4 branches Branch jhb_preemption 2001/07/19 'Fully preemptive kernel. ' Branch smpng 2001/07/17 'SMPng workspace ' He was talking about them in irc this morning. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 15:30:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id F3A8F37B401 for ; Mon, 30 Jul 2001 15:30:19 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA31254; Mon, 30 Jul 2001 17:34:13 -0700 (PDT) Date: Mon, 30 Jul 2001 17:34:12 -0700 (PDT) From: Julian Elischer To: Warner Losh Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: <200107302121.f6ULLIw41535@harmony.village.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 Mon, 30 Jul 2001, Warner Losh wrote: > In message Julian Elischer writes: > : Well, I'm quite a way into doing the KSE kernel. > > Julian, > this sounds like cool stuff. How is it related to the > perforce branches that jhb has setup? > My patches are relative to -current I can't seem to get to IRC from here as identd is blocked at the firewall. so I don't know about his perforce stuff. > p4 branches > Branch jhb_preemption 2001/07/19 'Fully preemptive kernel. ' > Branch smpng 2001/07/17 'SMPng workspace ' > > He was talking about them in irc this morning. > > Warner > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 15:39:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id A72E537B401 for ; Mon, 30 Jul 2001 15:39:33 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA11541; Mon, 30 Jul 2001 18:38:47 -0400 (EDT) Date: Mon, 30 Jul 2001 18:38:47 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 30 Jul 2001, Julian Elischer wrote: > On Mon, 30 Jul 2001, Daniel Eischen wrote: > > If KSEs may get notifications for threads running in other KSEs, > > it means that there will have to be some inter-KSE locking of > > blocked and running thread queues. And each KSE has it's own > > mailbox, so it might force KSEs to fiddle with mailboxes they > > don't own. > > no it would never have to fiddle with a mailbox that it didn't own, > but it might find a thread on its "completed" list that it should > put on the other run queue. If I don't do that then there will be times > when I could run a thread but instead will sit idle. > It is of course easy to do.. (comment out some code :-) Blocked threads will be put in a per-KSE queue of their own. Having a different KSE handle the unblocking of a thread would probably require that the thread be removed from the other KSEs blocked queue as well as insertion into its run queue. We could probably use the same per-KSE lock to protect both run and blocked (and any other) queues though. > In the first version it will always come back on the same KSE because > there is a 1:1 relationship between threads and KSEs. > > I'm rewriting this stuff at the moment. I 'll make sure it can be done > either way (allow or not allow a thread to change KSEs while in the > kernel.) > > So, did the rest of what I wrote make sense? For the most part, yes, though you did write: > I have not coded the userland boundary crossing stuff yet, > so at this stage there can only be as many threads as there are KSEs > and the mapping is permanent. syscalls return directly instead ^Blocking ? > of producing an upcall to the UTS. I assume syscalls that don't block will always return directly to the UTS (unless other UTS notifications are needed). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 15:47:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id D76E137B403 for ; Mon, 30 Jul 2001 15:47:51 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.217]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA13790; Mon, 30 Jul 2001 15:47:42 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200107302121.f6ULLIw41535@harmony.village.org> Date: Mon, 30 Jul 2001 15:47:29 -0700 (PDT) From: John Baldwin To: Warner Losh Subject: Re: Threads topics. Cc: arch@FreeBSD.org, Julian Elischer Sender: owner-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 30-Jul-01 Warner Losh wrote: > In message > Julian Elischer writes: >: Well, I'm quite a way into doing the KSE kernel. > > Julian, > this sounds like cool stuff. How is it related to the > perforce branches that jhb has setup? > > p4 branches > Branch jhb_preemption 2001/07/19 'Fully preemptive kernel. ' > Branch smpng 2001/07/17 'SMPng workspace ' > > He was talking about them in irc this morning. Peter is the one with all the evil perforce branches. Using a perforce for things like KSE might be very beneficial indeed, but I'm just using the p4 depot on freefall, I didn't set it up and don't admin it. :) > Warner -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 16:49:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id B6B1837B403 for ; Mon, 30 Jul 2001 16:49:54 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA31582; Mon, 30 Jul 2001 18:47:44 -0700 (PDT) Date: Mon, 30 Jul 2001 18:47:43 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 30 Jul 2001, Daniel Eischen wrote: > On Mon, 30 Jul 2001, Julian Elischer wrote: > > On Mon, 30 Jul 2001, Daniel Eischen wrote: > > > If KSEs may get notifications for threads running in other KSEs, > > > it means that there will have to be some inter-KSE locking of > > > blocked and running thread queues. And each KSE has it's own > > > mailbox, so it might force KSEs to fiddle with mailboxes they > > > don't own. > > > > no it would never have to fiddle with a mailbox that it didn't own, > > but it might find a thread on its "completed" list that it should > > put on the other run queue. If I don't do that then there will be times > > when I could run a thread but instead will sit idle. > > It is of course easy to do.. (comment out some code :-) > > Blocked threads will be put in a per-KSE queue of their own. > Having a different KSE handle the unblocking of a thread would > probably require that the thread be removed from the other > KSEs blocked queue as well as insertion into its run queue. > We could probably use the same per-KSE lock to protect both > run and blocked (and any other) queues though. Why not keep teh blocked threads on a common queue? (theoretically only a RUNNING thread is associated with a KSE in the kernel.. a blocked KSE has a point er to teh KSE it WAS on, but I'm treating that as just a hint.. what advantage do you have in keeping a per-KSE list of blocked threads? I guess I could report them only on the mailbox they came in on, but then that would lead to a thread being reported as 'back and runnable" and yet teh UTS wouldn;t know about it until THAT PARTICULAR kse/UTS ran again. It is concievable that it may be preferable to run this thread before another that is runnable on onother KSE, except that the UTS instance for that KSE doesn't know that it is available.. > > > In the first version it will always come back on the same KSE because > > there is a 1:1 relationship between threads and KSEs. > > > > I'm rewriting this stuff at the moment. I 'll make sure it can be done > > either way (allow or not allow a thread to change KSEs while in the > > kernel.) > > > > So, did the rest of what I wrote make sense? > > For the most part, yes, though you did write: > > > I have not coded the userland boundary crossing stuff yet, > > so at this stage there can only be as many threads as there are KSEs > > and the mapping is permanent. syscalls return directly instead > ^Blocking ? > > of producing an upcall to the UTS. > > I assume syscalls that don't block will always return directly > to the UTS (unless other UTS notifications are needed). A syscall that does not block may still result in a UTS upcall upon return if it wants to report that it also completed 4 other previously blocked syscalls. (It is possible that you may not want the system to make use of the chance to complete those syscalls, but rather to wait until a context switch or something. To me it makes sense to allow the kernel to say, "Hey while you're down here, I have 4 unblocked syscalls I think you should complete so that we can free up their resources" In this situation, even a call to getpid() might result in an upcall so that the UTS can decide which of the 5 threads is more urgent to complete. If you do NOT want this to happpen that would be possible but probably not the default behaviour that I'll implement. I think I'll make several of these decisions 'tunable per process' so you can decide how you want it to behave. > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Jul 30 21:17: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id B1C2C37B401 for ; Mon, 30 Jul 2001 21:16:56 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA27889; Tue, 31 Jul 2001 00:16:11 -0400 (EDT) Date: Tue, 31 Jul 2001 00:16:11 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: Threads topics. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 30 Jul 2001, Julian Elischer wrote: > On Mon, 30 Jul 2001, Daniel Eischen wrote: > > Blocked threads will be put in a per-KSE queue of their own. > > Having a different KSE handle the unblocking of a thread would > > probably require that the thread be removed from the other > > KSEs blocked queue as well as insertion into its run queue. > > We could probably use the same per-KSE lock to protect both > > run and blocked (and any other) queues though. > > Why not keep teh blocked threads on a common queue? > (theoretically only a RUNNING thread is associated with a KSE > in the kernel.. a blocked KSE has a point er to teh KSE it WAS on, > but I'm treating that as just a hint.. They don't have to be placed in a per-KSE queue, but in a per-KSE Group queue if that that turns out to be better due to the way unblocked notifications are made. I was originally trying to minimize the amount of contention between KSEs. > what advantage do you have in keeping a per-KSE list of blocked threads? > I guess I could report them only on the mailbox they came in on, but then > that would lead to a thread being reported as 'back and runnable" > and yet teh UTS wouldn;t know about it until THAT PARTICULAR kse/UTS > ran again. It is concievable that it may be preferable to run this thread > before another that is runnable on onother KSE, except that the UTS > instance for that KSE doesn't know that it is available.. If we assume a per-KSE run queue for the moment, the only way one KSE will run a thread from another KSE is if that thread happens to be in a critical region. Threads in critical regions may hold up progress if not resumed until they leave the critical region. The only way a thread can be stopped in a critical region is if it was preempted or had a page fault. System calls will not be made while in critical regions, so threads should not block in the kernel within these regions. So if you want to differentiate between preempted and page faulted threads, and those threads blocked in the kernel (blocking syscalls), there is no reason that the notification of unblocked threads in the kernel _needs_ to made on the first runnable KSE. If a KSE has no more threads to run, it will make a call to the kernel to say "hey, I'm done until one of my blocked threads becomes unblocked". So the kernel needn't worry to much about the KSE running out of work; it will know when that happens and can send new upcall notifications at that time if it wants. Plus, when a KSE is resumed after being preempted, it always starts with an upcall -- another chance to send notifications. This is my UTS point of view anyways. I think we can handle notifications for threads on other KSEs, so do it whatever way you think is best. We can always change it later if we have to. > > For the most part, yes, though you did write: > > > > > I have not coded the userland boundary crossing stuff yet, > > > so at this stage there can only be as many threads as there are KSEs > > > and the mapping is permanent. syscalls return directly instead > > ^Blocking ? > > > of producing an upcall to the UTS. > > > > I assume syscalls that don't block will always return directly > > to the UTS (unless other UTS notifications are needed). > > A syscall that does not block may still result in a UTS upcall upon return > if it wants to report that it also completed 4 other previously blocked > syscalls. (It is possible that you may not want the system to make use of > the chance to complete those syscalls, but rather to wait until > a context switch or something. To me it makes sense > to allow the kernel to say, > "Hey while you're down here, I have 4 unblocked syscalls I think you > should complete so that we can free up their resources" Yeah, that's what I meant when I wrote "(unless other UTS notifications are needed)" ;-) It's OK to perform an upcall to notify the UTS of events; I just wanted to be sure that every syscall wasn't going to return to the UTS via an upcall even if there were no notifications to be made. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 4: 9:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by hub.freebsd.org (Postfix) with ESMTP id ED88537B401 for ; Tue, 31 Jul 2001 04:09:54 -0700 (PDT) (envelope-from tteguh@id.ibm.com) Received: from f02n15e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id VAA150602 for ; Tue, 31 Jul 2001 21:06:10 +1000 Received: from d23m0081.id.ibm.com (d23m0080.id.ibm.com [9.184.105.196]) by f02n15e.au.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6VB9Oh51226 for ; Tue, 31 Jul 2001 21:09:24 +1000 Importance: Normal Subject: intel base customer reference using freeBSD To: freebsd-arch@FreeBSD.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "Teguh Tjahjono" Date: Tue, 31 Jul 2001 18:06:45 +0700 X-MIMETrack: Serialize by Router on d23m0081/23/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 31/07/2001 06:06:46 PM 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 Hi there, one of my customer here in Indonesia want to know if there is a customer reference for freeBSD, especially customer that run the freeBSD on intel base server and I will be very very happy if you can give me the customer that used IBM PC Server (IBM Intel Base server) as their platform for the freeBSD. Cordially, Teguh Tjahjono eServer xSeries and Intellistation Specialist, eServer Group, IBM Indonesia Phone: 62-21-2512922, Direct: 62-21-5238173, IVPN: 956 - 8173 Fax: 62-21-2512933, Mobile: 62-811952229, E-mail: tteguh@id.ibm.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 8:51:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 4E16537B401 for ; Tue, 31 Jul 2001 08:51:41 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 596E781D05; Tue, 31 Jul 2001 10:51:41 -0500 (CDT) Date: Tue, 31 Jul 2001 10:51:41 -0500 From: Alfred Perlstein To: Teguh Tjahjono Cc: freebsd-arch@FreeBSD.org Subject: Re: intel base customer reference using freeBSD Message-ID: <20010731105141.X26571@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tteguh@id.ibm.com on Tue, Jul 31, 2001 at 06:06:45PM +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 * Teguh Tjahjono [010731 06:10] wrote: > Hi there, > > one of my customer here in Indonesia want to know if there is a customer > reference for freeBSD, especially customer that run the freeBSD on intel > base server and I will be very very happy if you can give me the customer > that used IBM PC Server (IBM Intel Base server) as their platform for the > freeBSD. http://www.freebsd.org/gallery/gallery.html I don't know of many FreeBSD based companies that are going out of business so that you can get second hand hardware however the gallery should list some vendors of FreeBSD tested hardware. best of luck, -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 9:29: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 413CF37B401 for ; Tue, 31 Jul 2001 09:29:04 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA34989 for ; Tue, 31 Jul 2001 11:20:47 -0700 (PDT) Date: Tue, 31 Jul 2001 11:20:46 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org Subject: treads patches 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 Not NEARLY finished, but all the patches to make GENERIC compile upto the end of nfs/ are at http://www.freebsd.org/~julian You'd have to be crazy though.. it's 850KB of diffs (It's mainly there as a backup) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 10:26:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id DA2EA37B401 for ; Tue, 31 Jul 2001 10:26:25 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A2FF881D05; Tue, 31 Jul 2001 12:26:15 -0500 (CDT) Date: Tue, 31 Jul 2001 12:26:15 -0500 From: Alfred Perlstein To: Julian Elischer Cc: arch@freebsd.org Subject: Re: treads patches Message-ID: <20010731122615.D26571@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Tue, Jul 31, 2001 at 11:20:46AM -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 * Julian Elischer [010731 11:29] wrote: > Not NEARLY finished, but all the patches to make GENERIC compile upto the > end of nfs/ are at http://www.freebsd.org/~julian > > You'd have to be crazy though.. it's 850KB of diffs > (It's mainly there as a backup) This is excellent, keep up the work! -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 13:28:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 8CE6237B403 for ; Tue, 31 Jul 2001 13:28:51 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA36002 for ; Tue, 31 Jul 2001 15:28:00 -0700 (PDT) Date: Tue, 31 Jul 2001 15:27:59 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org Subject: thread scheduling question 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 Does anyone have any views on what happens when the posix scheduling calls are applied against a multithreaded process? in particular against one with several KSEGRPs? are the multiple KSEs and KSEGRPs visible to the outside at all? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 13:48:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 1DA3537B405 for ; Tue, 31 Jul 2001 13:48:49 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA16841; Tue, 31 Jul 2001 16:48:02 -0400 (EDT) Date: Tue, 31 Jul 2001 16:48:02 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: thread scheduling question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 31 Jul 2001, Julian Elischer wrote: > Does anyone have any views on what happens when > the posix scheduling calls are applied against a multithreaded > process? What POSIX scheduling calls? sched_xxx? > in particular against one with several KSEGRPs? > are the multiple KSEs and KSEGRPs visible to the outside at all? In general, I think that the sched_xxx (say, sched_setscheduler) should apply to the process' main (original) KSE Group and not affect other KSE Groups created for scope system threads. We'll have another system call (perhaps later on) to allow changing of those KSE Groups (Solaris has priocntl(2) to allow changing scheduling parameters by PID, LWPID, PPID, PGID, etc). Here's what Solaris 8 has to say about sched_setscheduler (and it's mostly verbatim from what SUSv2 has to say): The effect of this function on individual threads is depen- dent on the scheduling contention scope of the threads: o For threads with system scheduling contention scope, these functions have no effect on their scheduling. o For threads with process scheduling contention scope, the threads' scheduling parameters will not be affected. However, the scheduling of these threads with respect to threads in other processes may be dependent on the scheduling parameters of their pro- cess, which are governed using these functions. If an implementation supports a two-level scheduling model in which library threads are multiplexed on top of several kernel scheduled entities, then the underlying kernel scheduled entities for the system contention scope threads will not be affected by these functions. The underlying kernel scheduled entities for the process contention scope threads will have their scheduling parame- ters changed to the value specified in param. Kernel scheduled entities for use by process contention scope threads that are created after this call completes inherit their scheduling policy and associated scheduling parameters from the process. This function is not atomic with respect to other threads in the process. Threads are allowed to continue to execute while this function call is in the process of changing the scheduling policy for the underlying kernel scheduled enti- ties used by the process contention scope threads. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 14: 8:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 11A9F37B409 for ; Tue, 31 Jul 2001 14:08:51 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA36157 for ; Tue, 31 Jul 2001 16:00:40 -0700 (PDT) Date: Tue, 31 Jul 2001 16:00:39 -0700 (PDT) From: Julian Elischer To: arch@freebsd.org Subject: threads comment 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 Y'know, if we'd called the thread a "process" and the thing that has a pid a "task" (or something) the actual functional changes would be a HECK of a lot clearer in the diffs because I have 50k of functional changes and 800+KB of - struct proc *pB + struct thread *td; (just a comment) Actually if we left processes as processes and then created 'super-processes', I think you could start now and still finish first. (so far I have replaced about 4000 instances of struct proc with struct thread (mostly by hand)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 14: 9:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 997FB37B409 for ; Tue, 31 Jul 2001 14:09:02 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA36167; Tue, 31 Jul 2001 16:09:17 -0700 (PDT) Date: Tue, 31 Jul 2001 16:09:16 -0700 (PDT) From: Julian Elischer To: Daniel Eischen Cc: arch@FreeBSD.ORG Subject: Re: thread scheduling question 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 hmmm, ok.. so, as a redux: KSE's in the original KSEG are affected (the original KSEG is affected. New KSEGs created after this, are affected (by default) exisiting other KSEGs are not affected.. Means we need to track which is the original KSEG :-) ALso I LIKE their terminology.. :-) On Tue, 31 Jul 2001, Daniel Eischen wrote: > On Tue, 31 Jul 2001, Julian Elischer wrote: > > Does anyone have any views on what happens when > > the posix scheduling calls are applied against a multithreaded > > process? > > What POSIX scheduling calls? sched_xxx? > > > in particular against one with several KSEGRPs? > > are the multiple KSEs and KSEGRPs visible to the outside at all? > > In general, I think that the sched_xxx (say, sched_setscheduler) > should apply to the process' main (original) KSE Group and not > affect other KSE Groups created for scope system threads. We'll > have another system call (perhaps later on) to allow changing of > those KSE Groups (Solaris has priocntl(2) to allow changing scheduling > parameters by PID, LWPID, PPID, PGID, etc). > > Here's what Solaris 8 has to say about sched_setscheduler (and it's > mostly verbatim from what SUSv2 has to say): > > The effect of this function on individual threads is depen- > dent on the scheduling contention scope of the threads: > > o For threads with system scheduling contention scope, > these functions have no effect on their scheduling. > > o For threads with process scheduling contention scope, > the threads' scheduling parameters will not be > affected. However, the scheduling of these threads > with respect to threads in other processes may be > dependent on the scheduling parameters of their pro- > cess, which are governed using these functions. > > If an implementation supports a two-level scheduling model > in which library threads are multiplexed on top of several > kernel scheduled entities, then the underlying kernel > scheduled entities for the system contention scope threads > will not be affected by these functions. > > The underlying kernel scheduled entities for the process > contention scope threads will have their scheduling parame- > ters changed to the value specified in param. Kernel > scheduled entities for use by process contention scope > threads that are created after this call completes inherit > their scheduling policy and associated scheduling parameters > from the process. > > This function is not atomic with respect to other threads in > the process. Threads are allowed to continue to execute > while this function call is in the process of changing the > scheduling policy for the underlying kernel scheduled enti- > ties used by the process contention scope threads. > > > -- > Dan Eischen > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 17:41:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C951137B403 for ; Tue, 31 Jul 2001 17:41:18 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id UAA18580; Tue, 31 Jul 2001 20:40:34 -0400 (EDT) Date: Tue, 31 Jul 2001 20:40:34 -0400 (EDT) From: Daniel Eischen To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: thread scheduling question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 31 Jul 2001, Julian Elischer wrote: > hmmm, ok.. so, as a redux: > > KSE's in the original KSEG are affected (the original KSEG is > affected. New KSEGs created after this, are affected (by default) > exisiting other KSEGs are not affected.. Hmm, after reading more carefully, I don't think that _subsequent_ KSEGs created for _system_ scope threads should inherit the same scheduling parameters. Read this part a little more carefully: > > The underlying kernel scheduled entities for the process > > contention scope threads will have their scheduling parame- > > ters changed to the value specified in param. Kernel > > scheduled entities for use by process contention scope ^^^^^^^^^^^^^^^^^^^^^^^^^ > > threads that are created after this call completes inherit > > their scheduling policy and associated scheduling parameters > > from the process. It doesn't say that KSEs (yes, nice terminology ;-)) created for _system_ scope threads inherit the scheduling policy/parameters. Since we (currently) don't create more than one KSEG for process scope threads, this degenerates into just affecting the original KSEG. I suppose that if the threads library ever wanted to create more than 1 KSEG for process scope threads, we could just pass a flags word with KSEG_SCHED_INHERIT set on kseg_create(). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 20:26:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from boss (unknown [210.183.236.168]) by hub.freebsd.org (Postfix) with SMTP id CF35D37B403 for ; Tue, 31 Jul 2001 20:25:07 -0700 (PDT) (envelope-from boss@palza.net) From: =?ks_c_5601-1987?B?yLK068jG?= To: freebsd-arch@FreeBSD.org Subject: =?ks_c_5601-1987?B?W77LuLJdIGZyZWVic2QtYXJjaLTUwMcgsMe9wsC7ILHiv/ggteW4s7TPtNkuLg==?= Date: Wed, 01 Aug 2001 12:22:03 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0127_01C0F01A.93A22C00" X-Priority: 3 Message-Id: <20010801032507.CF35D37B403@hub.freebsd.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0127_01C0F01A.93A22C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 xsjA2iC5ubXnwfYuLi4gxsjA2rPdISEgIMbIwNogubm158H2Li4uIMbIwNqz3SEhIMbIwNqz 3b+hIL/DtvO/wiDAr7jTIMfRuLa05yAtIMG2xvjG7cH2IGJ5IGVucG9wxsjA2rPdwMwgubnH z7TCILWlv6m/5D8/IMGhuri0wiCw9z8/ILvnwdbGyMDaILq4tMIgtaewob+wPz8gv6Gwzy4u Li4uIL7Gwfe1tSDGyMDas93AuyC49Lb6vu6/5D8/IMK8uvEuLi4gN7/5IDHAzyCws8btx9Eg x9GxuSDF5MG+IMDOxc2z3SCw5rjFILnXILv9yLCxpLDtILvnwMzGrsH2v+QuLi4gsLPG7SCx 4rPkwLi3ziAyMDAxs+Igx9Egx9i1v77IILDmuMW4piDBpr/cx9EguPC15yC8rbrxvbqwobmr t+G287PXv6kuLiANCsbIwNqz3cC6Li4gDQoxLiCw5rjFsbmzuyDD1sD6vPbB2MDHILz2vPa3 4b/NIMjEutLBprimIMD8sN0gw6TFw8fPv6m8rSDAr8L7vcO/obTCILqwtbXAxyC89rz2t+Gw oSC1+7fOILrZwfYgvsq0wrTZs9e/qS4uILrOsKG8rbrxvbq1tSC4tsL5sKHB9rG4v6kuLi4g sde4rrDtLi4guMW4xb7IwPzA5cShsKEgwNa+7rytIL7IwPzHz7TZwfa/5D8gDQoyLiC7/ciw saSw7bHeuMUsIMTEx7vFzS+wocD8LCCwobG4L8DiyK0sIMDatb/C9ywgus61v7vqLCCxuMDO L7G4wfcgte7AxyC02b7nx9EgxKvF17DtuK66sCC7/ciwsaSw7bimIMH2v/jHz7jnLCCwoiDH 2LTnIMH2v6q/obyttbUgsMu79sfSILz2IMDWwfa/5C4uIMbIwNqz3cC6ILG5s7sgw9bDyrfO IMXrwM/AuyC067rxx8+/qSC6z8fRwfa/qsDHIMDOxc2z3SC7/ciwsaSw7cbkwMzB9rimILi4 tem++r3AtM+02S4uILrPx9G/obyttbUgwM7FzbPdwMwgsLO55rXHseK4piC52bbztMIguLbA vb+hvK3AzLjnLi4gyKQuLiDBpMShwPvAuLfOIL7Hv+u1yLTZsMWzqiCxubChuri+yLn9v6Eg wPrDy7XJILz2IMDWtMIgs7u/68DHILHbwMwgv8O287/DIL3Dv6G0wiDB77CiILvowabBtsSh IMfPsNq9wLTPtNkuLiANCjMuILvzsKGxpLDtxsjA2rPdILvzsKGxpLDttMIgxsjA2rPdwLsg xevHz7+pIL/CtvPAziC51yC/wMfBtvPAziC787ChuKYgwMy/68Dav6Gw1CCxpLDtx8+45ywg xsjA2rPdILDmuMW9w726xdvAuyDAzL/rx8+/qSDA2sO8wPvAuLfOILDmuMW4piDF68fRILjF uMW4piDH0iC89iDA1rW1t88gx8+0wiDGyMDas93AxyDH2b3JILytuvG9usDUtM+02S4gseLB uMDHILzux8649CC+98O8v6EgwNTB1sfPt8G46SDG8rHVIDEwMLi4v/ggwMy788DHIMDUwaEg uvG/67D6ILvzx7Agxse4xb+hILX7uKUgvPa89rfhILXuILrxv+vAzCDB9rOqxKGw1CC4ub7G IL3HwfrA+8DOIMbHuMXAzMDNwMwgsMXAxyC++LDFs6ogsKGw3SCw5sDvt8LAzCC2s77uwa4g s9fGvMHwwLi3zrrOxc0gv9y46cC7ILneseIgwM+89r+0vcC0z7TZLiC53bjpILTnu+fAxyC7 87ChsaSw7cDHILDmv+wgsbmzuyDD1sD6wMcgwNTBobz2vPa34b/NIFsyMDAxs+Igx9Egx9gg tb++yL+htMIguau34bfOIMDMv+vHz73HILz2IMDWvcC0z7TZXSCw5rjFILOrwvu89rz2t+G4 piCzq8L7sd2+18DHIDElLCDIxLrSwaa3ziDHz7+pIMDUwaHH0SC787Chwda16cDHILrOtOPA uyDD1rzSt87Hz7+pILChsN0gsObA77fCwLsgxbC/9iC15biztM+02SCw5rjFILnmvcTAxyDA /MDau/OwxbehsKEgwfa/+LXHuOcgtfu287ytILmrx9G068DHILmwx7C17rfPwMwgsKG0ycfV tM+02S4uLiC2x8fRILnos8qxpLDtuKYgtOu9xcfSILz2IMDWvu4gwM+8rsDMwbYgwMy788DH IMi/sPqwoSCwobTJx9W0z7TZLiANCsbIwNqz3cC6IMi4v/iwocDUvcMgurC1tcDHIMHWuc61 7rfPufjIo7imILHiwOfHz73HIMfKv+SwoSC++L3AtM+02S4gwMy0wiDAzsXNs93AzLbztMIg v624sLD4sKMguru3ocDHIMPrwfa4piDD1rTrx9Egu+y4rrfBtMIgwMe1tcDMuOcguLjAz7+h IMDWwLsgvPa1tSDA1rTCILrSuf3A+8DOIMfYxbe/oSDAx8fRILCzwM4gwaS6uMDHIMCvw+LA uyC5zL+sv6EguebB9sfPsO3A2iDH1MDUtM+02S4gtOu9xSCw5rjFuKYgxevH0SCwxbehuKYg x8+9w7fBuOkgud215b3DILDFt6HAusfgILDowcK5+MijuKYgwNS3wsfPvMW+3yDH1bTPtNku IMDMtMIgubDHsLTrsd3AuyC53rDFs6ogud3HsL3DIMDUsd2+18C7ILW5t8Egud6x4iDAp8fY ILLAIMfKv+TH0SCwzcDMuOcgvce47cGmsKEgvce9w7XHtMIgv+y4rrOqtvO/obytILDFt6HA xyC+yMD8x9TAuyC6uMDlx9IgvPYgwNa0wiCwzcDUtM+02S4gwMy3r8fRIMGhv6G1tSC60rG4 x8+w7SDIpL3DILnfu/3H0iC89iDA1rTCILvnsO2/oSC067rxx8+/qSDGyMDas93AzCDB98Gi ILDmuMW4piDB37DUx8+0wiC4xbjFvsjA/MDlxKG4piCwobW/wd+/oSDA1r3AtM+02S4gxsjA 2rPdsPogx9SysiC6uLTZIMDawK+307DtIL7IwPzH0SDA/MDau/OwxbehuKYgsObH6MfPvcOx 4iC52bb4tM+02S4gDQrCysH2LCDAr7jTLCCx27i2tOcsILD4sLPHwbfOxvfB7iwgu+e298Oj seIsIMXkt9C55iC17iDGyMDas93AxyC02b7nx9EgxL+5wrTPxrywoSC/qbevutDAxyDC/L+p uKYgseK02biusO0gwNa9wLTPtNkhISC/wLzFvK0gwNrB1iC+1r/rx8+/qSDB1r3DseIgudm2 +LTPtNkuLiDGyMDaILm5tefB9i4uLiDAzLvzIMbIwNqz3cDMvvq9wLTPtNkuLiANCrT1wMy7 8yC43sDPwLsgud7B9iC+ysC4vcO3wbjpILjewM+89r3FsMW6zrimxay4r8fPvcOx4iC52bb4 tM+02S4gILq7ILjewM/AuiBodHRwOi8vd3d3LmtyLmZyZWVic2Qub3JnL3N1cHBvcnQuc2h0 bWy/obytILq4sO0gud+827XIILjewM/A1LTPtNkuIMbIwNqz3cDHIMCvwM3H0SDBpLq4uKYg waaw+MfSILjxwPvAuLfOIMDbvLogtce++sC4uOcgZnJlZWJzZC1hcmNotNTAxyCx4rrQwLsg urvAx77GtM+w1CC788fPsNQgx8+/tLTZuOkgwfi9ycC4t84gu+ew+iC15biztM+02S4g ------=_NextPart_000_0127_01C0F01A.93A22C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0 bWw+DQo8aGVhZD4NCjx0aXRsZT7GyMDaILm5tefB9i4uLiDGyMDas90hISA8L3RpdGxlPg0K PG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJOYW1vIFdlYkVkaXRvciBBY3RpdmVY IENvbnRyb2wgdjIuMDAiPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0ieWVsbG93IiB0ZXh0 PSJibGFjayIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgYWxpbms9InJlZCI+DQo8aDIg YWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48YSBocmVmPSJodHRwOi8v d3d3LnBhbHphLm5ldCI+PGltZyBzcmM9Imh0dHA6Ly93d3cucGFsemEubmV0L2ltYWdlcy9p bmRleF9sb2dvLmdpZiIgYm9yZGVyPSIwIj48L2E+IDxmb250IGZhY2U9IrvqtbmxpLz2IEwi IHNpemU9IjYiIGNvbG9yPSJibGFjayI+PGI+xsjA2iC5ubXnwfYuLi4gxsjA2rPdISE8L2I+ PC9mb250PiA8L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAl OyI+PGZvbnQgZmFjZT0iu+q1ubGkvPYgTCIgc2l6ZT0iNiIgY29sb3I9ImJsdWUiPjxiPg0K PGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0i QXJpYWwiIHNpemU9IjQiIGNvbG9yPSJibHVlIj7GyMDas92/oSC/w7bzv8IgwK+40yDH0bi2 tOcgLSDBtsb4xu3B9iBieSBlbnBvcDwvYj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNp emU9IjIiIGNvbG9yPSJibGFjayI+PC9mb250PjwvaDI+DQo8ZW1iZWQgc3JjPSJodHRwOi8v ZW5wb3AuY29tL3dlYl9hbmkvYTAwMjMvYTAwMjMuc3dmIiB3aWR0aD0iMzc1IiBoZWlnaHQ9 IjMwMCI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9u dCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj7GyMDas93AzCC5ucfP tMIgtaW/qb/kPz8gwaG6uLTCILD3Pz8gPC9iPjwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJs ZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9 IjIiIGNvbG9yPSJibGFjayI+PGI+u+fB1sbIwNoguri0wiC1p7Chv7A/PzwvYj48L2ZvbnQ+ PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0 eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29s b3I9ImJsYWNrIj48Yj6/obDPLi4uLi4gvsbB97W1IMbIwNqz3cC7ILj0tvq+7r/kPz8gwry6 8S4uLjwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIg YWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlh bCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj43v/kgMcDPILCzxu3H0SDH0bG5IMXkwb4g wM7FzbPdILDmuMUgudcgu/3IsLGksO0gu+fAzMauwfa/5C4uLiA8L2I+PC9mb250PjwvaDI+ DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNl PSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj6ws8btILHis+TAuLfOIDIwMDGz 4iDH0SDH2LW/vsggsOa4xbimIMGmv9zH0SC48LXnILytuvG9urChPC9iPjwvZm9udD48L2gy Pg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFj ZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+uau34bbzs9e/qS4uPC9iPjwv Zm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxicj4NCjxoMiBhbGln bj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBz aXplPSI0IiBjb2xvcj0iYmxhY2siPjxiPsbIwNqz3cC6Li48L2I+PC9mb250Pjxmb250IGNv bG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGJyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHls ZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjQiIGNvbG9y PSJibHVlIj48Yj4xLiCw5rjFPC9iPjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0i MiIgY29sb3I9ImJsdWUiPjwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0i bGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjQiIGNvbG9yPSJi bGFjayI+PGI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48 Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj6xubO7IMPWwPq8 9sHYwMcgvPa89rfhv80gyMS60sGmuKYgwPyw3SDDpMXDx8+/qbytPC9iPjwvZm9udD48Zm9u dCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0i YmxhY2siPjxiPsCvwvu9w7+htMIgurC1tcDHILz2vPa34bChILX7t84gutnB9iC+yrTCtNmz 17+pLi48L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgy IGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJp YWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+us6wobytuvG9urW1ILi2wvmwocH2sbi/ qS4uLiA8L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgy IGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJp YWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+sde4rrDtLi4guMW4xb7IwPzA5cShsKEg wNa+7rytIL7IwPzHz7TZwfa/5D88L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwv Zm9udD48L2gyPg0KPGJyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjQiIGNvbG9yPSJibHVlIj48Yj4yLiC7 /ciwsaSw7TwvYj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJi bHVlIj48L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSI0IiBjb2xvcj0iYmxhY2siPjxiPg0K PGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0i QXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+sd64xSwgxMTHu8XNL7ChwPwsILCh sbgvwOLIrSwgwNq1v8L3LCC6zrW/u+osILG4wM4vsbjB9yC17sDHILTZvufH0SA8L2I+PC9m b250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0 IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIi IGNvbG9yPSJibGFjayI+PGI+xKvF17DtuK66sCC7/ciwsaSw7bimIMH2v/jHz7jnLCCwoiDH 2LTnIMH2v6q/obyttbUgsMu79sfSILz2IMDWwfa/5C4uPC9iPjwvZm9udD48Zm9udCBjb2xv cj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2si PjxiPsbIwNqz3cC6ILG5s7sgw9bDyrfOIMXrwM/AuyC067rxx8+/qSC6z8fRwfa/qsDHPC9i PjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0i bGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXpl PSIyIiBjb2xvcj0iYmxhY2siPjxiPsDOxc2z3SC7/ciwsaSw7cbkwMzB9rimILi4tem++r3A tM+02S4uICA8L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0K PGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0i QXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+us/H0b+hvK21tSDAzsXNs93AzCCw s7nmtcex4rimILnZtvO0wiC4tsC9v6G8rcDMuOcuLiAgPC9iPjwvZm9udD48Zm9udCBjb2xv cj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2si PjxiPsikLi4gwaTEocD7wLi3ziC+x7/rtci02bDFs6ogsbmwobq4vsi5/b+hIMD6w8u1ySC8 9iDA1rTCILO7v+vAxyCx28DMIDwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9m b250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48 Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj6/w7bzv8MgvcO/ obTCIMHvsKIgu+jBpsG2xKEgx8+w2r3AtM+02S4uICA8L2I+PC9mb250Pjxmb250IGNvbG9y PSJibGFjayI+IDwvZm9udD48L2gyPg0KPGJyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0i bGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjQiIGNvbG9yPSJi bHVlIj4zLiC787ChsaSw7TwvYj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIi IGNvbG9yPSJibHVlIj48L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSI0IiBjb2xvcj0iYmxh Y2siPjxiPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZv bnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+xsjA2rPdILvzsKGx pLDttMIgxsjA2rPdwLsgxevHz7+pIL/CtvPAziC51yC/wMfBtvPAziC787ChuKY8L2I+PC9m b250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0 IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIi IGNvbG9yPSJibGFjayI+PGI+wMy/68Dav6Gw1CCxpLDtx8+45ywgxsjA2rPdILDmuMW9w726 xdvAuyDAzL/rx8+/qTwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250Pjwv aDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBm YWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj7A2sO8wPvAuLfOILDmuMW4 piDF68fRILjFuMW4piDH0iC89iDA1rW1t88gx8+0wjwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9 ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhl aWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48 Yj7GyMDas93AxyDH2b3JILytuvG9usDUtM+02S48L2I+PC9mb250Pjxmb250IGNvbG9yPSJi bGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWln aHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+ seLBuMDHILzux8649CC+98O8v6EgwNTB1sfPt8G46SDG8rHVIDEwMLi4v/ggwMy788DHIDwv Yj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249 ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6 ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj7A1MGhILrxv+uw+iC788ewIMbHuMW/oSC1+7ilILz2 vPa34SC17iC68b/rwMwgwfazqsShsNQguLm+xjwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJs YWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj69 x8H6wPvAziDGx7jFwMzAzcDMILDFwMcgvviwxbOqILChsN0gsObA77fCwMwgtrO+7sGuPC9i PjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0i bGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXpl PSIyIiBjb2xvcj0iYmxhY2siPjxiPrPXxrzB8MC4t866zsXNIL/cuOnAuyC53rHiIMDPvPa/ tL3AtM+02S48L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPiAN CjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9 IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxiPrnduOkgtOe758DHILvzsKGxpLDt wMcgsOa/7CCxubO7IMPWwPrAxyDA1MGhvPa89rfhv80gPC9iPjwvZm9udD48Zm9udCBjb2xv cj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2si PjxiPlsyMDAxs+Igx9Egx9ggtb++yL+htMIguau34bfOIMDMv+vHz73HILz2IMDWvcC0z7TZ XTwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxp Z249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIg c2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj6w5rjFILOrwvu89rz2t+G4piCzq8L7sd2+18DH IDElLCDIxLrSwaa3ziDHz7+pPC9iPjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2Zv bnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxm b250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxiPsDUwaHH0SC787Ch wda16cDHILrOtOPAuyDD1rzSt87Hz7+pILChsN0gsObA77fCwLs8L2I+PC9mb250Pjxmb250 IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0i bGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJi bGFjayI+PGI+xbC/9iC15biztM+02TwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4g PC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7 Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj6w5rjFILnm vcTAxyDA/MDau/OwxbehsKEgwfa/+LXHuOc8L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFj ayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+tfu2 87ytILmrx9G068DHILmwx7C17rfPwMwgsKG0ycfVtM+02S4uLjwvYj48L2ZvbnQ+PGZvbnQg Y29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJs aW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJs YWNrIj48Yj62x8fRILnos8qxpLDtuKYgtOu9xcfSILz2IMDWvu4gwM+8rsDMwbYgwMy788DH PC9iPjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGln bj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBz aXplPSIyIiBjb2xvcj0iYmxhY2siPjxiPsi/sPqwoSCwobTJx9W0z7TZLjwvYj48L2ZvbnQ+ PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8YnI+DQo8aDIgYWxpZ249Imxl ZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0i NCIgY29sb3I9ImJsYWNrIj48Yj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxi PsbIwNqz3cC6IMi4v/iwocDUvcMgurC1tcDHIMHWuc617rfPufjIo7imPC9iPjwvZm9udD48 Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xv cj0iYmxhY2siPjxiPrHiwOfHz73HIMfKv+SwoSC++L3AtM+02S48L2I+PC9mb250Pjxmb250 IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0i bGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJi bGFjayI+PGI+wMy0wiDAzsXNs93AzLbztMIgv624sLD4sKMguru3ocDHIMPrwfa4pjwvYj48 L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249Imxl ZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0i MiIgY29sb3I9ImJsYWNrIj48Yj7D1rTrx9Egu+y4rrfBtMIgwMe1tcDMuOc8L2I+PC9mb250 Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBz dHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNv bG9yPSJibGFjayI+PGI+uLjAz7+hIMDWwLsgvPa1tSDA1rTCILrSuf3A+8DOIMfYxbe/oSDA x8fRPC9iPjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBh bGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFs IiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxiPrCzwM4gwaS6uMDHIMCvw+LAuyC5zL+sv6Eg uebB9sfPsO3A2iDH1MDUtM+02S48L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwv Zm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+ PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+tOu9xSCw5rjF uKYgxevH0SCwxbehuKYgx8+9w7fBuOk8L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+ IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAl OyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+ud215b3D ILDFt6HAusfgILDowcK5+MijuKYgwNS3wsfPvMW+3yDH1bTPtNkuPC9iPjwvZm9udD48Zm9u dCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0i YmxhY2siPjxiPsDMtMIgubDHsLTrsd3AuyC53rDFs6ogud3HsL3DIMDUsd2+18C7ILW5t8Eg ud6x4jwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIg YWxpZ249ImxlZnQiIHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlh bCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48Yj7Ap8fYILLAIMfKv+TH0SCwzcDMuOc8L2I+ PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJs ZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9 IjIiIGNvbG9yPSJibGFjayI+PGI+vce47cGmsKEgvce9w7XHtMIgv+y4rrOqtvO/obytPC9i PjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0i bGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsiPjxmb250IGZhY2U9IkFyaWFsIiBzaXpl PSIyIiBjb2xvcj0iYmxhY2siPjxiPrDFt6HAxyC+yMD8x9TAuyC6uMDlx9IgvPYgwNa0wiCw zcDUtM+02S48L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0K PGgyIGFsaWduPSJsZWZ0IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0i QXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+wMy3r8fRIMGhv6G1tSC60rG4x8+w 7SDIpL3DILnfu/3H0iC89iDA1rTCPC9iPjwvZm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8 L2ZvbnQ+PC9oMj4NCjxoMiBhbGlnbj0ibGVmdCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEwJTsi Pjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxiPrvnsO2/oSC0 67rxx8+/qSDGyMDas93AzCDB98GiILDmuMW4piDB37DUx8+0wjwvYj48L2ZvbnQ+PGZvbnQg Y29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiIHN0eWxlPSJs aW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJs YWNrIj48Yj64xbjFvsjA/MDlxKG4piCwobW/wd+/oSDA1r3AtM+02S48L2I+PC9mb250Pjxm b250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0IiBzdHls ZT0ibGluZS1oZWlnaHQ6MTAlOyI+PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9y PSJibGFjayI+PGI+xsjA2rPdsPogx9SysiC6uLTZIMDawK+307DtIL7IwPzH0TwvYj48L2Zv bnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQi IHN0eWxlPSJsaW5lLWhlaWdodDoxMCU7Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIg Y29sb3I9ImJsYWNrIj48Yj7A/MDau/OwxbehuKYgsObH6MfPvcOx4iC52bb4tM+02S48L2I+ PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPg0KPGJyPg0KPGgyIGFs aWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48 Yj7CysH2LCDAr7jTLCCx27i2tOcsILD4sLPHwbfOxvfB7iwgu+e298OjseIsIMXkt9C55iC1 7jwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+IA0KPGgyIGFs aWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIj48 Yj7GyMDas93AxyC02b7nx9EgxL+5wrTPxrywoSC/qbevutDAxyDC/L+puKY8L2I+PC9mb250 Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPiANCjxoMiBhbGlnbj0ibGVmdCI+ PGZvbnQgZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+seK02biusO0g wNa9wLTPtNkhITwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250PjwvaDI+ DQo8aDIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0i YmxhY2siPjxiPr/AvMW8rSDA2sHWIL7Wv+vHz7+pIMHWvcOx4iC52bb4tM+02S4uPC9iPjwv Zm9udD48Zm9udCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4gDQo8aDIgYWxpZ249Imxl ZnQiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIzIiBjb2xvcj0iYmxhY2siPjxiPsbIwNog ubm158H2Li4uIMDMu/MgxsjA2rPdwMy++r3AtM+02S4uPC9iPjwvZm9udD48Zm9udCBjb2xv cj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4gDQo8YnI+DQo8aDIgYWxpZ249ImxlZnQiPjxmb250 IHNpemU9IjIiIGNvbG9yPSJibGFjayI+tPXAzLvzILjewM/AuyC53sH2IL7KwLi9w7fBuOkg PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSJyZWQiPjxhIGhyZWY9Im1haWx0bzp3ZWJh ZG1pbkBwYWx6YS5uZXQiPrjewM+89r3FsMW6zrimPGEvPjwvZm9udD48Zm9udCBzaXplPSIy IiBjb2xvcj0ieWVsbG93Ij4NCjxoMiBhbGlnbj0ibGVmdCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9ImJsYWNrIj7FrLivx8+9w7HiILnZtvi0z7TZPC9mb250Pjxmb250IGNvbG9yPSJibGFj ayI+LjwvZm9udD48L2gyPg0KPGgyPjxmb250IGNvbG9yPSJibGFjayI+Jm5ic3A7IDwvZm9u dD48L2gyPg0KPGgyIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iMiIg Y29sb3I9ImJsYWNrIj48Yj66uyC43sDPwLogaHR0cDovL3d3dy5rci5mcmVlYnNkLm9yZy9z dXBwb3J0LnNodG1sv6G8rTwvYj48L2ZvbnQ+PGZvbnQgY29sb3I9ImJsYWNrIj4gPC9mb250 PjwvaDI+DQo8aDIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBj b2xvcj0iYmxhY2siPjxiPrq4sO0gud+827XIILjewM/A1LTPtNkuPC9iPjwvZm9udD48Zm9u dCBjb2xvcj0iYmxhY2siPiA8L2ZvbnQ+PC9oMj4gDQo8aDIgYWxpZ249ImxlZnQiPjxmb250 IGZhY2U9IkFyaWFsIiBzaXplPSIyIiBjb2xvcj0iYmxhY2siPjxiPsbIwNqz3cDHIMCvwM3H 0SDBpLq4uKYgwaaw+MfSILjxwPvAuLfOIMDbvLogtce++sC4uOc8L2I+PC9mb250Pjxmb250 IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPiANCjxoMiBhbGlnbj0ibGVmdCI+PGZvbnQg ZmFjZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+ZnJlZWJzZC1hcmNotNTA xyCx4rrQwLsgurvAx77GtM+w1CC788fPsNQgx8+/tLTZuOk8L2I+PC9mb250Pjxmb250IGNv bG9yPSJibGFjayI+IDwvZm9udD48L2gyPiANCjxoMiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFj ZT0iQXJpYWwiIHNpemU9IjIiIGNvbG9yPSJibGFjayI+PGI+wfi9ycC4t84gu+ew+iC15biz tM+02S48L2I+PC9mb250Pjxmb250IGNvbG9yPSJibGFjayI+IDwvZm9udD48L2gyPiANCjwv Ym9keT4NCjwvaHRtbD4= ------=_NextPart_000_0127_01C0F01A.93A22C00-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 20:49:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 12EAA37B405; Tue, 31 Jul 2001 20:49:11 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f713mYf55260; Tue, 31 Jul 2001 23:48:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 31 Jul 2001 23:48:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Cc: stable@FreeBSD.org Subject: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-909119149-996637714=:54921" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-909119149-996637714=:54921 Content-Type: TEXT/PLAIN; charset=US-ASCII One of the observations that has been made fairly frequently to me is that the current default inetd.conf puts many FreeBSD users at risk unnecessarily, as many of them have moved to using SSH for remote access needs. In particular in light of the recent ftpd and telnetd security bugs, it seems like 4.4-RELEASE would be a good time to move to a more conservative default of having both of these services disabled in the base install, as both NetBSD and OpenBSD have moved to doing. The attached patch modifies inetd.conf to disable all services by default, and expands on the comments in the header so as to be more instructive concerning enabling and disabling services. It also modifies sysinstall such that enabling inetd in the post-install configuration describes inetd more than previously, mentions the risks, and then also presents the opportunity to edit inetd.conf if inetd is enabled. Also, during the normal install, the user is automatically prompted to enable or disable inetd in much the same style as the NFS server. I believe this addresses concerns about enabling remote telnetd login during install, which was one of the primary reasons to leave it enabled by default. Note that this does not disable the installation of the necessary software, merely disable it by default, so users can enable them again easily by modifying inetd.conf, either with the help of sysinstall, or manually. These changes select a safe default, but hopefully offer the necessary flexibility for users needing the services specifically. I've gotten reviews on content and configurability from Warner Losh, Chris Costello, and Jake Burkholder. Assuming no one seriously objects (or only a small number of people do), I'll commit to -CURRENT within a day or so, and MFC (pending RE approval) shortly there-after. Clearly, it would be desirable to have this in as many of the release snapshots as possible. Here, for the patch-impaired, are a couple of excerpts from sysinstall, so that language can be evaluated for readability and comprehensibility for more novice users: x x [ ] Gateway This machine will route packets between interfaces x x [X] inetd This machine wants to run the inet daemon x x [X] NFS client This machine will be an NFS client x xlqqqqqqqqqqqqqqqqqqqqq User Confirmation Requested qqqqqqqqqqqqqqqqqqqqqkx x x xx The Internet Super Server (inetd) allows a number of simple Internet xx x x xx services to be enabled, including finger, ftp, and telnetd. Enabling xx x x xx these services may increase risk of security problems by increasing xx x x xx the exposure of your system. xx x x xx xx x x xx With this in mind, do you wish to enable inetd? xx x x xx xx x x xtqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqux x x xx [ Yes ] No xx x x xlqqqqqqqqqqqqqqqqqqqqq User Confirmation Requested qqqqqqqqqqqqqqqqqqqqqkx x x xx Inetd relies on its configuration file, /etc/inetd.conf, to determine xx x x xx which Internet services will be available. The default FreeBSD xx x x xx inetd.conf leaves all services disabled by default, so they must be xx x x xx specifically enabled in the configuration file before they will xx x x xx function, even once inetd is enabled. xx x x xx xx x x xx Select [Yes] now to invoke an editor on /etc/inetd.conf, or [No] to xx x x xx use the current settings. xx x x xx xx x x xtqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqux x --0-909119149-996637714=:54921 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="inetd_defaults.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: PyB1c3Iuc2Jpbi9zeXNpbnN0YWxsL2tleW1hcC5oDQo/IHVzci5zYmluL3N5 c2luc3RhbGwvcnRlcm1jYXANCj8gdXNyLnNiaW4vc3lzaW5zdGFsbC9tYWtl ZGV2cy5jDQo/IHVzci5zYmluL3N5c2luc3RhbGwvc3lzaW5zdGFsbA0KPyB1 c3Iuc2Jpbi9zeXNpbnN0YWxsL3N5c2luc3RhbGwuOC5neg0KSW5kZXg6IHVz ci5zYmluL3N5c2luc3RhbGwvY29uZmlnLmMNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy91c3Iuc2Jpbi9zeXNp bnN0YWxsL2NvbmZpZy5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xODMN CmRpZmYgLXUgLXIxLjE4MyBjb25maWcuYw0KLS0tIHVzci5zYmluL3N5c2lu c3RhbGwvY29uZmlnLmMJMjAwMS8wNy8xNyAwNDowOTo1MAkxLjE4Mw0KKysr IHVzci5zYmluL3N5c2luc3RhbGwvY29uZmlnLmMJMjAwMS8wOC8wMSAwMzoz NDo1OQ0KQEAgLTk1NSw2ICs5NTUsMzggQEANCiB9DQogDQogaW50DQorY29u ZmlnSW5ldGQoZGlhbG9nTWVudUl0ZW0gKnNlbGYpDQorew0KKyAgICBjaGFy IGNtZFsyNTZdOw0KKw0KKyAgICBXSU5ET1cgKncgPSBzYXZlc2NyKCk7DQor DQorICAgIGlmIChtc2dZZXNObygiVGhlIEludGVybmV0IFN1cGVyIFNlcnZl ciAoaW5ldGQpIGFsbG93cyBhIG51bWJlciBvZiBzaW1wbGUgSW50ZXJuZXRc biINCisgICAgICAgICAgICAgICAgICJzZXJ2aWNlcyB0byBiZSBlbmFibGVk LCBpbmNsdWRpbmcgZmluZ2VyLCBmdHAsIGFuZCB0ZWxuZXRkLiAgRW5hYmxp bmdcbiINCisgICAgICAgICAgICAgICAgICJ0aGVzZSBzZXJ2aWNlcyBtYXkg aW5jcmVhc2UgcmlzayBvZiBzZWN1cml0eSBwcm9ibGVtcyBieSBpbmNyZWFz aW5nXG4iDQorICAgICAgICAgICAgICAgICAidGhlIGV4cG9zdXJlIG9mIHlv dXIgc3lzdGVtLlxuXG4iDQorICAgICAgICAgICAgICAgICAiV2l0aCB0aGlz IGluIG1pbmQsIGRvIHlvdSB3aXNoIHRvIGVuYWJsZSBpbmV0ZD9cbiIpKSB7 DQorICAgICAgICB2YXJpYWJsZV9zZXQyKCJpbmV0ZF9lbmFibGUiLCAiTk8i LCAxKTsNCisgICAgfSBlbHNlIHsNCisgICAgICAgIC8qIElmIGluZXRkIGlz IGVuYWJsZWQsIHdlJ2xsIG5lZWQgYW4gaW5ldGQuY29uZiAqLw0KKw0KKwlp ZiAoIW1zZ1llc05vKCJpbmV0ZCg4KSByZWxpZXMgb24gaXRzIGNvbmZpZ3Vy YXRpb24gZmlsZSwgL2V0Yy9pbmV0ZC5jb25mLCB0byBkZXRlcm1pbmVcbiIN CisgICAgICAgICAgICAgICAgICAgIndoaWNoIEludGVybmV0IHNlcnZpY2Vz IHdpbGwgYmUgYXZhaWxhYmxlLiAgVGhlIGRlZmF1bHQgRnJlZUJTRFxuIg0K KyAgICAgICAgICAgICAgICAgICAiaW5ldGQuY29uZig1KSBsZWF2ZXMgYWxs IHNlcnZpY2VzIGRpc2FibGVkIGJ5IGRlZmF1bHQsIHNvIHRoZXkgbXVzdCBi ZVxuIg0KKyAgICAgICAgICAgICAgICAgICAic3BlY2lmaWNhbGx5IGVuYWJs ZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24gZmlsZSBiZWZvcmUgdGhleSB3aWxs XG4iDQorICAgICAgICAgICAgICAgICAgICJmdW5jdGlvbiwgZXZlbiBvbmNl IGluZXRkKDgpIGlzIGVuYWJsZWQuXG5cbiINCisgICAgICAgICAgICAgICAg ICAgIlNlbGVjdCBbWWVzXSBub3cgdG8gaW52b2tlIGFuIGVkaXRvciBvbiAv ZXRjL2luZXRkLmNvbmYsIG9yIFtOb10gdG9cbiINCisgICAgICAgICAgICAg ICAgICAgInVzZSB0aGUgY3VycmVudCBzZXR0aW5ncy5cbiIpKSB7DQorICAg ICAgICAgICAgc3ByaW50ZihjbWQsICIlcyAvZXRjL2luZXRkLmNvbmYiLCB2 YXJpYWJsZV9nZXQoVkFSX0VESVRPUikpOw0KKyAgICAgICAgICAgIGRpYWxv Z19jbGVhcigpOw0KKyAgICAgICAgICAgIHN5c3RlbUV4ZWN1dGUoY21kKTsN CisgICAgICAgICAgICB2YXJpYWJsZV9zZXQyKCJpbmV0ZF9lbmFibGUiLCAi WUVTIiwgMSk7DQorCX0NCisgICAgfQ0KKyAgICByZXN0b3Jlc2NyKHcpOw0K K30NCisNCitpbnQNCiBjb25maWdORlNTZXJ2ZXIoZGlhbG9nTWVudUl0ZW0g KnNlbGYpDQogew0KICAgICBjaGFyIGNtZFsyNTZdOw0KSW5kZXg6IHVzci5z YmluL3N5c2luc3RhbGwvZGlzcGF0Y2guYw0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3Vzci5zYmluL3N5c2lu c3RhbGwvZGlzcGF0Y2guYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzgN CmRpZmYgLXUgLXIxLjM4IGRpc3BhdGNoLmMNCi0tLSB1c3Iuc2Jpbi9zeXNp bnN0YWxsL2Rpc3BhdGNoLmMJMjAwMS8wNy8wNSAwOTo1MTowOQkxLjM4DQor KysgdXNyLnNiaW4vc3lzaW5zdGFsbC9kaXNwYXRjaC5jCTIwMDEvMDgvMDEg MDM6MzU6MDUNCkBAIC01Miw2ICs1Miw3IEBADQogfSByZXNXb3Jkc1tdID0g ew0KICAgICB7ICJjb25maWdBbm9uRlRQIiwJCWNvbmZpZ0Fub25GVFAJCX0s DQogICAgIHsgImNvbmZpZ1JvdXRlciIsCQljb25maWdSb3V0ZXIJCX0sDQor ICAgIHsgImNvbmZpZ0luZXRkIiwJCWNvbmZpZ0luZXRkCQl9LA0KICAgICB7 ICJjb25maWdORlNTZXJ2ZXIiLAljb25maWdORlNTZXJ2ZXIJCX0sDQogICAg IHsgImNvbmZpZ05UUCIsCQljb25maWdOVFAJCX0sDQogICAgIHsgImNvbmZp Z1BDTkZTRCIsCQljb25maWdQQ05GU0QJCX0sDQpJbmRleDogdXNyLnNiaW4v c3lzaW5zdGFsbC9pbnN0YWxsLmMNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy91c3Iuc2Jpbi9zeXNpbnN0YWxs L2luc3RhbGwuYyx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMzAwDQpkaWZm IC11IC1yMS4zMDAgaW5zdGFsbC5jDQotLS0gdXNyLnNiaW4vc3lzaW5zdGFs bC9pbnN0YWxsLmMJMjAwMS8wNy8xNyAwNDowOTo1MAkxLjMwMA0KKysrIHVz ci5zYmluL3N5c2luc3RhbGwvaW5zdGFsbC5jCTIwMDEvMDgvMDEgMDM6MzU6 MTgNCkBAIC01NzMsNiArNTczLDEwIEBADQogCXZhcmlhYmxlX3NldDIoImdh dGV3YXlfZW5hYmxlIiwgIllFUyIsIDEpOw0KIA0KICAgICBkaWFsb2dfY2xl YXJfbm9yZWZyZXNoKCk7DQorICAgIGlmICghbXNnTm9ZZXMoIkRvIHlvdSB3 YW50IHRvIGNvbmZpZ3VyZSBpbmV0ZCBhbmQgc2ltcGxlIGludGVybmV0IHNl cnZpY2VzPyIpKQ0KKyAgICAgICAgY29uZmlnSW5ldGQoc2VsZik7DQorDQor ICAgIGRpYWxvZ19jbGVhcl9ub3JlZnJlc2goKTsNCiAgICAgaWYgKCFtc2dO b1llcygiRG8geW91IHdhbnQgdG8gaGF2ZSBhbm9ueW1vdXMgRlRQIGFjY2Vz cyB0byB0aGlzIG1hY2hpbmU/IikpDQogCWNvbmZpZ0Fub25GVFAoc2VsZik7 DQogDQpJbmRleDogdXNyLnNiaW4vc3lzaW5zdGFsbC9tZW51cy5jDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMv dXNyLnNiaW4vc3lzaW5zdGFsbC9tZW51cy5jLHYNCnJldHJpZXZpbmcgcmV2 aXNpb24gMS4zMTANCmRpZmYgLXUgLXIxLjMxMCBtZW51cy5jDQotLS0gdXNy LnNiaW4vc3lzaW5zdGFsbC9tZW51cy5jCTIwMDEvMDcvMzEgMjE6MzA6NTcJ MS4zMTANCisrKyB1c3Iuc2Jpbi9zeXNpbnN0YWxsL21lbnVzLmMJMjAwMS8w OC8wMSAwMzozNTo1Mw0KQEAgLTIzNSw2ICsyMzUsNyBAQA0KICAgICAgIHsg IiBGVFAgc2l0ZXMiLAkJIlRoZSBGVFAgbWlycm9yIHNpdGUgbGlzdGluZy4i LAkJTlVMTCwgZG1lbnVTdWJtZW51LCBOVUxMLCAmTWVudU1lZGlhRlRQIH0s DQogICAgICAgeyAiIEdhdGV3YXkiLAkJIlNldCBmbGFnIHRvIHJvdXRlIHBh Y2tldHMgYmV0d2VlbiBpbnRlcmZhY2VzLiIsIGRtZW51VmFyQ2hlY2ssIGRt ZW51VG9nZ2xlVmFyaWFibGUsIE5VTEwsICJnYXRld2F5PVlFUyIgfSwNCiAg ICAgICB7ICIgSFRNTCBEb2NzIiwJCSJUaGUgSFRNTCBkb2N1bWVudGF0aW9u IG1lbnUiLAkJTlVMTCwgZG9jQnJvd3NlciB9LA0KKyAgICAgIHsgIiBpbmV0 ZCBDb25maWd1cmF0aW9uIiwJIkNvbmZpZ3VyZSBpbmV0ZCBhbmQgc2ltcGxl IGludGVybmV0IHNlcnZpY2VzLiIsCWRtZW51VmFyQ2hlY2ssIGNvbmZpZ0lu ZXRkLCBOVUxMLCAiaW5ldGRfZW5hYmxlPVlFUyIgfSwNCiAgICAgICB7ICIg SW5zdGFsbCwgU3RhbmRhcmQiLAkiQSBzdGFuZGFyZCBzeXN0ZW0gaW5zdGFs bGF0aW9uLiIsCU5VTEwsIGluc3RhbGxTdGFuZGFyZCB9LA0KICAgICAgIHsg IiBJbnN0YWxsLCBFeHByZXNzIiwJIkFuIGV4cHJlc3Mgc3lzdGVtIGluc3Rh bGxhdGlvbi4iLAlOVUxMLCBpbnN0YWxsRXhwcmVzcyB9LA0KICAgICAgIHsg IiBJbnN0YWxsLCBDdXN0b20iLAkiVGhlIGN1c3RvbSBpbnN0YWxsYXRpb24g bWVudSIsCQlOVUxMLCBkbWVudVN1Ym1lbnUsIE5VTEwsICZNZW51SW5zdGFs bEN1c3RvbSB9LA0KQEAgLTEzMzIsNyArMTMzMyw3IEBADQogICAgICAgeyAi IEdhdGV3YXkiLAkiVGhpcyBtYWNoaW5lIHdpbGwgcm91dGUgcGFja2V0cyBi ZXR3ZWVuIGludGVyZmFjZXMiLA0KIAlkbWVudVZhckNoZWNrLAlkbWVudVRv Z2dsZVZhcmlhYmxlLCBOVUxMLCAiZ2F0ZXdheV9lbmFibGU9WUVTIiB9LA0K ICAgICAgIHsgIiBpbmV0ZCIsCSJUaGlzIG1hY2hpbmUgd2FudHMgdG8gcnVu IHRoZSBpbmV0IGRhZW1vbiIsDQotCWRtZW51VmFyQ2hlY2ssCWRtZW51VG9n Z2xlVmFyaWFibGUsIE5VTEwsICJpbmV0ZF9lbmFibGU9WUVTIiB9LA0KKwlk bWVudVZhckNoZWNrLAljb25maWdJbmV0ZCwgTlVMTCwgImluZXRkX2VuYWJs ZT1ZRVMiIH0sDQogICAgICAgeyAiIE5GUyBjbGllbnQiLAkiVGhpcyBtYWNo aW5lIHdpbGwgYmUgYW4gTkZTIGNsaWVudCIsDQogCWRtZW51VmFyQ2hlY2ss CWRtZW51VG9nZ2xlVmFyaWFibGUsIE5VTEwsICJuZnNfY2xpZW50X2VuYWJs ZT1ZRVMiIH0sDQogICAgICAgeyAiIE5GUyBzZXJ2ZXIiLAkiVGhpcyBtYWNo aW5lIHdpbGwgYmUgYW4gTkZTIHNlcnZlciIsDQpJbmRleDogdXNyLnNiaW4v c3lzaW5zdGFsbC9zeXNpbnN0YWxsLmgNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy91c3Iuc2Jpbi9zeXNpbnN0 YWxsL3N5c2luc3RhbGwuaCx2DQpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjA5 DQpkaWZmIC11IC1yMS4yMDkgc3lzaW5zdGFsbC5oDQotLS0gdXNyLnNiaW4v c3lzaW5zdGFsbC9zeXNpbnN0YWxsLmgJMjAwMS8wNy8xNyAwNDowOTo1MAkx LjIwOQ0KKysrIHVzci5zYmluL3N5c2luc3RhbGwvc3lzaW5zdGFsbC5oCTIw MDEvMDgvMDEgMDM6MzY6MDYNCkBAIC00NDcsNiArNDQ3LDcgQEANCiBleHRl cm4gaW50CWNvbmZpZ1hEZXNrdG9wKGRpYWxvZ01lbnVJdGVtICpzZWxmKTsN CiBleHRlcm4gaW50CWNvbmZpZ1JvdXRlcihkaWFsb2dNZW51SXRlbSAqc2Vs Zik7DQogZXh0ZXJuIGludAljb25maWdQQ05GU0QoZGlhbG9nTWVudUl0ZW0g KnNlbGYpOw0KK2V4dGVybiBpbnQJY29uZmlnSW5ldGQoZGlhbG9nTWVudUl0 ZW0gKnNlbGYpOw0KIGV4dGVybiBpbnQJY29uZmlnTkZTU2VydmVyKGRpYWxv Z01lbnVJdGVtICpzZWxmKTsNCiBleHRlcm4gaW50CWNvbmZpZ1dyaXRlUkNf Y29uZihkaWFsb2dNZW51SXRlbSAqc2VsZik7DQogZXh0ZXJuIGludAljb25m aWdTZWN1cml0eVByb2ZpbGUoZGlhbG9nTWVudUl0ZW0gKnNlbGYpOw0KSW5k ZXg6IGV0Yy9pbmV0ZC5jb25mDQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS Q1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvZXRjL2luZXRkLmNvbmYsdg0KcmV0 cmlldmluZyByZXZpc2lvbiAxLjQ4DQpkaWZmIC11IC1yMS40OCBpbmV0ZC5j b25mDQotLS0gZXRjL2luZXRkLmNvbmYJMjAwMS8wMy8zMCAxMDoyNTo0MAkx LjQ4DQorKysgZXRjL2luZXRkLmNvbmYJMjAwMS8wOC8wMSAwMzozNjoxMA0K QEAgLTIsMTIgKzIsMTQgQEANCiAjDQogIyBJbnRlcm5ldCBzZXJ2ZXIgY29u ZmlndXJhdGlvbiBkYXRhYmFzZQ0KICMNCi0jIGRlZmluZSAqYm90aCogSVB2 NCBhbmQgSVB2NiBlbnRyaWVzIGZvciBkdWFsLXN0YWNrIHN1cHBvcnQuDQor IyBEZWZpbmUgKmJvdGgqIElQdjQgYW5kIElQdjYgZW50cmllcyBmb3IgZHVh bC1zdGFjayBzdXBwb3J0Lg0KKyMgVG8gZGlzYWJsZSBhIHNlcnZpY2UsIGNv bW1lbnQgaXQgb3V0IGJ5IHByZWZpeGluZyB0aGUgbGluZSB3aXRoICcjJy4N CisjIFRvIGVuYWJsZSBhIHNlcnZpY2UsIHJlbW92ZSB0aGUgJyMnIGF0IHRo ZSBiZWdpbm5pbmcgb2YgdGhlIGxpbmUuDQogIw0KLWZ0cAlzdHJlYW0JdGNw CW5vd2FpdAlyb290CS91c3IvbGliZXhlYy9mdHBkCWZ0cGQgLWwNCi1mdHAJ c3RyZWFtCXRjcDYJbm93YWl0CXJvb3QJL3Vzci9saWJleGVjL2Z0cGQJZnRw ZCAtbA0KLXRlbG5ldAlzdHJlYW0JdGNwCW5vd2FpdAlyb290CS91c3IvbGli ZXhlYy90ZWxuZXRkCXRlbG5ldGQNCi10ZWxuZXQJc3RyZWFtCXRjcDYJbm93 YWl0CXJvb3QJL3Vzci9saWJleGVjL3RlbG5ldGQJdGVsbmV0ZA0KKyNmdHAJ c3RyZWFtCXRjcAlub3dhaXQJcm9vdAkvdXNyL2xpYmV4ZWMvZnRwZAlmdHBk IC1sDQorI2Z0cAlzdHJlYW0JdGNwNglub3dhaXQJcm9vdAkvdXNyL2xpYmV4 ZWMvZnRwZAlmdHBkIC1sDQorI3RlbG5ldAlzdHJlYW0JdGNwCW5vd2FpdAly b290CS91c3IvbGliZXhlYy90ZWxuZXRkCXRlbG5ldGQNCisjdGVsbmV0CXN0 cmVhbQl0Y3A2CW5vd2FpdAlyb290CS91c3IvbGliZXhlYy90ZWxuZXRkCXRl bG5ldGQNCiAjc2hlbGwJc3RyZWFtCXRjcAlub3dhaXQJcm9vdAkvdXNyL2xp YmV4ZWMvcnNoZAlyc2hkDQogI3NoZWxsCXN0cmVhbQl0Y3A2CW5vd2FpdAly b290CS91c3IvbGliZXhlYy9yc2hkCXJzaGQNCiAjbG9naW4Jc3RyZWFtCXRj cAlub3dhaXQJcm9vdAkvdXNyL2xpYmV4ZWMvcmxvZ2luZAlybG9naW5kDQpA QCAtMTcsMTAgKzE5LDEzIEBADQogI2V4ZWMJc3RyZWFtCXRjcAlub3dhaXQJ cm9vdAkvdXNyL2xpYmV4ZWMvcmV4ZWNkCXJleGVjZA0KICN1dWNwZAlzdHJl YW0JdGNwCW5vd2FpdAlyb290CS91c3IvbGliZXhlYy91dWNwZAl1dWNwZA0K ICNubnRwCXN0cmVhbQl0Y3AJbm93YWl0CXVzZW5ldAkvdXNyL2xpYmV4ZWMv bm50cGQJbm50cGQNCisjDQogIyBydW4gY29tc2F0IGFzIHJvb3QgdG8gYmUg YWJsZSB0byBwcmludCBwYXJ0aWFsIG1haWxib3ggY29udGVudHMgdy8gYmlm ZiwNCiAjIG9yIHVzZSB0aGUgc2FmZXIgdHR5OnR0eSB0byBqdXN0IHByaW50 IHRoYXQgbmV3IG1haWwgaGFzIGJlZW4gcmVjZWl2ZWQuDQotY29tc2F0CWRn cmFtCXVkcAl3YWl0CXR0eTp0dHkJL3Vzci9saWJleGVjL2NvbXNhdAljb21z YXQNCi1udGFsawlkZ3JhbQl1ZHAJd2FpdAl0dHk6dHR5CS91c3IvbGliZXhl Yy9udGFsa2QJbnRhbGtkDQorI2NvbXNhdAlkZ3JhbQl1ZHAJd2FpdAl0dHk6 dHR5CS91c3IvbGliZXhlYy9jb21zYXQJY29tc2F0DQorIw0KKyMgbnRhbGsg aXMgcmVxdWlyZWQgZm9yIHRoZSAndGFsaycgdXRpbGl0eSB0byB3b3JrIGNv cnJlY3RseQ0KKyNudGFsawlkZ3JhbQl1ZHAJd2FpdAl0dHk6dHR5CS91c3Iv bGliZXhlYy9udGFsa2QJbnRhbGtkDQogI3RmdHAJZGdyYW0JdWRwCXdhaXQJ bm9ib2R5CS91c3IvbGliZXhlYy90ZnRwZAl0ZnRwZCAvdGZ0cGJvb3QNCiAj Ym9vdHBzCWRncmFtCXVkcAl3YWl0CXJvb3QJL3Vzci9saWJleGVjL2Jvb3Rw ZAlib290cGQNCiAjDQo= --0-909119149-996637714=:54921-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 20:56: 5 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists.blarg.net (lists.blarg.net [206.124.128.17]) by hub.freebsd.org (Postfix) with ESMTP id A005437B403; Tue, 31 Jul 2001 20:55:34 -0700 (PDT) (envelope-from coffee@blarg.net) Received: from thig.blarg.net (thig.blarg.net [206.124.128.18]) by lists.blarg.net (Postfix) with ESMTP id 95489BCFC; Tue, 31 Jul 2001 20:55:11 -0700 (PDT) Received: from paco.blarg.net (paco.fatburrito.com [206.124.139.210]) by thig.blarg.net (8.9.3/8.9.3) with ESMTP id UAA21452; Tue, 31 Jul 2001 20:55:10 -0700 Message-Id: <5.1.0.14.0.20010731205702.00b183d0@mail.blarg.net> X-Sender: coffee@mail.blarg.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Jul 2001 20:58:00 -0700 To: Robert Watson , arch@FreeBSD.ORG From: "Derek C." Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Cc: stable@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, I am a fairly typical uninformed/idiot user, who is getting better every day, and I say the documentation is great, and the patch is a great idea. Derek At 08:48 PM 7/31/2001, Robert Watson wrote: >One of the observations that has been made fairly frequently to me is that >the current default inetd.conf puts many FreeBSD users at risk >unnecessarily, as many of them have moved to using SSH for remote access >needs. In particular in light of the recent ftpd and telnetd security >bugs, it seems like 4.4-RELEASE would be a good time to move to a more >conservative default of having both of these services disabled in the base >install, as both NetBSD and OpenBSD have moved to doing. > >The attached patch modifies inetd.conf to disable all services by default, >and expands on the comments in the header so as to be more instructive >concerning enabling and disabling services. It also modifies sysinstall >such that enabling inetd in the post-install configuration describes inetd >more than previously, mentions the risks, and then also presents the >opportunity to edit inetd.conf if inetd is enabled. Also, during the >normal install, the user is automatically prompted to enable or disable >inetd in much the same style as the NFS server. > >I believe this addresses concerns about enabling remote telnetd login >during install, which was one of the primary reasons to leave it enabled >by default. Note that this does not disable the installation of the >necessary software, merely disable it by default, so users can enable them >again easily by modifying inetd.conf, either with the help of sysinstall, >or manually. These changes select a safe default, but hopefully offer the >necessary flexibility for users needing the services specifically. > >I've gotten reviews on content and configurability from Warner Losh, Chris >Costello, and Jake Burkholder. Assuming no one seriously objects (or only >a small number of people do), I'll commit to -CURRENT within a day or so, >and MFC (pending RE approval) shortly there-after. Clearly, it would be >desirable to have this in as many of the release snapshots as possible. > >Here, for the patch-impaired, are a couple of excerpts from sysinstall, so >that language can be evaluated for readability and comprehensibility for >more novice users: > >x x [ ] Gateway This machine will route packets between interfaces >x x [X] inetd This machine wants to run the inet daemon >x x [X] NFS client This machine will be an NFS client > >x xlqqqqqqqqqqqqqqqqqqqqq User Confirmation Requested >qqqqqqqqqqqqqqqqqqqqqkx x >x xx The Internet Super Server (inetd) allows a number of simple Internet xx x >x xx services to be enabled, including finger, ftp, and telnetd. Enabling >xx x >x xx these services may increase risk of security problems by increasing xx x >x xx the exposure of your system. xx x >x xx xx x >x xx With this in mind, do you wish to enable inetd? >xx x x xx >xx x x >xtqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqux x >x xx [ Yes ] No xx x > > >x xlqqqqqqqqqqqqqqqqqqqqq User Confirmation Requested >qqqqqqqqqqqqqqqqqqqqqkx x >x xx Inetd relies on its configuration file, /etc/inetd.conf, to determine >xx x >x xx which Internet services will be available. The default FreeBSD xx x >x xx inetd.conf leaves all services disabled by default, so they must be xx x >x xx specifically enabled in the configuration file before they will xx x >x xx function, even once inetd is enabled. xx x >x xx xx x >x xx Select [Yes] now to invoke an editor on /etc/inetd.conf, or [No] to xx x >x xx use the current settings. xx x >x xx xx x >x >xtqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqux x > >? usr.sbin/sysinstall/keymap.h >? usr.sbin/sysinstall/rtermcap >? usr.sbin/sysinstall/makedevs.c >? usr.sbin/sysinstall/sysinstall >? usr.sbin/sysinstall/sysinstall.8.gz >Index: usr.sbin/sysinstall/config.c >=================================================================== >RCS file: /home/ncvs/src/usr.sbin/sysinstall/config.c,v >retrieving revision 1.183 >diff -u -r1.183 config.c >--- usr.sbin/sysinstall/config.c 2001/07/17 04:09:50 1.183 >+++ usr.sbin/sysinstall/config.c 2001/08/01 03:34:59 >@@ -955,6 +955,38 @@ > } > > int >+configInetd(dialogMenuItem *self) >+{ >+ char cmd[256]; >+ >+ WINDOW *w = savescr(); >+ >+ if (msgYesNo("The Internet Super Server (inetd) allows a number of >simple Internet\n" >+ "services to be enabled, including finger, ftp, and >telnetd. Enabling\n" >+ "these services may increase risk of security problems >by increasing\n" >+ "the exposure of your system.\n\n" >+ "With this in mind, do you wish to enable inetd?\n")) { >+ variable_set2("inetd_enable", "NO", 1); >+ } else { >+ /* If inetd is enabled, we'll need an inetd.conf */ >+ >+ if (!msgYesNo("inetd(8) relies on its configuration file, >/etc/inetd.conf, to determine\n" >+ "which Internet services will be available. The >default FreeBSD\n" >+ "inetd.conf(5) leaves all services disabled by >default, so they must be\n" >+ "specifically enabled in the configuration file before >they will\n" >+ "function, even once inetd(8) is enabled.\n\n" >+ "Select [Yes] now to invoke an editor on >/etc/inetd.conf, or [No] to\n" >+ "use the current settings.\n")) { >+ sprintf(cmd, "%s /etc/inetd.conf", variable_get(VAR_EDITOR)); >+ dialog_clear(); >+ systemExecute(cmd); >+ variable_set2("inetd_enable", "YES", 1); >+ } >+ } >+ restorescr(w); >+} >+ >+int > configNFSServer(dialogMenuItem *self) > { > char cmd[256]; >Index: usr.sbin/sysinstall/dispatch.c >=================================================================== >RCS file: /home/ncvs/src/usr.sbin/sysinstall/dispatch.c,v >retrieving revision 1.38 >diff -u -r1.38 dispatch.c >--- usr.sbin/sysinstall/dispatch.c 2001/07/05 09:51:09 1.38 >+++ usr.sbin/sysinstall/dispatch.c 2001/08/01 03:35:05 >@@ -52,6 +52,7 @@ > } resWords[] = { > { "configAnonFTP", configAnonFTP }, > { "configRouter", configRouter }, >+ { "configInetd", configInetd }, > { "configNFSServer", configNFSServer }, > { "configNTP", configNTP }, > { "configPCNFSD", configPCNFSD }, >Index: usr.sbin/sysinstall/install.c >=================================================================== >RCS file: /home/ncvs/src/usr.sbin/sysinstall/install.c,v >retrieving revision 1.300 >diff -u -r1.300 install.c >--- usr.sbin/sysinstall/install.c 2001/07/17 04:09:50 1.300 >+++ usr.sbin/sysinstall/install.c 2001/08/01 03:35:18 >@@ -573,6 +573,10 @@ > variable_set2("gateway_enable", "YES", 1); > > dialog_clear_norefresh(); >+ if (!msgNoYes("Do you want to configure inetd and simple internet >services?")) >+ configInetd(self); >+ >+ dialog_clear_norefresh(); > if (!msgNoYes("Do you want to have anonymous FTP access to this > machine?")) > configAnonFTP(self); > >Index: usr.sbin/sysinstall/menus.c >=================================================================== >RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v >retrieving revision 1.310 >diff -u -r1.310 menus.c >--- usr.sbin/sysinstall/menus.c 2001/07/31 21:30:57 1.310 >+++ usr.sbin/sysinstall/menus.c 2001/08/01 03:35:53 >@@ -235,6 +235,7 @@ > { " FTP sites", "The FTP mirror site > listing.", NULL, dmenuSubmenu, NULL, &MenuMediaFTP }, > { " Gateway", "Set flag to route packets between > interfaces.", dmenuVarCheck, dmenuToggleVariable, NULL, "gateway=YES" }, > { " HTML Docs", "The HTML documentation > menu", NULL, docBrowser }, >+ { " inetd Configuration", "Configure inetd and simple >internet services.", dmenuVarCheck, configInetd, NULL, >"inetd_enable=YES" }, > { " Install, Standard", "A standard system > installation.", NULL, installStandard }, > { " Install, Express", "An express system > installation.", NULL, installExpress }, > { " Install, Custom", "The custom installation > menu", NULL, dmenuSubmenu, NULL, &MenuInstallCustom }, >@@ -1332,7 +1333,7 @@ > { " Gateway", "This machine will route packets between interfaces", > dmenuVarCheck, dmenuToggleVariable, NULL, "gateway_enable=YES" }, > { " inetd", "This machine wants to run the inet daemon", >- dmenuVarCheck, dmenuToggleVariable, NULL, "inetd_enable=YES" }, >+ dmenuVarCheck, configInetd, NULL, "inetd_enable=YES" }, > { " NFS client", "This machine will be an NFS client", > dmenuVarCheck, dmenuToggleVariable, NULL, "nfs_client_enable=YES" }, > { " NFS server", "This machine will be an NFS server", >Index: usr.sbin/sysinstall/sysinstall.h >=================================================================== >RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v >retrieving revision 1.209 >diff -u -r1.209 sysinstall.h >--- usr.sbin/sysinstall/sysinstall.h 2001/07/17 04:09:50 1.209 >+++ usr.sbin/sysinstall/sysinstall.h 2001/08/01 03:36:06 >@@ -447,6 +447,7 @@ > extern int configXDesktop(dialogMenuItem *self); > extern int configRouter(dialogMenuItem *self); > extern int configPCNFSD(dialogMenuItem *self); >+extern int configInetd(dialogMenuItem *self); > extern int configNFSServer(dialogMenuItem *self); > extern int configWriteRC_conf(dialogMenuItem *self); > extern int configSecurityProfile(dialogMenuItem *self); >Index: etc/inetd.conf >=================================================================== >RCS file: /home/ncvs/src/etc/inetd.conf,v >retrieving revision 1.48 >diff -u -r1.48 inetd.conf >--- etc/inetd.conf 2001/03/30 10:25:40 1.48 >+++ etc/inetd.conf 2001/08/01 03:36:10 >@@ -2,12 +2,14 @@ > # > # Internet server configuration database > # >-# define *both* IPv4 and IPv6 entries for dual-stack support. >+# Define *both* IPv4 and IPv6 entries for dual-stack support. >+# To disable a service, comment it out by prefixing the line with '#'. >+# To enable a service, remove the '#' at the beginning of the line. > # >-ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l >-ftp stream tcp6 nowait root /usr/libexec/ftpd ftpd -l >-telnet stream tcp nowait root /usr/libexec/telnetd telnetd >-telnet stream tcp6 nowait root /usr/libexec/telnetd telnetd >+#ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l >+#ftp stream tcp6 nowait root /usr/libexec/ftpd ftpd -l >+#telnet stream tcp nowait root /usr/libexec/telnetd >telnetd >+#telnet stream tcp6 nowait root /usr/libexec/telnetd >telnetd > #shell stream tcp nowait root /usr/libexec/rshd rshd > #shell stream tcp6 nowait root /usr/libexec/rshd rshd > #login stream tcp nowait root /usr/libexec/rlogind rlogind >@@ -17,10 +19,13 @@ > #exec stream tcp nowait root /usr/libexec/rexecd rexecd > #uucpd stream tcp nowait root /usr/libexec/uucpd uucpd > #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd >+# > # run comsat as root to be able to print partial mailbox contents w/ biff, > # or use the safer tty:tty to just print that new mail has been received. >-comsat dgram udp wait tty:tty /usr/libexec/comsat comsat >-ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd >+#comsat dgram udp wait tty:tty /usr/libexec/comsat comsat >+# >+# ntalk is required for the 'talk' utility to work correctly >+#ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd > #tftp dgram udp wait nobody /usr/libexec/tftpd tftpd > /tftpboot > #bootps dgram udp wait root /usr/libexec/bootpd > bootpd > # To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 20:58:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id A84EF37B405 for ; Tue, 31 Jul 2001 20:58:13 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f713vvf55382; Tue, 31 Jul 2001 23:58:01 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 31 Jul 2001 23:57:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Karels Cc: arch@freebsd.org Subject: Re: syscall numbering In-Reply-To: <200107120234.f6C2YLC14835@redrock.eng.bsdi.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 Mike, Sorry about the delay in responding, I went off and got married and am only just digging out on the e-mail front :-). With regards to your proposal--this seems to be a generally good idea to me, as it would certainly improve the opportunities for compatible ABIs in the future. With regards to your specific proposed ranges--the ranges you've laid out seem generally fine to me. I'm responsible for about the last twenty or thirty system calls added to FreeBSD as part of the TrustedBSD work, and there are a number of further components added that will introduce more API calls. This suggests that the range 375-399 is too small for future FreeBSD work. If you're willing to allocate an additional higher chunk, and/or adjust the BSD/OS customer range, that would probably meet all of our needs. I'd also be quite willing to add necessary comments to our syscalls.master indicating range allocations, and pointing at you as the person allocating ranges for BSD-style operating systems. Given that there is a moderate chance of other BSD platforms picking up system calls from each other (as you describe), would your plan generally be for the platform introducing a new call to allocate a number from their range, and to encourage other platforms to use the same number if the ABI and API are identical? I.e., if OpenBSD were to pick up ACL/EA calls (something they've expressed interest in doing), I would ask them to use the FreeBSD numbers if identical, their own otherwise? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Wed, 11 Jul 2001, Mike Karels wrote: > I am sending this message at Jordan's suggestion after corresponding > with him. The subject is coordination of system call numbers. > > As some of you probably know, the syscall.master file in Berkeley BSD > releases had some ranges reserved for "vendors". Unfortunately, both > BSDI (now Wind River) and their customers were "vendors", and there > have been some collisions. I would now like to reserve another range > of system calls for those customers. This would not be of interest > to FreeBSD, except that BSD/OS also picks up system calls from FreeBSD, > and FreeBSD has a number of BSD/OS-compatible calls as well as other > entries for compatibility with NetBSD and/or OpenBSD. In theory, it > would be nice to coordinate all of this globally, but I understand > that NetBSD doesn't even have consistent numbering across all of their > platforms. I'm sure we won't be able to prevent conflicts completely, > but it is convenient that we can mostly use a single system call table. > > For now, I'm tempted to reserve 400-449 for BSD/OS customers. FreeBSD > seems to be using 300 up, to 374 currently, and BSD/OS calls are all > below that. Does this sound plausible? Does that leave enough for > FreeBSD expansion? > > I'm happy to consider other suggestions, including some larger level > of coordination. Feel free to contact me directly, off the list. > > Mike > > 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 Tue Jul 31 21:32:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from assaris.sics.se (dhcp102.iss.kth.se [130.237.7.102]) by hub.freebsd.org (Postfix) with ESMTP id 3CFFB37B401 for ; Tue, 31 Jul 2001 21:32:44 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id GAA80901; Wed, 1 Aug 2001 06:32:40 +0200 (CEST) (envelope-from assar) To: arch@FreeBSD.ORG Subject: Re: Making glob(3) portable (was Re: Importing lukemftpd) References: From: Assar Westerlund Date: 01 Aug 2001 06:32:40 +0200 In-Reply-To: Mike Heffner's message of "Fri, 27 Jul 2001 22:25:47 -0400 (EDT)" Message-ID: <5lofq0pfh3.fsf@assaris.sics.se> Lines: 7 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 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 Mike Heffer has committed this to current. Should this be MFC-ed (before 4.4?). I would like it to be, but the only reason for not doing so is that it's impossible to do so in a totally backwards compatible way and the APIs are not supposed to be changed in RELENG_4. Thoughts? /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 21:43:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 76A6437B403; Tue, 31 Jul 2001 21:43:53 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA25617; Tue, 31 Jul 2001 22:43:47 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id WAA17641; Tue, 31 Jul 2001 22:43:46 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15207.35074.452967.466218@nomad.yogotech.com> Date: Tue, 31 Jul 2001 22:43:46 -0600 (MDT) To: Robert Watson Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > One of the observations that has been made fairly frequently to me is that > the current default inetd.conf puts many FreeBSD users at risk > unnecessarily, as many of them have moved to using SSH for remote access > needs. In particular in light of the recent ftpd and telnetd security > bugs, it seems like 4.4-RELEASE would be a good time to move to a more > conservative default of having both of these services disabled in the base > install, as both NetBSD and OpenBSD have moved to doing. FWIW, as one of the folks who argued against this in the past (function before security), the recent telnet remote access bugs have (finally?) convinced me that all un-necessary services should be disabled. Even 'local/innocent' adminstrators can get themselves in trouble real fast if another bad bug like the telnet one is found/exploited. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 21:45:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 2432E37B401; Tue, 31 Jul 2001 21:45:32 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA25667; Tue, 31 Jul 2001 22:45:30 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id WAA17669; Tue, 31 Jul 2001 22:45:30 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15207.35178.61523.131897@nomad.yogotech.com> Date: Tue, 31 Jul 2001 22:45:30 -0600 (MDT) To: Robert Watson Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Disabling portmapper (was Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf) In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > One of the observations that has been made fairly frequently to me is that > the current default inetd.conf puts many FreeBSD users at risk > unnecessarily, as many of them have moved to using SSH for remote access > needs. In particular in light of the recent ftpd and telnetd security > bugs, it seems like 4.4-RELEASE would be a good time to move to a more > conservative default of having both of these services disabled in the base > install, as both NetBSD and OpenBSD have moved to doing. In the same vein, shouldn't we also have the portmapper 'disabled' out of the box by default? I know we haven't (yet) had any remote exploits like Linux, but it may only be a matter of time. Plus, the crap filling up the logs could be argued as a type of DoS. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 21:55:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhost.xrxgsn.com (unknown [216.42.106.144]) by hub.freebsd.org (Postfix) with ESMTP id 79D2B37B405; Tue, 31 Jul 2001 21:55:39 -0700 (PDT) (envelope-from mike.porter@xrxgsn.com) Received: from laptop (1Cust201.tnt3.salt-lake-city.ut.da.uu.net [63.11.215.201]) by mailhost.xrxgsn.com (8.9.3/8.9.3) with SMTP id AAA12776; Wed, 1 Aug 2001 00:47:57 -0400 (EDT) Message-ID: <00e501c11a45$f2165520$0300a8c0@laptop> From: "Mike Porter" To: "Robert Watson" , , "Derek C." Cc: Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Date: Tue, 31 Jul 2001 22:53:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Somehow I missed the original of this.... -----Original Message----- From: Derek C. To: Robert Watson ; arch@FreeBSD.ORG Cc: stable@FreeBSD.ORG Date: Tuesday, July 31, 2001 9:56 PM Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf >Well, I am a fairly typical uninformed/idiot user, who is getting better >every day, and I say the documentation is great, and the patch is a great idea. > >Derek > >At 08:48 PM 7/31/2001, Robert Watson wrote: > [snip the first introductory bits] > >>needs. In particular in light of the recent ftpd and telnetd security >>bugs, it seems like 4.4-RELEASE would be a good time to move to a more >>conservative default of having both of these services disabled in the base >>install, as both NetBSD and OpenBSD have moved to doing. >> Seems like a pretty good idea to me; although it seems to me that perhaps disabling SSH by default is overkill; certainly I think that it is a good idea to disable telnet by default...nearly eveyone who NEEDS it should be able to add it easily enough...however... [...] >>concerning enabling and disabling services. It also modifies sysinstall >>such that enabling inetd in the post-install configuration describes inetd >>more than previously, mentions the risks, and then also presents the >>opportunity to edit inetd.conf if inetd is enabled. Also, during the >>normal install, the user is automatically prompted to enable or disable >>inetd in much the same style as the NFS server. >> [snip the details] It also seems to me that a better solution than just editing inetd.conf (especially for novice users) would be a sub-menu, similar to the one used to enable inetd and NFS and the like, allowing a user to check which services are desired. Of course, I am not familiar with sysinstall internals, so I don't know how much work this really entails, its just an idea. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jul 31 22:29:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lists.blarg.net (lists.blarg.net [206.124.128.17]) by hub.freebsd.org (Postfix) with ESMTP id 4190437B403; Tue, 31 Jul 2001 22:29:14 -0700 (PDT) (envelope-from coffee@blarg.net) Received: from thig.blarg.net (thig.blarg.net [206.124.128.18]) by lists.blarg.net (Postfix) with ESMTP id DEC50BCF2; Tue, 31 Jul 2001 22:29:13 -0700 (PDT) Received: from paco.blarg.net (trilluser@paco.fatburrito.com [206.124.139.210]) by thig.blarg.net (8.9.3/8.9.3) with ESMTP id WAA00860; Tue, 31 Jul 2001 22:29:13 -0700 Message-Id: <5.1.0.14.0.20010731223153.03b3e370@mail.blarg.net> X-Sender: coffee@mail.blarg.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Jul 2001 22:32:33 -0700 To: "Mike Porter" , "Robert Watson" , From: "Derek C." Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Cc: In-Reply-To: <00e501c11a45$f2165520$0300a8c0@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG So did I... And nobody said anything about disabling SSH... the wording of the email confused me at first, but the services in question were FTP and Telnetd. Derek At 09:53 PM 7/31/2001, Mike Porter wrote: >Somehow I missed the original of this.... > >-----Original Message----- >From: Derek C. >To: Robert Watson ; arch@FreeBSD.ORG >Cc: stable@FreeBSD.ORG >Date: Tuesday, July 31, 2001 9:56 PM >Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to >edit , inetd.conf > > > >Well, I am a fairly typical uninformed/idiot user, who is getting better > >every day, and I say the documentation is great, and the patch is a great >idea. > > > >Derek > > > >At 08:48 PM 7/31/2001, Robert Watson wrote: > > >[snip the first introductory bits] > > > >>needs. In particular in light of the recent ftpd and telnetd security > >>bugs, it seems like 4.4-RELEASE would be a good time to move to a more > >>conservative default of having both of these services disabled in the base > >>install, as both NetBSD and OpenBSD have moved to doing. > >> >Seems like a pretty good idea to me; although it seems to me that perhaps >disabling SSH by default is overkill; certainly I think that it is a good >idea to disable telnet by default...nearly eveyone who NEEDS it should be >able to add it easily enough...however... > > >[...] > >>concerning enabling and disabling services. It also modifies sysinstall > >>such that enabling inetd in the post-install configuration describes inetd > >>more than previously, mentions the risks, and then also presents the > >>opportunity to edit inetd.conf if inetd is enabled. Also, during the > >>normal install, the user is automatically prompted to enable or disable > >>inetd in much the same style as the NFS server. > >> >[snip the details] >It also seems to me that a better solution than just editing inetd.conf >(especially for novice users) would be a sub-menu, similar to the one used >to enable inetd and NFS and the like, allowing a user to check which >services are desired. Of course, I am not familiar with sysinstall >internals, so I don't know how much work this really entails, its just an >idea. > >mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 0:13:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id B77D437B40A for ; Wed, 1 Aug 2001 00:13:23 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.104.188.Dial1.SanJose1.Level3.net [209.244.104.188]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA16292; Wed, 1 Aug 2001 00:13:21 -0700 (PDT) Message-ID: <3B67AC38.26E8382D@mindspring.com> Date: Wed, 01 Aug 2001 00:14:00 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: threads comment 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: > (so far I have replaced about 4000 instances of struct proc with struct > thread (mostly by hand)) Do you need help installing cscope?!? -- 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 1 0:27:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 8BF2437B405 for ; Wed, 1 Aug 2001 00:27:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.104.188.Dial1.SanJose1.Level3.net [209.244.104.188]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA12989; Wed, 1 Aug 2001 00:26:46 -0700 (PDT) Message-ID: <3B67AF5E.A576153B@mindspring.com> Date: Wed, 01 Aug 2001 00:27:26 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: thread scheduling question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Does anyone have any views on what happens when > the posix scheduling calls are applied against a multithreaded > process? > in particular against one with several KSEGRPs? > are the multiple KSEs and KSEGRPs visible to the outside at all? No need to reply to this: I sent Julian the POSIX manual pages for the scheduling functions that deal with system vs. process scoping. -- 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 1 0:46:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (oringworld.nanolink.com [195.24.48.39]) by hub.freebsd.org (Postfix) with SMTP id A081137B406 for ; Wed, 1 Aug 2001 00:46:42 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 53288 invoked by uid 1000); 1 Aug 2001 07:45:41 -0000 Date: Wed, 1 Aug 2001 10:45:41 +0300 From: Peter Pentchev To: Assar Westerlund Cc: arch@FreeBSD.ORG Subject: Re: Making glob(3) portable (was Re: Importing lukemftpd) Message-ID: <20010801104541.A47972@ringworld.oblivion.bg> Mail-Followup-To: Assar Westerlund , arch@FreeBSD.ORG References: <5lofq0pfh3.fsf@assaris.sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5lofq0pfh3.fsf@assaris.sics.se>; from assar@FreeBSD.ORG on Wed, Aug 01, 2001 at 06:32:40AM +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 01, 2001 at 06:32:40AM +0200, Assar Westerlund wrote: > Mike Heffer has committed this to current. Should this be MFC-ed > (before 4.4?). I would like it to be, but the only reason for not > doing so is that it's impossible to do so in a totally backwards > compatible way and the APIs are not supposed to be changed in > RELENG_4. Thoughts? ISTR this having been discussed before, and the general agreement being that it has not lived in RELENG_4 long enough for people to really start using it (outside the base system). Okay, so it has been in 4.3-RELEASE, but still, I think in this particular case it would be better to try for compatibility.. G'luck, Peter -- I am jealous of the first word in this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 0:49:22 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id CBA1F37B406 for ; Wed, 1 Aug 2001 00:49:20 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id CAA38600; Wed, 1 Aug 2001 02:44:37 -0700 (PDT) Message-ID: <3B67AFCB.5F882245@elischer.org> Date: Wed, 01 Aug 2001 00:29:15 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: tlambert2@mindspring.com Cc: arch@freebsd.org Subject: Re: threads comment References: <3B67AC38.26E8382D@mindspring.com> Content-Type: text/plain; charset=iso-8859-2 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 Terry Lambert wrote: > > Julian Elischer wrote: > > (so far I have replaced about 4000 instances of struct proc with struct > > thread (mostly by hand)) > > Do you need help installing cscope?!? > > -- Terry It's installed but it's so cryptic that I couldn't figure it out and gave up.. anyhow it's not just a find and replace.. I need to change the variable names and types, but only sometimes.. sometimes what is needed REALLY IS still the proc struct... -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 1:20:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id DA74637B405 for ; Wed, 1 Aug 2001 01:20:08 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.244.104.188.Dial1.SanJose1.Level3.net [209.244.104.188]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA10119; Wed, 1 Aug 2001 01:20:01 -0700 (PDT) Message-ID: <3B67BBD9.AD0593A7@mindspring.com> Date: Wed, 01 Aug 2001 01:20:41 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: arch@freebsd.org Subject: Re: threads comment References: <3B67AC38.26E8382D@mindspring.com> <3B67AFCB.5F882245@elischer.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 Julian Elischer wrote: > > Do you need help installing cscope?!? > > It's installed but it's so cryptic that I couldn't figure it out > and gave up.. ?!? > anyhow it's not just a find and replace.. > I need to change the variable names and types, but only sometimes.. > sometimes what is needed REALLY IS still the proc struct... But if it's _mostly_ everywhere, you'd be better off changing it all, and then changing back the ones that need it, especially considering your proc/thread naming comment. -- 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 1 6: 0:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhost.xrxgsn.com (unknown [216.42.106.144]) by hub.freebsd.org (Postfix) with ESMTP id 9286C37B401; Wed, 1 Aug 2001 06:00:27 -0700 (PDT) (envelope-from mike.porter@xrxgsn.com) Received: from laptop (1Cust140.tnt1.salt-lake-city.ut.da.uu.net [63.11.213.140]) by mailhost.xrxgsn.com (8.9.3/8.9.3) with SMTP id IAA23880; Wed, 1 Aug 2001 08:52:45 -0400 (EDT) Message-ID: <000601c11a89$ab31e4a0$0300a8c0@laptop> From: "Mike Porter" To: "Robert Watson" , , "Derek C." Cc: Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Date: Wed, 1 Aug 2001 06:58:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -----Original Message----- From: Derek C. To: Mike Porter ; Robert Watson ; arch@FreeBSD.ORG Cc: stable@FreeBSD.ORG Date: Tuesday, July 31, 2001 11:22 PM Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf >So did I... > >And nobody said anything about disabling SSH... the wording of the email >confused me at first, but the services in question were FTP and Telnetd. > errm....my bad. That's what I get for staying up past 11 to reply to messages. somehow I saw ssh in there. ftpd makes *much* more sense <(}: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 6: 1:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2710137B401; Wed, 1 Aug 2001 06:01:46 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f71D1bf59358; Wed, 1 Aug 2001 09:01:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 1 Aug 2001 09:01:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jeff Palmer Cc: stable@FreeBSD.org, arch@FreeBSD.org Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf In-Reply-To: <20010801010958.X9176-100000@jeff.isni.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 1 Aug 2001, Jeff Palmer wrote: > Pardon my newbieness.. > > Doesn't the 4.x branch have a dialog box at install time asking you what > security model you'd prefer.. if you select high security, 'inetd' > itself is even disabed.. (Your own post showed the dialog) The problem, in my view, with the current "security profile" behavior is that it has a lot of baggage: in order to disable inetd, you have to accept securelevels, for example. Likewise, selecting the default leaves you with settings that, in the case of the recent telnet and ftp vulnerabilities, left you vulnerable to remote exploits out of the box. Because many new users select the defaults during the install, assuming they're be moderately "right", our selection of defaults should be relatively conservative so as to protect those users. An appropriate security stance is one that consists of a set of choices made by an administrator who is aware of the ramifications of the choice: they balance knowledge about their environment, both requirements and risks, in selecting configuration options. For new users, it's important that we choose settings that mitigate risk, allowing them to adopt additional risk when they determine it is appropriate. I.e., if they don't know what telnet is, we have no business turning it on, especially if it's going to get them rooted. > In my opinion, security is up to each individual administrator. They > should enable and disable all services based on their own needs. I > rarely see a machine with a competent admin, running a nearly 100% > default install. Absolutely: the majority of the attached patch was a modification to sysinstall to make configuring services *more* accessible, not less. It provides an improved description of the ramifications of enabling inetd, and offers the opportunity to configure which services are enabled earlier. It selects a more conservative default (all off), and permits the administrator to selectively enable services that they believe they need, rather than asserting they need services that (to be honest) are becoming less and less useful over time. > Also, FreeBSD has been awesome at fixing security holes within minutes > or hours (and in extreme cases, a day or two). So the likelyhood of any > daemon being exploitable within the first 15 minutes of a fresh install > are pretty much zero. Generally, we have a pretty good track record with fixing security problems, once we're informed of them. However, the reality is that the application of security patches is something that is both admin-"hard", and admin-"time consuming". Conservative defaults allow us to protect those administrators who weren't using the services anyway, and make administrators who do use the service more aware of what services are enabled in the system. This will make it easier for them to understand what security fixes they require, and reduce the number of occurences of "I'm vulnerable by virtue of a service I don't use, and didn't realize was on by default". > Therefore, it doesn't matter what services are enabled/disabled in > inetd.conf as most administrators edit that file within a few minutes of > a default install anyway. The current model, you edit it to close some > ports. in the model you suggest, you edit it to open some ports. > Either way, it takes an entire 20 seconds (ok, 1 minute for the 'vi > newbie') to edit the file and HUP inetd. If it doesn't matter what services are enabled or disabled from your perspective, selecting a default that disables provides the security benefits for less knowledgeable users, without costing you anything. If anything, it may make your life easier by prompting you with this opportunity during install. You believe that the average user's first act on a system is to disable services they don't need--I suspect that instead, it's to install additional services they know they do need, and to leave other things enabled because they're already on, and harmless, or to leave them on because they don't realize they're enabled. > I'd prefer to see people spending their time auditing the code, so we > can be even more proactive about exploits and vulnerabilities than we > currently are, rather than wasting time talking about services enabled > in inetd. I'm sorry you feel that way: from a practical perspective, there are a number of components to making an operating system secure. This includes both programmatic tasks concerning correctness, development of security models, and also making sure the system is simple to both administer and secure. When evaluating the security of a system, a very large part of the work includes evaluating its configuration: helping administrators select the right configuration for them, and encouraging sensible configuration, plays an important role in making proper configuration possible. In practice, the changes here took about half an hour to develop, and are an explicit response to the recent vulnerabilities: we need to not just fix the bugs, but also figure out how to reduce the impact of inevitable bugs. The reality is that the bugs will exist: a complete operating system is simply too complex to be bug-free. We need to respond to that reality by modifying our software: we should continue to target "least privilege" by reducing the privilege required for applications, reducing the impact of successful compromise, and by reducing the opportunity for compromise by disabling features and services that are unnecessary in the environment where the system is operating. The TrustedBSD project seeks to address the "least privilege" issue by reducing dependance on privilege (commits by Thomas Moestl in -CURRENT almost eliminate the need for setgid kmem binaries, which offer substantial), and increasing the degree to which privilege can be delegated in a fine-grained manner through improved operating system policy mechanisms (capabilities, ACLs, mandatory access control). Improved documentation and administrative security tools are an important, but less visible, part of that. > Just my two cents. Feel free to CC: me unless it's a flame. If it's a > flame.. please add [FLAME] to the subject for the procmail filters. :-) I hope you don't consider this a flame, rather, an honest disagreement on a contentious topic. My main concern in posting, or I would just have committed the patch outright, was to make sure that by making these changes, I wouldn't *break* functionality for a class of users. For example, simply disabling telnet in inetd.conf would have caused problems for those who use serial console configuration followed by telnet to log in, but on a trusted network segment. To disable telnet, we first need to offer the opportunity to re-enable it in the install. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 6: 6:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 98ABA37B401; Wed, 1 Aug 2001 06:06:06 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f71D5vf59389; Wed, 1 Aug 2001 09:05:57 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 1 Aug 2001 09:05:56 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Porter Cc: arch@FreeBSD.ORG, "Derek C." , stable@FreeBSD.ORG Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf In-Reply-To: <00e501c11a45$f2165520$0300a8c0@laptop> 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, 31 Jul 2001, Mike Porter wrote: > Seems like a pretty good idea to me; although it seems to me that > perhaps disabling SSH by default is overkill; certainly I think that it > is a good idea to disable telnet by default...nearly eveyone who NEEDS > it should be able to add it easily enough...however... Actually, although I'm happy with the current default of enabling SSH for now, if there isn't already a sysinstall post-install config twiddle for SSH, we should probably add one. To be honest, a "default all off" policy, with the opportunity to enable easily in sysinstall, might be better than turning SSH on by default. Maybe we'll do that for 5.0-RELEASE :-). > >>concerning enabling and disabling services. It also modifies sysinstall > >>such that enabling inetd in the post-install configuration describes inetd > >>more than previously, mentions the risks, and then also presents the > >>opportunity to edit inetd.conf if inetd is enabled. Also, during the > >>normal install, the user is automatically prompted to enable or disable > >>inetd in much the same style as the NFS server. > >> > [snip the details] > It also seems to me that a better solution than just editing inetd.conf > (especially for novice users) would be a sub-menu, similar to the one > used to enable inetd and NFS and the like, allowing a user to check > which services are desired. Of course, I am not familiar with > sysinstall internals, so I don't know how much work this really entails, > its just an idea. This is true--however, the inetd.conf file doesn't lend itself to automated management, as it doesn't have an inline "disabled" flag. To disable a service, you comment it out, making it hard for a program to distinguish things which are legitimately comments, and things that are disabled services. In the long term, it would probably make sense to develop some sort of administrative tool for inetd.conf: however, I concluded that doing so prior to 4.4-RELEASE was unlikely, and opted for this. In the future, if such a tool is developed, I'd be happy to slot it in instead of invoking EDITOR on it :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 6: 8:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B27E537B403; Wed, 1 Aug 2001 06:08:39 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f71D8Tf59418; Wed, 1 Aug 2001 09:08:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 1 Aug 2001 09:08:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Nate Williams Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf) In-Reply-To: <15207.35178.61523.131897@nomad.yogotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 31 Jul 2001, Nate Williams wrote: > > One of the observations that has been made fairly frequently to me is that > > the current default inetd.conf puts many FreeBSD users at risk > > unnecessarily, as many of them have moved to using SSH for remote access > > needs. In particular in light of the recent ftpd and telnetd security > > bugs, it seems like 4.4-RELEASE would be a good time to move to a more > > conservative default of having both of these services disabled in the base > > install, as both NetBSD and OpenBSD have moved to doing. > > In the same vein, shouldn't we also have the portmapper 'disabled' out > of the box by default? I know we haven't (yet) had any remote exploits > like Linux, but it may only be a matter of time. > > Plus, the crap filling up the logs could be argued as a type of DoS. I'd be tempted to disable the portmapper (rpcbind in -CURRENT) by default, allowing it to either be manually enabled, or enabled by virtue of dependencies (something we already support). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 7: 3:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 8EEE337B401; Wed, 1 Aug 2001 07:03:13 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA24913; Wed, 1 Aug 2001 07:03:13 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda24911; Wed Aug 1 07:02:55 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.4/8.9.1) id f71E2sc46085; Wed, 1 Aug 2001 07:02:54 -0700 (PDT) Received: from UNKNOWN(10.1.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdb46083; Wed Aug 1 07:02:14 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.4/8.9.1) id f71E2Dm30982; Wed, 1 Aug 2001 07:02:13 -0700 (PDT) Message-Id: <200108011402.f71E2Dm30982@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdo30977; Wed Aug 1 07:02:03 2001 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: Robert Watson Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf In-reply-to: Your message of "Tue, 31 Jul 2001 23:48:34 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Aug 2001 07:02:03 -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 In message , Robe rt Watson writes: > One of the observations that has been made fairly frequently to me is that > the current default inetd.conf puts many FreeBSD users at risk > unnecessarily, as many of them have moved to using SSH for remote access > needs. In particular in light of the recent ftpd and telnetd security > bugs, it seems like 4.4-RELEASE would be a good time to move to a more > conservative default of having both of these services disabled in the base > install, as both NetBSD and OpenBSD have moved to doing. I think that this is goodness. I have been an advocate of this (actually a less balanced approach -- of which I've seen the light and error of my thinking) for a long time. For that matter one of my biggest pet peeves about RH Linux is that by default it installs everything and enables everything. I think that the approach taken here is a balanced approach and is the correct approach. Services are not removed from the system entirely and can be enabled if needed. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 8:29:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bdr-xcon.matchlogic.com (mail.matchlogic.com [205.216.147.127]) by hub.freebsd.org (Postfix) with ESMTP id 2539C37B405; Wed, 1 Aug 2001 08:29:38 -0700 (PDT) (envelope-from crandall@matchlogic.com) Received: by mail.matchlogic.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 09:29:29 -0600 Message-ID: <5FE9B713CCCDD311A03400508B8B30130828F210@bdr-xcln.corp.matchlogic.com> From: Charles Randall To: 'Cy Schubert - ITSD Open Systems Group' , Robert Watson Cc: arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: RE: Patch to modify default inetd.conf, have sysinstall prompt t o edit , inetd.conf Date: Wed, 1 Aug 2001 09:27:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG FYI, Starting with RedHat 7.1, they now install a firewall and prompt the user for high/medium/low/none security policies. -Charles -----Original Message----- From: Cy Schubert - ITSD Open Systems Group [mailto:Cy.Schubert@uumail.gov.bc.ca] Sent: Wednesday, August 01, 2001 8:02 AM To: Robert Watson Cc: arch@FreeBSD.ORG; stable@FreeBSD.ORG Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf In message , Robe rt Watson writes: > One of the observations that has been made fairly frequently to me is that > the current default inetd.conf puts many FreeBSD users at risk > unnecessarily, as many of them have moved to using SSH for remote access > needs. In particular in light of the recent ftpd and telnetd security > bugs, it seems like 4.4-RELEASE would be a good time to move to a more > conservative default of having both of these services disabled in the base > install, as both NetBSD and OpenBSD have moved to doing. I think that this is goodness. I have been an advocate of this (actually a less balanced approach -- of which I've seen the light and error of my thinking) for a long time. For that matter one of my biggest pet peeves about RH Linux is that by default it installs everything and enables everything. I think that the approach taken here is a balanced approach and is the correct approach. Services are not removed from the system entirely and can be enabled if needed. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD Ministry of Management Services Province of BC 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 1 12:11:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id B014C37B401; Wed, 1 Aug 2001 12:11:28 -0700 (PDT) Date: Wed, 1 Aug 2001 12:11:28 -0700 From: David O'Brien To: Robert Watson Cc: Nate Williams , arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf) Message-ID: <20010801121128.B10275@hub.freebsd.org> Reply-To: obrien@freebsd.org References: <15207.35178.61523.131897@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@FreeBSD.ORG on Wed, Aug 01, 2001 at 09:08:29AM -0400 X-Operating-System: FreeBSD 4.3-STABLE 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 01, 2001 at 09:08:29AM -0400, Robert Watson wrote: > I'd be tempted to disable the portmapper (rpcbind in -CURRENT) by default, > allowing it to either be manually enabled, or enabled by virtue of > dependencies (something we already support). It already is disabled in -current since 2000-07-28 22:45:36 portmap_enable="NO" # Run the portmapper service (YES/NO). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 13:39:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id DCC7537B408; Wed, 1 Aug 2001 13:39:28 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f71KdSM81670; Wed, 1 Aug 2001 13:39:28 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 9850638FE; Wed, 1 Aug 2001 13:39:28 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: John Baldwin Cc: Warner Losh , arch@FreeBSD.ORG, Julian Elischer Subject: Re: Threads topics. In-Reply-To: Date: Wed, 01 Aug 2001 13:39:28 -0700 From: Peter Wemm Message-Id: <20010801203928.9850638FE@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 30-Jul-01 Warner Losh wrote: > > In message > > Julian Elischer writes: > >: Well, I'm quite a way into doing the KSE kernel. > > > > Julian, > > this sounds like cool stuff. How is it related to the > > perforce branches that jhb has setup? > > > > p4 branches > > Branch jhb_preemption 2001/07/19 'Fully preemptive kernel. ' > > Branch smpng 2001/07/17 'SMPng workspace ' > > > > He was talking about them in irc this morning. > > Peter is the one with all the evil perforce branches. Using a perforce for > things like KSE might be very beneficial indeed, but I'm just using the p4 > depot on freefall, I didn't set it up and don't admin it. :) I'd really like this to happen. The idea would be that you check all this in as you go and you can even co-opt others into helping you. That way we dont get a giant "SUPRISE!!" patch. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 14:43:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-80.dsl.lsan03.pacbell.net [63.207.60.80]) by hub.freebsd.org (Postfix) with ESMTP id 52C6A37B403; Wed, 1 Aug 2001 14:43:37 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 7921A66F38; Wed, 1 Aug 2001 14:43:36 -0700 (PDT) Date: Wed, 1 Aug 2001 14:43:36 -0700 From: Kris Kennaway To: David O'Brien Cc: Robert Watson , Nate Williams , arch@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf) Message-ID: <20010801144335.C82198@xor.obsecurity.org> References: <15207.35178.61523.131897@nomad.yogotech.com> <20010801121128.B10275@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010801121128.B10275@hub.freebsd.org>; from obrien@FreeBSD.ORG on Wed, Aug 01, 2001 at 12:11:28PM -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 --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 01, 2001 at 12:11:28PM -0700, David O'Brien wrote: > On Wed, Aug 01, 2001 at 09:08:29AM -0400, Robert Watson wrote: > > I'd be tempted to disable the portmapper (rpcbind in -CURRENT) by defau= lt, > > allowing it to either be manually enabled, or enabled by virtue of > > dependencies (something we already support). >=20 > It already is disabled in -current since 2000-07-28 22:45:36 > portmap_enable=3D"NO" # Run the portmapper service (YES/NO). But does sysinstall enable it by default? Kris --dkEUBIird37B8yKS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7aHgHWry0BWjoQKURAhwiAKDIsessqunywt5Zfez7/tYSryfsdwCfc6UL G6ywU8VhlZgWW0WeHfM7F7U= =IJ36 -----END PGP SIGNATURE----- --dkEUBIird37B8yKS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 14:47:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 7D63937B401; Wed, 1 Aug 2001 14:47:41 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.217]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA19847; Wed, 1 Aug 2001 14:47:38 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010801144335.C82198@xor.obsecurity.org> Date: Wed, 01 Aug 2001 14:39:00 -0700 (PDT) From: John Baldwin To: Kris Kennaway Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd. Cc: stable@FreeBSD.org, arch@FreeBSD.org, Nate Williams , Robert Watson , "David O'Brien" Sender: owner-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 01-Aug-01 Kris Kennaway wrote: > On Wed, Aug 01, 2001 at 12:11:28PM -0700, David O'Brien wrote: >> On Wed, Aug 01, 2001 at 09:08:29AM -0400, Robert Watson wrote: >> > I'd be tempted to disable the portmapper (rpcbind in -CURRENT) by default, >> > allowing it to either be manually enabled, or enabled by virtue of >> > dependencies (something we already support). >> >> It already is disabled in -current since 2000-07-28 22:45:36 >> portmap_enable="NO" # Run the portmapper service (YES/NO). > > But does sysinstall enable it by default? For liberal and moderate security, yes. Thus by default it does. It's only left off for high and fascist security settings. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 14:55: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7779237B401; Wed, 1 Aug 2001 14:54:57 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f71Lssf64969; Wed, 1 Aug 2001 17:54:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 1 Aug 2001 17:54:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: Kris Kennaway , stable@FreeBSD.org, arch@FreeBSD.org, Nate Williams , "David O'Brien" Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 1 Aug 2001, John Baldwin wrote: > > On 01-Aug-01 Kris Kennaway wrote: > > On Wed, Aug 01, 2001 at 12:11:28PM -0700, David O'Brien wrote: > >> On Wed, Aug 01, 2001 at 09:08:29AM -0400, Robert Watson wrote: > >> > I'd be tempted to disable the portmapper (rpcbind in -CURRENT) by default, > >> > allowing it to either be manually enabled, or enabled by virtue of > >> > dependencies (something we already support). > >> > >> It already is disabled in -current since 2000-07-28 22:45:36 > >> portmap_enable="NO" # Run the portmapper service (YES/NO). > > > > But does sysinstall enable it by default? > > For liberal and moderate security, yes. Thus by default it does. It's > only left off for high and fascist security settings. Sadly, I think the "security profile" mechanism has only limited utility. It makes no attempt to match security to the function of the machine, rather, it is an attempt to linearize the application of security restrictions at relatively arbitrary (i.e., developer-defined rather than user-defined) points along an arbitrary scale. If anything, we should have profiles of features, not profiles of security settings in the current form. I.e., "Workstation", "Workstation with Remote Access", ... Enabling portmap should be a function of needing portmap, not a function of a "low" security profile. If the user asks to enable NFS, they should be warned they will incur certain risks, and that this will result in the enabling of certain other services, such as portmap. Likewise, they might be able to specifically enable portmap regardless of NFS, as they might have their own RPC applications, and likewise be warned of the risks and benefits. Because most consumers will only want portmap in the event they're using portmap for NFS or NIS, portmap might not be explicitly prompted for during install by itself, but be available as a config option in the post-install configuration section of sysinstall for manual frobbing. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 15:20: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hub.freebsd.org (Postfix) with ESMTP id 4BEAF37B401; Wed, 1 Aug 2001 15:19:55 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@[147.11.46.217]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA12266; Wed, 1 Aug 2001 15:19:53 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 01 Aug 2001 15:19:54 -0700 (PDT) From: John Baldwin To: Robert Watson Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd. Cc: "David O'Brien" , Nate Williams , arch@FreeBSD.org, stable@FreeBSD.org, Kris Kennaway Sender: owner-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 01-Aug-01 Robert Watson wrote: > > On Wed, 1 Aug 2001, John Baldwin wrote: > >> >> On 01-Aug-01 Kris Kennaway wrote: >> > On Wed, Aug 01, 2001 at 12:11:28PM -0700, David O'Brien wrote: >> >> On Wed, Aug 01, 2001 at 09:08:29AM -0400, Robert Watson wrote: >> >> > I'd be tempted to disable the portmapper (rpcbind in -CURRENT) by >> >> > default, >> >> > allowing it to either be manually enabled, or enabled by virtue of >> >> > dependencies (something we already support). >> >> >> >> It already is disabled in -current since 2000-07-28 22:45:36 >> >> portmap_enable="NO" # Run the portmapper service (YES/NO). >> > >> > But does sysinstall enable it by default? >> >> For liberal and moderate security, yes. Thus by default it does. It's >> only left off for high and fascist security settings. [ long snip on problems with security profiles ] Not saying security profiles are good or bad, just answering Kris' question. :) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 15:47:58 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 16D2937B403; Wed, 1 Aug 2001 15:47:54 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.4/8.11.1) id f71Mj8u14073; Wed, 1 Aug 2001 15:45:08 -0700 (PDT) (envelope-from obrien) Date: Wed, 1 Aug 2001 15:43:46 -0700 From: "David O'Brien" To: John Baldwin Cc: Kris Kennaway , stable@FreeBSD.org, arch@FreeBSD.org, Nate Williams , Robert Watson Subject: Re: Disabling portmapper (was Re: Patch to modify default inetd. Message-ID: <20010801154346.A14054@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010801144335.C82198@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Wed, Aug 01, 2001 at 02:39:00PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Aug 01, 2001 at 02:39:00PM -0700, John Baldwin wrote: > >> It already is disabled in -current since 2000-07-28 22:45:36 > >> portmap_enable="NO" # Run the portmapper service (YES/NO). > > > > But does sysinstall enable it by default? > > For liberal and moderate security, yes. Thus by default it does. It's only > left off for high and fascist security settings. Ah. An for those of us that cvsup, it was equivalant to "fascist security" when the default was changed. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 16: 6:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [24.14.150.180]) by hub.freebsd.org (Postfix) with ESMTP id 1512937B401 for ; Wed, 1 Aug 2001 16:06:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f71N6PM82209 for ; Wed, 1 Aug 2001 16:06:26 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id C1BA138CC; Wed, 1 Aug 2001 16:06:25 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Julian Elischer Cc: arch@FreeBSD.ORG Subject: Re: threads comment In-Reply-To: Date: Wed, 01 Aug 2001 16:06:25 -0700 From: Peter Wemm Message-Id: <20010801230625.C1BA138CC@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Y'know, > > if we'd called the thread a "process" > and the thing that has a pid a "task" (or something) > > the actual functional changes would be a HECK of a lot > clearer in the diffs because I have 50k of functional changes and > 800+KB of > > - struct proc *pB > + struct thread *td; > > > (just a comment) > > Actually if we left processes as processes and then created > 'super-processes', I think you could start now and > still finish first. > > (so far I have replaced about 4000 instances of struct proc with struct > thread (mostly by hand)) IMHO, it is better to do it right rather than take a shortcut that we're going to regret later. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Aug 1 19:52:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailhost.xrxgsn.com (unknown [216.42.106.144]) by hub.freebsd.org (Postfix) with ESMTP id 446FF37B401; Wed, 1 Aug 2001 19:52:43 -0700 (PDT) (envelope-from mike.porter@xrxgsn.com) Received: from laptop (1Cust65.tnt4.salt-lake-city.ut.da.uu.net [63.11.216.65]) by mailhost.xrxgsn.com (8.9.3/8.9.3) with SMTP id WAA07717; Wed, 1 Aug 2001 22:45:00 -0400 (EDT) Message-ID: <025d01c11afd$ee861fe0$0300a8c0@laptop> From: "Mike Porter" To: "Robert Watson" Cc: , Subject: Re: Patch to modify default inetd.conf, have sysinstall prompt to edit , inetd.conf Date: Wed, 1 Aug 2001 20:50:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-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, 31 Jul 2001, Mike Porter wrote: > > >Actually, although I'm happy with the current default of enabling SSH for >now, if there isn't already a sysinstall post-install config twiddle for >SSH, we should probably add one. To be honest, a "default all off" >policy, with the opportunity to enable easily in sysinstall, might be >better than turning SSH on by default. Maybe we'll do that for >5.0-RELEASE :-). Yes thank you for clarifying. Although as I mentioned earlier, I managed to misread your post and thought you were toaling about ssh when you were talking about ftpd... > >This is true--however, the inetd.conf file doesn't lend itself to >automated management, as it doesn't have an inline "disabled" flag. To >disable a service, you comment it out, making it hard for a program to >distinguish things which are legitimately comments, and things that are >disabled services. In the long term, it would probably make sense to >develop some sort of administrative tool for inetd.conf: however, I >concluded that doing so prior to 4.4-RELEASE was unlikely, and opted for >this. In the future, if such a tool is developed, I'd be happy to slot it >in instead of invoking EDITOR on it :-). > This is an interesting point, though it could also be argued that if there is a prety tool to do it, many (most?) of the comments in the file are no longer needed. The flip side of this, of course is that then you are more or less forced into using the specialized editor, and there are those who would prefer not to (at least not all the time). JUst brainstorming here....but another potential advantage...such a program could invoke a boot time check of inetd.conf to a stored backup created on editing, which block stuff like the person who had the "dlip" line in his inetd.conf. I suppose the argument AGAINST that is that whoever put that line in his inetd.conf could as easily have access to the mythical-viinetd (to borrow from vipw), and this therefore doesn't add much in the way of *real* security. Well, I'm going to shut up now before I put my foot in my mouth again. mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 2 1:50: 2 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.bigmailbox.com (mail12.bigmailbox.com [209.132.220.43]) by hub.freebsd.org (Postfix) with ESMTP id 8FEF937B401 for ; Thu, 2 Aug 2001 01:49:59 -0700 (PDT) (envelope-from shrig@www.com) Received: œby mail12.bigmailbox.com (8.8.7/8.8.7) id BAA07459; Thu, 2 Aug 2001 01:49:59 -0700 Date: Thu, 2 Aug 2001 01:49:59 -0700 Message-Id: <200108020849.BAA07459@mail12.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [203.199.51.150] From: "Shrikant Gundapwar" To: freebsd-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 HI All I am new to this community as well as FreeBSD. Can any one help me regarding some details of FreeBSD ? I would like to have a look at detailed architecture of FreeBSD and algorithms exclusively used in. Enjoy.... -shrikant ------------------------------------------------------------ WWW.COM - Where the Web Begins! http://www.www.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 2 16:26:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id 420D237B405 for ; Thu, 2 Aug 2001 16:26:45 -0700 (PDT) (envelope-from mwlucas@blackhelicopters.org) Received: (from mwlucas@localhost) by blackhelicopters.org (8.9.3/8.9.3) id TAA01537; Thu, 2 Aug 2001 19:26:05 -0400 (EDT) (envelope-from mwlucas) Date: Thu, 2 Aug 2001 19:26:05 -0400 From: Michael Lucas To: Shrikant Gundapwar Cc: freebsd-arch@FreeBSD.ORG Subject: Re: your mail Message-ID: <20010802192605.B1463@blackhelicopters.org> References: <200108020849.BAA07459@mail12.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200108020849.BAA07459@mail12.bigmailbox.com>; from shrig@www.com on Thu, Aug 02, 2001 at 01:49:59AM -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 Hello, Shrikant, First, welcome to FreeBSD! Your best bet is to ask over on questions@freebsd.org; any number of people will be happy to provide you to pointers on information. The -arch list is specifically intended for development directions in FreeBSD; you're not going to find this information here. Regards, Michael On Thu, Aug 02, 2001 at 01:49:59AM -0700, Shrikant Gundapwar wrote: > HI All > > I am new to this community as well as FreeBSD. Can any one help me regarding some details of FreeBSD ? I would like to have a look at detailed architecture of FreeBSD and algorithms exclusively used in. > > Enjoy.... > > -shrikant > > > > > ------------------------------------------------------------ > WWW.COM - Where the Web Begins! http://www.www.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- Michael Lucas mwlucas@blackhelicopters.org http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 2 16:42:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ualjuarez.elrancho.com.mx (unknown [200.23.18.58]) by hub.freebsd.org (Postfix) with ESMTP id C2CDF37B403 for ; Thu, 2 Aug 2001 16:40:52 -0700 (PDT) (envelope-from promo@elrancho.com.mx) Received: from 200 [148.243.115.100] by ualjuarez.elrancho.com.mx (SMTPD32-6.05) id A0B8DA0216; Thu, 02 Aug 2001 18:41:12 +0100 From: Fre nights for you. To: Subject: You have WON your FREE nights!!! Mime-Version: 1.0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Reply-To: promo@elrancho.com.mx X-Mailer: MailList Express 3.70, Internet-Soft.Com Message-Id: <200108021825.23w9r9A@www.elrancho.com.mx> Date: Thu, 2 Aug 2001 18:41:18 +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 =0D=0A=0D=0A=0D=0A=0D=0A=20=20= =0D=0A=20=20=20=20=0D=0A=20=20=20=20=20=20

=0D=0A=20=20=20=20=20=20=  

=0D=0A=20=20=20=20=20=20English =0D=0A=20=20= =20=20=20=20Espa=F1ol=0D=0A=20= =20=0D=0A=0D=0A

=0D=0A=0D=0A=20=20
=0D=0A=20=20=0D=0A=20=20= =20=20=0D=0A=20=20=20=20=20=20
=0D=0A=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20<= span=20style=3D"background-color:=20#FFFFFF">=0D=0A=20=20=20=20=20=20=20=20Escape=0D=0A=20= =20=20=20=20=20=20=20to=20Paradise...!=0D=0A=20=20=20=20=20=20= =20=20

=0D=0A=20=20=20=20=20=20=20=20=0D= =0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20= =20=20=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20El=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=20= =20Rancho=20Villas=0D=0A=20=20=20=20=20=20=20=20=20=20<= /center>=0D=0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20= =20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20
=0D=0A=20=20=20= =20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20= =20=20=20=20=20 =0D=0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20<= font=20color=3D"#FFFFFF"=20face=3D"Arial"=20size=3D"2">Mazatlan,=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20Mexico

=0D=0A=20=20=20=20= =20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20=  =0D=0A=20=20=20=20=20= =20
=0D=0A=20=20
=0D=0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20= =20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20= =20=0D=0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Dear=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=20Friend:

=0D=0A=20=20=20=20=20= =20=20=20=20=20=20=20You've=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20been=20= selected=20to=20take=201=20night=20free=20for=20each=20one=20you=20pay=20= in=20our=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20resort=20at=20Mazatla= n,=20Mexico.

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20That's=0D=0A= =20=20=20=20=20=20=20=20=20=20=20=20right=20!!

=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20Pay=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=201=20night=20and=20get=20another=20one=20F= REE!!

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20This=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20opportunity=20goes=20to=20only=20selec= ted=20people,=20so=20take=20advantage=20of=20this=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20unique=20offer=20you'll=20never=20see=20again=20a=20l= odging=20offer=20like=20this=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20o= ne. =20Your=20next=20vacation=20half=20the=20price!!

=0D= =0A=20=20=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Why=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20don't=20you=20take=20a=20rest=20in=20the=20w= onderful=20beach=20of=20Mazatlan,=0D=0A=20=20=20=20=20=20=20=20=20=20=20= =20Mexico. =20This=20is=20your=20opportunity. =20Make=20it=20= possible=20for=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20you.

= =0D=0A=20=20=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20If=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=20you=20use=20this=20wonderful=20opportunit= y,=20I'll=20also=20give=20you=20a=2020%=0D=0A=20=20=20=20=20=20=20=20= =20=20=20=20discount=20over=20drinks=20and=20food=20in=20our=20rest= aurant. =20The=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20delicious=20= flavors=20you're=20will=20taste=20there=20are=20going=20to=20be=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20unforgettable,=20believe=20me!<= /p>=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20I=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20send=20you=20our=20addresses=20for=20m= ore=20information,=20just=20in=20case=20you=20are=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20interested=20in=20the=20offer=20I'm=20sending=20you.<= /font>

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20= If=0D= =0A=20=20=20=20=20=20=20=20=20=20=20=20you=20want=20to=20use=20this=20b= enefit,=20please=20refer=20the=20code=20below=20to=20make=0D=0A=20=20=20= =20=20=20=20=20=20=20=20=20this=20offer=20valid:

=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=20fRpromo0802

=0D=0A=20=20=20=20=20=20=20=20= =20=20=20=20Promotion=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Validity: =20= from=20Aug=2015=20to=20Dec.=2015,=202001;=20excluding=20Thanksgiving=0D= =0A=20=20=20=20=20=20=20=20=20=20=20=20week.

=0D=0A=20=20=
=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Web=20Sites:
=0D=0A= =20=20=20=20=20=20=20=20=20=20=20=20www.elrancho.com.mx

=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20<= a=20href=3D"http://www.elranchovillas.com">www.elranchovillas.com

=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20e-mail:<= font=20color=3D"#0000FF">
=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20= info@elrancho.com.mx=0D=0A=20=20=20=20=20=20=20=20= =20=20=0D=0A=20= =20=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20= =20=20=0D=0A=20=20=20=20=20=20= =20=20=20=20=20=20=0D=0A=20=20= =20=20=20=20=20=20=20=20=20=20=0D=0A=20=20
=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Reservations:=
=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20Tel:=20(1)716-0606
=0D= =0A=20=20=20=20=20=20=20=20=20=20=20=20Fax: =20(1)716-9777
=0D=0A= =20=20=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20= =20=20=20=20US=20&=20Canada:
=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20= 1-888-596-5760
=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20=0D=0A= =20=20=20=20=20=20=20=20=20=20=20=20Mexico:
=0D=0A=20=20=20=20=20=20=20=20=20= =20=20=2001-800-717-1991=0D=0A=20=20=20=20=20=20=20=20= =0D=0A=20=20=20=20=20=20=20=20=0D=0A=20=20
=0D=0A=20=20=20= =20=20=20To=20be=20removed=20= from=20our=20mailing=20list,=0D=0A=20=20=20=20=20=20please=20send=20us=20= a=20blank=20email=20to=20pro= mo@elrancho.com.mx=0D=0A=20=20=20=20=20=20with=20the=20word=20REMOV= E=20in=20the=20subject=20line.

=0D=0A=20=20=20=20=20=20=0D= =0A=20=20=20=20=0D=0A=20=20=0D=0A=20=20
=0D=0A=0D=0A 

=0D=0A&= nbsp;

=0D=0A 

=0D=0A 

=0D=0A 

=0D=0A 

=0D=0A 

=0D=0A 

=0D=0A 

=0D=0A=

=0D=0A=0D=0A= =20=20=0D=0A=20=20=20=20
=0D=0A=20=20=20=20=0D=0A=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20Escapa=0D=0A=20=20=20=20=20=20al=20pa= ra=EDso...!=0D=0A=20=20=20=20=20=20

= =0D=0A=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=0D=0A= =20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20 =0D=0A= =20=20=20=20=20=20=20=20=20=20Villas=0D=0A=20=20=20=20=20=20=20= =20=20=20=20=20El=20Rancho=0D=0A=20=20=20=20=20=20=20=20=
=0D=0A=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20&nbs= p;

=0D=0A=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=0D= =0A=20=20=20=20=20=20
=0D=0A=20=20=20=20=20=20=0D=0A=20=20=20= =20=20=20=20=20 =0D=0A=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20Maz= atl=E1n,=0D=0A=20=20=20=20=20=20=20=20=20=20M=E9xico

=0D=0A= =20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20=20=0D= =0A=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20=20=20=20 =0D=0A=20=20=20=20=20=20=20= =20=0D=0A=20=20=20=20=20=20=20= =20=20=20=20=20Hola=0D=0A=20=20=20=20=20=20=20=20=20=20=20=20amigo:=

=0D=0A=20=20=20=20=20=20=20=20=20=20Haz=0D=0A=20=20=20=20=20=20=20= =20=20=20sido=20seleccionado=20para=20llevarte=20una=20noche=20gratis=20= por=20cada=20una=20que=0D=0A=20=20=20=20=20=20=20=20=20=20pagues=20a=20= nuestro=20hotel=20en=20Mazatl=E1n,=20M=E9xico.

=0D=0A=20=20=20= =20=20=20=20=20=20=20Es=0D=0A=20=20=20=20=20=20=20=20=20=20en=20serio=20!!=

=0D=0A=20=20=20=20=20=20=20=20=20=20Paga=0D=0A=20=20=20=20=20=20=20=20=20=201=20noche=20y=20te=20llev= as=20otra=20totalmente=20GRATIS!!

=0D=0A=20=20=20=20=20=20= =20=20=20=20Esta=0D=0A=20=20=20=20=20=20=20=20=20=20oportunidad=20se=20da=20= s=F3lo=20a=20personas=20muy=20selectas,=20asi=20que=20aproveche=0D=0A=20= =20=20=20=20=20=20=20=20=20esta=20=FAnica=20oferta.  =20Jam=E1= s=20vera=20una=20oferta=20igual=20en=20lo=20que=0D=0A=20=20=20=20=20=20= =20=20=20=20a=20alojamiento=20se=20refiere. =20Sus=20pr=F3ximas=20= vacaciones=20por=20la=20mitad=0D=0A=20=20=20=20=20=20=20=20=20=20de=20p= recio!!

=0D=0A=20=20=20=20=20=20=20=20=20=20Por=0D=0A=20=20=20=20=20= =20=20=20=20=20qu=E9=20no=20tomar=20un=20descansito=20en=20las=20maravi= llosas=20playas=20de=20Mazatl=E1n,=0D=0A=20=20=20=20=20=20=20=20=20=20M= =E9xico. =20Esta=20es=20su=20oportunidad. =20H=E1gala=20posib= le=20por=20usted.

=0D=0A=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20= =20=20Es=0D=0A=20=20=20=20=20=20=20=20=20=20m=E1s,=20si=20usted=20hace=20u= so=20de=20esta=20incre=EDble=20oportunidad,=20adem=E1s=20le=0D=0A=20=20= =20=20=20=20=20=20=20=20regalo=20un=2020%=20de=20descuento=20en=20al= imentos=20y=20bebidas=20en=20nuestro=0D=0A=20=20=20=20=20=20=20=20=20= =20restaurante. =20Los=20sabores=20delicios=20que=20probara=20ah=ED= ,=20ser=E1n=0D=0A=20=20=20=20=20=20=20=20=20=20inolvidables,=20cr=E9ame= !

=0D=0A=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20=20=20Para=0D=0A=20=20= =20=20=20=20=20=20=20=20m=E1s=20informaci=F3n,=20le=20mando=20nuestras=20= direcciones=20electr=F3nicas,=20s=F3lo=0D=0A=20=20=20=20=20=20=20=20=20= =20en=20el=20caso=20de=20que=20se=20interese=20por=20la=20oferta=20que=20= le=20he=20hecho.

=0D=0A=20=20=20=20=20=20=20=20=20=20 

=0D=0A=20=20=20=20=20=20=20=20= =20=20Si=0D=0A=20=20=20=20=20=20=20=20=20=20quiere=20usar=20el=20beneficio= ,=20por=20favor=20indique=20el=20codigo=20que=20sigue=20para=0D=0A=20=20= =20=20=20=20=20=20=20=20hacer=20v=E1lida=20esta=20oferta:

=0D= =0A=20=20=20=20=20=20=20=20=20=20<= font=20=0D=0Asize=3D"2">fRpromo0802

=0D=0A=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20Vigencia=20de=20la=20promoci=F3n:=20de=20Agosto=0D=0A=20=20=20=20=20= =20=20=2015=20a=20Diciembre=2015=20del=202001;=20se=20excluye=20la=20se= mana=20de=20Thanksgiving=20(Festividad=0D=0A=20=20=20=20=20=20=20=20en=20= EE.UU.)

=0D=0A=20=20=20=20=20=20
=0D=0A=20=20=20=20= =20=20=20=20=20=20Web=20Sites:
=0D=0A=20=20=20=20=20=20=20=20=20=20ww= w.elrancho.com.mx

=0D=0A=20=20=20=20=20=20=20=20=20= =20www.elranchovillas.com<= /p>=0D=0A=20=20=20=20=20=20=20=20=20=20e-mail:
=0D=0A=20=20=20=20=20= =20=20=20=20=20info@elrancho.com.mx=0D=0A=20=20=20= =20=20=20=20=20= =0D=0A=20=20=20=20=20=20=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20= =0D=0A=20=20=20=20=20=20=20=20=20= =20=0D=0A=20=20=20=20=20=20=20=20= =20=20=0D=0A=20=20=20=20=0D=0A=20=20=20=20=20=20=20=20=20=20Reservaciones:
=0D=0A=20=20=20=20=20= =20=20=20=20=20Tel:=20(1)716-0606
=0D=0A=20=20=20=20=20=20=20=20=20=20= Fax: =20(1)716-9777
=0D=0A=20=20=20=20=20=20=20=20=20=20= =0D=0A=20=20=20=20=20=20=20=20=20=20M=E9xico:
=0D=0A=20=20=20=20=20=20=20=20= =20=2001-800-717-1991
=0D=0A=20=20=20=20=20=20=20=20=20=20=0D= =0A=20=20=20=20=20=20=20=20=20=20US=20&=20Canada:
=0D=0A=20=20=20=20=20=20=20= =20=20=201-888-596-5760=0D=0A=20=20=20=20=20=20=0D= =0A=20=20=20=20=20=20=0D=0A=20=20=20=20<= font=20size=3D"1">Para=20ser=20removido=20de=20nuestra=20lista=20de=0D=0A= =20=20=20=20correo,=20por=20favor=20env=EDenos=20un=20email=20en=20blan= co=20a=20la=20siguiente=20direcci=F3n=0D=0A=20=20=20=20electr=F3nica=20= :=20promo@elrancho.com.mx,=0D=0A=20=20=20=20con=20la=20palabra=20REMOVE=20en=20la=20linea=20de=20= Asunto=20(subject).

=0D=0A=20=20=20=20=0D=0A=20=20=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0AThe=20message=20sent=20= by=20MailList=20Express=203.70=20=20=20Registered=20Version=20(Download= =20from=20http://Internet-Soft.com)=0D=0A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Aug 2 22:13:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from rcsntx.swbell.net (mta8.rcsntx.swbell.net [151.164.30.63]) by hub.freebsd.org (Postfix) with ESMTP id 5B5DD37B401 for ; Thu, 2 Aug 2001 22:13:48 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.149.190]) by mta8.rcsntx.swbell.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GHH005TB7UV8A@mta8.rcsntx.swbell.net> for arch@FreeBSD.ORG; Fri, 03 Aug 2001 00:13:44 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.11.4/8.9.3) id f735CwO24128; Fri, 03 Aug 2001 00:12:58 -0500 (CDT envelope-from chris) Date: Fri, 03 Aug 2001 00:12:58 -0500 From: Chris Costello Subject: Re: threads comment In-reply-to: <"from julian"@elischer.org> To: Julian Elischer Cc: arch@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20010803001257.H6870@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: Mutt/1.2.5i References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday, July 31, 2001, Julian Elischer wrote: > if we'd called the thread a "process" > and the thing that has a pid a "task" (or something) That would be extremely confusing. A task would be a thing to go to; that sounds more like an instruction, or maybe a thread. I think your current diff does it best: Everybody knows that a single process has one or more threads of execution, rather than a task having one or more processes of execution. Don't you agree? -- +-------------------+---------------------------------------------------+ | Chris Costello | Don't document the program; program the document. | | chris@calldei.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 2 23:26:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 7949937B407 for ; Thu, 2 Aug 2001 23:26:09 -0700 (PDT) (envelope-from julian@elischer.org) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA49582; Fri, 3 Aug 2001 01:37:36 -0700 (PDT) Date: Fri, 3 Aug 2001 01:37:35 -0700 (PDT) From: Julian Elischer To: Chris Costello Cc: arch@FreeBSD.ORG Subject: Re: threads comment In-Reply-To: <20010803001257.H6870@holly.calldei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 3 Aug 2001, Chris Costello wrote: > That would be extremely confusing. A task would be a thing to > go to; that sounds more like an instruction, or maybe a thread. > I think your current diff does it best: Everybody knows that a > single process has one or more threads of execution, rather than > a task having one or more processes of execution. Don't you > agree? Well that's what I'm doing.... :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 3 13:31:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 7BA0F37B406 for ; Fri, 3 Aug 2001 13:31:06 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id 447343E35; Fri, 3 Aug 2001 13:31:06 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id 36B5A3C12C for ; Fri, 3 Aug 2001 13:31:06 -0700 (PDT) To: arch@freebsd.org Subject: Library routine to load a kld if it already isn't Date: Fri, 03 Aug 2001 13:31:01 -0700 From: Dima Dorfman Message-Id: <20010803203106.447343E35@bazooka.unixfreak.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 Programs that control a certain driver or set of drivers (e.g., ifconfig, ccdconfig, mdconfig) attempt to load the module they'll be working with if it isn't already present. They do it in different ways, and the most correct way (i.e., the one that handles the most cases properly) is liable to change if the kld subsystem ever changes. I propose to add a library routine, kldmaybeload(3), that will check if a certain module is present in the kernel, and load it if it isn't. This will cut down on duplicated code, and may save some headaches later if the kld interface changes. Sharball of the implementation and man page is attached (extract into src/lib/libc/gen). Comments? Suggestions? # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # kldmaybeload.c # kldmaybeload.3 # echo x - kldmaybeload.c sed 's/^X//' >kldmaybeload.c << 'END-of-kldmaybeload.c' X/* X * Copyright (c) 2001 Dima Dorfman. X * All rights reserved. X * X * Redistribution and use in source and binary forms, with or without X * modification, are permitted provided that the following conditions X * are met: X * 1. Redistributions of source code must retain the above copyright X * notice, this list of conditions and the following disclaimer. X * 2. Redistributions in binary form must reproduce the above copyright X * notice, this list of conditions and the following disclaimer in the X * documentation and/or other materials provided with the distribution. X * X * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X * SUCH DAMAGE. X */ X X#if defined(LIBC_RCS) && !defined(lint) Xstatic const char rcsid[] = X "$FreeBSD$"; X#endif /* LIBC_RCS and not lint */ X X#include X#include X#include X X#include X#include X#include X Xint Xkldmaybeload(const char *modname) X{ X struct module_stat ms; X int fid, mid; X char *cp; X X ms.version = sizeof(ms); X /* X * Walk the list of loaded modules. We have to do this by X * walking the list of loaded files, then walking the modules X * in them using modfnext(). The latter will return 0 when X * we've reached the last module in the file. This is X * contrary to the documentation, which says it will return X * the ID of "the next kernel module", and says nothing about X * files. XXX X */ X for (fid = kldnext(0); fid != 0; fid = kldnext(fid)) { X for (mid = kldfirstmod(fid); mid != 0; mid = modfnext(mid)) { X if (modstat(mid, &ms) == -1) X /* X * This really shouldn't happen, X * because modstat() can't fail for X * any reason that wouldn't indicate a X * bug either in the kernel, or in X * this function. X */ X return (-1); X /* X * Some modules have a bus name in their name, X * e.g. "pci/if_fxp". We were given a name X * without the bus name, so we have to strip X * it off it it's there before we do the X * comparison. X */ X cp = strchr(ms.name, '/'); X if (cp != NULL) X cp++; X else X cp = ms.name; X if (strcmp(modname, cp) == 0) X /* Already loaded. */ X return (0); X } X } X /* We didn't find it, so it must not be present. Load it. */ X return (kldload(modname)); X} END-of-kldmaybeload.c echo x - kldmaybeload.3 sed 's/^X//' >kldmaybeload.3 << 'END-of-kldmaybeload.3' X.\" X.\" Copyright (c) 2001 Dima Dorfman. X.\" All rights reserved. X.\" X.\" Redistribution and use in source and binary forms, with or without X.\" modification, are permitted provided that the following conditions X.\" are met: X.\" 1. Redistributions of source code must retain the above copyright X.\" notice, this list of conditions and the following disclaimer. X.\" 2. Redistributions in binary form must reproduce the above copyright X.\" notice, this list of conditions and the following disclaimer in the X.\" documentation and/or other materials provided with the distribution. X.\" X.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X.\" SUCH DAMAGE. X.\" X.\" $FreeBSD$ X.\" X.Dd July 31, 2001 X.Dt KLDMAYBELOAD 3 X.Os X.Sh NAME X.Nm kldmaybeload X.Nd load a kernel module if it isn't already present X.Sh LIBRARY X.Lb libc X.Sh SYNOPSIS X.In unistd.h X.Ft int X.Fn kldmaybeload "const char *modname" X.Sh DESCRIPTION XThe X.Fn kldmaybeload Xfunction checks if the module referenced by X.Fa modname Xis already present in the kernel (either by being already loaded, or Xstatically compiled in), and loads it if it isn't. X.Sh RETURN VALUES XIf the module is already present or has been successfully loaded, X0 is returned; otherwise, if the module is not present and could not Xbe loaded, \-1 is returned and X.Va errno Xis set to indicate the error. X.Sh ERRORS XAn attempt to load the module may fail for the following reasons: X.Bl -tag -width Er X.It Bq Er EPERM XPermission is denied to read the module file or link it with the kernel. X.It Bq Er EFAULT X.Fa modname Xpoints outside the process's allocated address space, or Xa bad address was encountered when trying to link the module. X.It Bq Er ENOMEM XThere was insufficient memory to service the request. X.It Bq Er ENOENT XThe module file could not be found. X.It Bq Er ENOEXEC XThe format of the module file was unrecognized. X.El X.Sh SEE ALSO X.Xr modfind 2 , X.Xr kldload 2 , X.Xr kld 4 , X.Xr kldconfig , X.Xr kldload 8 X.Sh HISTORY XThe X.Fn kldmaybeload Xfunction appeared in X.Fx 5.0 . END-of-kldmaybeload.3 exit To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 3 13:35: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1C3F437B407; Fri, 3 Aug 2001 13:34:59 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f73KYtf09679; Fri, 3 Aug 2001 16:34:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 3 Aug 2001 16:34:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Cc: stable@FreeBSD.org, re@FreeBSD.org Subject: Further tweaks to sysinstall to take into account inetd changes 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 Attached, please find an additional patch to sysinstall, which: - Reduces the number of offered security profiles, as we now have a more conservative default, and actually prompt specifically for inetd rather than handling it as a side effect of the security profile. Update the help file to reflect this change. - Rename "Fascist" to "Extreme" in the source code, to match the names presented. - Remove portmap and inetd from profile management. Portmap is now disabled by default, but automatically turned on if a feature requires it (such as NFS, etc). I'll probably commit this to -CURRENT within a day or so, assuming no widespread objections, and put it in the MFC queue for when I get release engineer permission to MFC. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 3 13:56: 6 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id C3D0C37B401; Fri, 3 Aug 2001 13:55:44 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.4/8.11.4) with SMTP id f73Ktff09835; Fri, 3 Aug 2001 16:55:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 3 Aug 2001 16:55:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Cc: stable@FreeBSD.org, re@FreeBSD.org Subject: Re: Further tweaks to sysinstall to take into account inetd changes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Someone kindly pointed out that the patch I included lacked some content. Try below. Index: config.c =================================================================== RCS file: /spare/freebsd/ncvs/src/usr.sbin/sysinstall/config.c,v retrieving revision 1.185 diff -u -r1.185 config.c --- config.c 2001/08/02 03:53:36 1.185 +++ config.c 2001/08/03 20:26:28 @@ -487,52 +487,22 @@ return DITEM_SUCCESS; } -/* Use the most fascist security settings */ +/* Use the most extreme security settings */ int -configSecurityFascist(dialogMenuItem *self) +configSecurityExtreme(dialogMenuItem *self) { WINDOW *w = savescr(); - variable_set2("inetd_enable", "NO", 1); - variable_set2("portmap_enable", "NO", 1); + variable_set2("nfs_server_enable", "NO", 1); variable_set2("sendmail_enable", "NO", 1); variable_set2("sshd_enable", "NO", 1); - variable_set2("nfs_server_enable", "NO", 1); variable_set2("kern_securelevel_enable", "YES", 1); variable_set2("kern_securelevel", "2", 1); - /* More fascist stuff should go here */ if (self) msgConfirm("Extreme security settings have been selected.\n\n" - "This means that all \"popular\" network services and\n" - "mechanisms like inetd(8) have been DISABLED by default.\n\n" - "PLEASE NOTE that this still does not save you from having\n" - "to properly secure your system in other ways or exercise\n" - "due diligence in your administration, this simply picks\n" - "a more secure set of out-of-box defaults to start with.\n\n" - "To change any of these settings later, edit /etc/rc.conf"); - - restorescr(w); - return DITEM_SUCCESS; -} - -int -configSecurityHigh(dialogMenuItem *self) -{ - WINDOW *w = savescr(); - - variable_set2("inetd_enable", "NO", 1); - variable_set2("sendmail_enable", "YES", 1); - variable_set2("sshd_enable", "YES", 1); - variable_set2("portmap_enable", "NO", 1); - variable_set2("nfs_server_enable", "NO", 1); - variable_set2("kern_securelevel_enable", "YES", 1); - variable_set2("kern_securelevel", "1", 1); - - if (self) - msgConfirm("High security settings have been selected.\n\n" - "This means that most \"popular\" network services and\n" - "mechanisms like inetd(8) have been DISABLED by default.\n\n" + "Sendmail, SSHd, and NFS services have been disabled, and\n" + "securelevels have been enabled.\n" "PLEASE NOTE that this still does not save you from having\n" "to properly secure your system in other ways or exercise\n" "due diligence in your administration, this simply picks\n" @@ -543,54 +513,23 @@ return DITEM_SUCCESS; } -int configSecurityModerate(dialogMenuItem *self) { WINDOW *w = savescr(); - variable_set2("inetd_enable", "YES", 1); - if (!variable_cmp("nfs_client_enable", "YES") || - !variable_cmp("nfs_server_enable", "YES")) - variable_set2("portmap_enable", "YES", 1); - if (!variable_cmp("nfs_server_enable", "YES")) - variable_set2("nfs_reserved_port_only", "YES", 1); + variable_set2("nfs_reserved_port_only", "YES", 1); variable_set2("sendmail_enable", "YES", 1); variable_set2("sshd_enable", "YES", 1); variable_set2("kern_securelevel_enable", "NO", 1); if (self) msgConfirm("Moderate security settings have been selected.\n\n" - "This means that most \"popular\" network services and\n" - "mechanisms like inetd(8) have been enabled by default\n" - "for a comfortable user experience but with possible\n" - "trade-offs in system security. If this bothers you and\n" - "you know exactly what you are doing, select one of the\n" - "other security profiles instead.\n\n" - "To change any of these settings later, edit /etc/rc.conf"); - - restorescr(w); - return DITEM_SUCCESS; -} - -int -configSecurityLiberal(dialogMenuItem *self) -{ - WINDOW *w = savescr(); - - variable_set2("inetd_enable", "YES", 1); - variable_set2("portmap_enable", "YES", 1); - variable_set2("sendmail_enable", "YES", 1); - variable_set2("sshd_enable", "YES", 1); - variable_set2("kern_securelevel_enable", "NO", 1); - - if (self) - msgConfirm("Liberal security settings have been selected.\n\n" - "This means that most \"popular\" network services and\n" - "mechanisms like inetd(8) have been enabled by default\n" - "for the most comfortable user experience but with possible\n" - "trade-offs in system security. If this bothers you and\n" - "you know exactly what you are doing, select one of the\n" - "other security profiles instead.\n\n" + "Sendmail and SSHd have been enabled, securelevels are\n" + "disabled, and NFS server settings have been left intact.\n" + "PLEASE NOTE that this still does not save you from having\n" + "to properly secure your system in other ways or exercise\n" + "due diligence in your administration, this simply picks\n" + "a standard set of out-of-box defaults to start with.\n\n" "To change any of these settings later, edit /etc/rc.conf"); restorescr(w); Index: menus.c =================================================================== RCS file: /spare/freebsd/ncvs/src/usr.sbin/sysinstall/menus.c,v retrieving revision 1.312 diff -u -r1.312 menus.c --- menus.c 2001/08/02 03:53:36 1.312 +++ menus.c 2001/08/03 20:24:36 @@ -1673,10 +1673,8 @@ "Select a canned security profile - F1 for help", "security", /* help file */ { { "X Exit", "Exit this menu (returning to previous)", NULL, configSecurityModerate }, - { "Low", "Fairly wide-open (little) security.", NULL, configSecurityLiberal }, { "Medium", "Moderate security settings [DEFAULT].", NULL, configSecurityModerate }, - { "High", "Fairly safe security settings.", NULL, configSecurityHigh }, - { "Extreme", "Very restrictive security settings.", NULL, configSecurityFascist }, + { "Extreme", "Very restrictive security settings.", NULL, configSecurityExtreme }, { NULL } }, }; Index: sysinstall.h =================================================================== RCS file: /spare/freebsd/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v retrieving revision 1.211 diff -u -r1.211 sysinstall.h --- sysinstall.h 2001/08/02 03:53:36 1.211 +++ sysinstall.h 2001/08/03 20:17:47 @@ -451,10 +451,8 @@ extern int configNFSServer(dialogMenuItem *self); extern int configWriteRC_conf(dialogMenuItem *self); extern int configSecurityProfile(dialogMenuItem *self); -extern int configSecurityFascist(dialogMenuItem *self); -extern int configSecurityHigh(dialogMenuItem *self); +extern int configSecurityExtreme(dialogMenuItem *self); extern int configSecurityModerate(dialogMenuItem *self); -extern int configSecurityLiberal(dialogMenuItem *self); extern int configTTYs(dialogMenuItem *self); /* crc.c */ Index: help/security.hlp =================================================================== RCS file: /spare/freebsd/ncvs/src/usr.sbin/sysinstall/help/security.hlp,v retrieving revision 1.2 diff -u -r1.2 security.hlp --- help/security.hlp 2001/03/11 23:47:12 1.2 +++ help/security.hlp 2001/08/03 20:23:55 @@ -3,19 +3,14 @@ which services are enabled (or disabled) by each of the canned security profiles: - Extreme High Medium Low - ------- ---- -------- --- -inetd NO NO YES YES -sendmail NO YES YES YES -sshd NO YES YES YES -portmap NO NO * YES -nfs_server NO NO ** *** -securelevel YES (2) YES (1) NO NO + Extreme Medium + ------- ------ +nfs_server NO * +sendmail NO YES +sshd NO YES +securelevel YES (2) NO NOTES: -* Portmap is enabled if the machine has been configured as either an NFS - client or an NFS server earlier in the installation process. -** If the machine has been configured as an NFS server, NFS will only run - on a reserved port. -*** No changes are made to the NFS configuration. +* If the machine has been configured as an NFS server, NFS will only run + on a reserved port. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Aug 3 23:50:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 83D5937B408 for ; Fri, 3 Aug 2001 23:50:10 -0700 (PDT) (envelope-from ben@FreeBSD.org) Received: from strontium.shef.vinosystems.com ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.30 #1) id 15SvFZ-0009G5-00; Sat, 04 Aug 2001 07:49:29 +0100 Received: (from ben@localhost) by strontium.shef.vinosystems.com (8.11.4/8.11.4) id f746nSI74006; Sat, 4 Aug 2001 07:49:29 +0100 (BST) (envelope-from ben@FreeBSD.org) X-Authentication-Warning: strontium.shef.vinosystems.com: ben set sender to ben@FreeBSD.org using -f Date: Sat, 4 Aug 2001 07:49:28 +0100 From: Ben Smithurst To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: Library routine to load a kld if it already isn't Message-ID: <20010804074928.A66860@strontium.shef.vinosystems.com> References: <20010803203106.447343E35@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010803203106.447343E35@bazooka.unixfreak.org> X-PGP-Key: http://www.smithurst.org/ben/pgp-key.txt Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dima Dorfman wrote: > X.Sh ERRORS > XAn attempt to load the module may fail for the following reasons: > X.Bl -tag -width Er > X.It Bq Er EPERM I think I'd prefer this section be reduced to kldmaybeload() may fail and set errno for any of the errors specified for the routines modfind(2) and kldload(2). in the way other libc manual pages do. That way, there's just one less place to update when additional error possibilities are added to those functions. --=20 Ben Smithurst / ben@FreeBSD.org FreeBSD: The Power To Serve http://www.FreeBSD.org/ --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7a5r2bPzJ+yzvRCwRAt7nAJ4/JFvQN1ewPdXVzocltbEu7nhYwACguBBb jv+6Ggf8IizqfK9DDrT1d9c= =sTKj -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 4 6:38:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 5E69337B403; Sat, 4 Aug 2001 06:38:41 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: by bazooka.unixfreak.org (Postfix, from userid 1000) id 067FB3E31; Sat, 4 Aug 2001 06:38:40 -0700 (PDT) Received: from bazooka.unixfreak.org (localhost [127.0.0.1]) by bazooka.unixfreak.org (Postfix) with ESMTP id EA4053C12B; Sat, 4 Aug 2001 06:38:40 -0700 (PDT) To: Ben Smithurst Cc: arch@freebsd.org Subject: Re: Library routine to load a kld if it already isn't In-Reply-To: <20010804074928.A66860@strontium.shef.vinosystems.com>; from ben@FreeBSD.org on "Sat, 4 Aug 2001 07:49:28 +0100" Date: Sat, 04 Aug 2001 06:38:35 -0700 From: Dima Dorfman Message-Id: <20010804133840.067FB3E31@bazooka.unixfreak.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 Ben Smithurst writes: > Dima Dorfman wrote: > > > X.Sh ERRORS > > XAn attempt to load the module may fail for the following reasons: > > X.Bl -tag -width Er > > X.It Bq Er EPERM > > I think I'd prefer this section be reduced to > > kldmaybeload() may fail and set errno for any of the errors > specified for the routines modfind(2) and kldload(2). > > in the way other libc manual pages do. That way, there's just one less > place to update when additional error possibilities are added to those > functions. Adding error possibilities is a change in the interface, and shouldn't done lightly. Nonetheless, I agree with your idea in general, although the text you propose is inaccurate. It doesn't use modfind(2), it uses kldnext(2), kldfirstmod(2), modfnext(2), modstat(2), and kldload(2). Of all of those, only kldstat(2) should fail. If any of the others fail, there's either a bug in the routine, or a bug in the kernel. (One bug is known: if the module it's currently checking is unloaed before it calls modfnext(2), or the file is unloaded before it calls kldnext(2), those functions will fail with ENOENT. Now that I think about it, it might be good to document that.) Thanks for your comments. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Aug 4 12: 3:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id A803537B401 for ; Sat, 4 Aug 2001 12:03:20 -0700 (PDT) (envelope-from ben@FreeBSD.org) Received: from strontium.shef.vinosystems.com ([192.168.91.36] ident=root) by scientia.demon.co.uk with esmtp (Exim 3.30 #1) id 15T6hi-0007pq-00; Sat, 04 Aug 2001 20:03:18 +0100 Received: (from ben@localhost) by strontium.shef.vinosystems.com (8.11.4/8.11.4) id f74J3IX41536; Sat, 4 Aug 2001 20:03:18 +0100 (BST) (envelope-from ben@FreeBSD.org) X-Authentication-Warning: strontium.shef.vinosystems.com: ben set sender to ben@FreeBSD.org using -f Date: Sat, 4 Aug 2001 20:03:18 +0100 From: Ben Smithurst To: Dima Dorfman Cc: arch@freebsd.org Subject: Re: Library routine to load a kld if it already isn't Message-ID: <20010804200318.D66860@strontium.shef.vinosystems.com> References: <20010804074928.A66860@strontium.shef.vinosystems.com> <20010804133840.067FB3E31@bazooka.unixfreak.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010804133840.067FB3E31@bazooka.unixfreak.org> X-PGP-Key: http://www.smithurst.org/ben/pgp-key.txt Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dima Dorfman wrote: > Adding error possibilities is a change in the interface, and shouldn't > done lightly. Nonetheless, I agree with your idea in general, > although the text you propose is inaccurate. It doesn't use > modfind(2), it uses kldnext(2), kldfirstmod(2), modfnext(2), > modstat(2), and kldload(2). Of all of those, only kldstat(2) should > fail. Sorry, I meant modstat(), not modfind() -- I listed just those two functions since they're the only ones a failure of will result in the code returning -1 as far as I can see. --=20 Ben Smithurst / ben@FreeBSD.org FreeBSD: The Power To Serve http://www.FreeBSD.org/ --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7bEb0bPzJ+yzvRCwRAihDAJ4zQM+YUL7o8b5ZQFgL2V81LI89NgCghBLQ tz7jnfwIDVg2CVeioxE8RYw= =tLG7 -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message