From owner-freebsd-arch Sun Mar 18 0: 1:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp10.phx.gblx.net (smtp10.phx.gblx.net [206.165.6.140]) by hub.freebsd.org (Postfix) with ESMTP id 8C91037B736; Sun, 18 Mar 2001 00:01:34 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp10.phx.gblx.net (8.9.3/8.9.3) id BAA24352; Sun, 18 Mar 2001 01:01:18 -0700 Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp10.phx.gblx.net, id smtpdB8Mzia; Sun Mar 18 01:01:16 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id BAA03653; Sun, 18 Mar 2001 01:01:23 -0700 (MST) From: Terry Lambert Message-Id: <200103180801.BAA03653@usr05.primenet.com> Subject: Re: man pages To: imp@harmony.village.org (Warner Losh) Date: Sun, 18 Mar 2001 08:01:21 +0000 (GMT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), jhb@FreeBSD.ORG (John Baldwin), mjacob@feral.com (Matthew Jacob), arch@FreeBSD.ORG In-Reply-To: <200103171820.f2HIKq945996@harmony.village.org> from "Warner Losh" at Mar 17, 2001 11:20:52 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : >Just wanted to show > : >an example that needed it, not for synchronization, but to assume total > : >control of the CPU and to make everyone else wait while I do my > : >semi-time critical hardware frobbing. > : > : I agree, there are lots of applications where it is a must to be > : able to do that, and we can either provide a civilized API for it > : or suffer all the weird hacks people will implement themselves... > > My hardware was UP. I don't know what I'd want this to mean in an MP > environment. For my app, one CPU is fine (since the bus bandwidth I > use in my handsprings is minimal). This likely is the typical case. > > I have trouble thinking of why someone would want to do this on > multiple CPUs at the same time, unless it involved synchronization. My immediate question on the original "Just wanted to show..." posting was "What about SMP?". I think that there are several types of critical sections: 1) Keep this CPU from fielding interrupts 2) Keep this CPU from having to run other code (kernel preemption safe) 3) Keep the I/O bus from being used by other code, since I'm engaged in time critical work I think what you want to do is lock off interrupts from the CPU, and then lock other code out of the I/O bus until you are done programming the DMA. Given the original example code, and the anecdotal statement that "disabling interrupts worked better", I'd have to say my best guess is that your code really needed to be able to lock access to the I/O bus, as well as preventing the CPU from being forced to run other interrupt handling code (cases #1 and #2 are similar, but distinct, in that way). Setting aside the idea that you should perhaps preprogram the DMA engine as best you can ahead of time, to avoid it being nearly as time critical (during init, and again, after each interrupt handler has effective run to completion), I think this calls for _at least_ a way to disable interrupt sources seperately from CPU interrupts, and possibly a seperate method of monopolizing the I/O bus. I think if you could disable sources (on some architectures, you would have to disable all sinks, instead, just as on some, you can only disable sources, and disabling them for one CPU disables them for all), then it would make your driver work in SMP mode; so would disabling interrupts to the sink (CPU) you are currently running on plus locking access to the I/O bus against other CPUs. You could actually envision a third routine which does a "don't interrupt this CPU, and grant it monopoly I/O bus access" that uses one method on some architectures, and another method on others. PS: Is there a reason we shouldn't just adopt Sun's function names and semantics? They've paid people to look at this for a long time. I personally don't have a problem with benefitting from thousands of amn hours and millions of dollars of architecture work by professional computer scientists, at no cost... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 0:12:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id AE44037B736 for ; Sun, 18 Mar 2001 00:12:32 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2I8Eg192210; Sun, 18 Mar 2001 00:14:42 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Sun, 18 Mar 2001 00:12:05 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: 'final' man pages Cc: arch@FreeBSD.org, Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Mar-01 Matthew Jacob wrote: >> > .Sh SYNOPSIS >> > .Fd #include >> > .Ft void >> > .Fn restore_intr "intrmask_t" >> >> Should be: >> >> .Fd #include >> .Fd #include >> ... >> >> ( is an implementation detail. It should never be >> included directly.) > > Urmm.. Huh. John told me to do it! It's his fault! I'll defer to Bruce on this one, he is more of an expert in header foo. >> It's not even clear that interrupt states can be restored in a nested >> way. > > Yes. > > Bruce- the following paragrahph is really hard to parse. I *think* you're > saying that we cannot guarantee nesting. That's a fair addition. Anything > else? Hmm, as long as you pair state changes with restores you can handle nesting in the same way that spl's did, i.e.: x = intr_disable() ... y = intr_disable() .... restore_intr(y) .... restore_intr(x) will DTRT and not enable interrupts until after the second restore_intr(). You do have to pair them up much like lock acquire/releases. >> Some cases need to be handled like ithread priorities: a handler >> for a high priority interrupt may have to yield to the handler for a >> lower priority interrupt to contest a lock. This requires some non-nested >> handling of interrupt states. I discussed this with John (jhb). He was >> more pessimistic about it than me. If a machine supports an external mechanism for disabling interrupts such as a PIC mask, then we can simply disable individual interrupts that way until the ithread associated with an interrupt source completes. Note that we only really need to do this for level-triggered interrupts. If we don't have this available and are forced to (ab)use the CPU interrupt level to mask interrupts, then we instead disable all other device interrupts on this CPU when an interrupt comes in until the associated ithread finishes. >> I think things currently work on >> i386's because the interrupt state isn't all actually returned by >> save_intr() or restored by restore_intr(). Most of the state is in the >> ICU or APIC, and we depend on this because the state is a mask and not >> a level. Priority propagation is more complicated because low priority >> interrupts aren't masked while high priority ones are being handled; we >> let them occur and then mask them. If we didn't have the global state >> in the ICU/APIC, then we would have to adjust the saved state in various >> stack frames, but this is too hard. OTOH, on alphas the interrupt state >> is controlled by a level and not a mask, so lower priority interrupts >> can't occur and I think nested handling of interrupt states works right >> provided ithread priorities work right. Only the case where the interrupt >> state is a mask and is all returned by save_intr() is broken, and we don't >> support any machines that require that. Actually, all device I/O interrupts on the alpha are at the same level, so they aren't split across multiple levels. Also, we lower the IPL back to 0 before running an ithread, so that only the actual interrupt stack that schedules an ithread to run runs at a raised IPL. As they are currently implemented, *_intr() only allow one to guarantee that the current thread on the current CPU will not be preempted. It doesn't set a level of interrupts that are allowed like spl's. That is managed separately by the interrupt code. >> Bruce -- 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 Sun Mar 18 0:12:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 4DE8137B739 for ; Sun, 18 Mar 2001 00:12:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2I8Ei192214; Sun, 18 Mar 2001 00:14:44 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Sun, 18 Mar 2001 00:12:08 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: 'final' man pages Cc: arch@FreeBSD.org, Matthew Jacob Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Mar-01 Bruce Evans wrote: > On Sat, 17 Mar 2001, Matthew Jacob wrote: >> > > .Sh RETURN VALUES >> > > Returns a interrupt mask value that is to be later passed >> > state (masks and levels have very different >> > semantics >> > which should probably be opaque here; better >> > rename intrmask_t too) >> > > .Xr restore_intr 9 . >> > >> > It's not even clear that interrupt states can be restored in a nested >> > way. >> >> Yes. >> >> Bruce- the following paragrahph is really hard to parse. I *think* you're >> saying that we cannot guarantee nesting. That's a fair addition. Anything >> else? > > I think there is no problem with guaranteeing nesting in drivers if > drivers follow the rules, and this must be guaranteed so that drivers > don't have to worry about. The public interfaces that we are discussing > are mainly for drivers. If there is a problem with interrupt nesting, > then it is in the implementation of mutexes and/or ithread scheduling. > Whatever is used there need not be the same as the public interface. Actually, while *_intr() do prevent preemption, that is all they do. They do not serve to protect data, so most drivers should be using spin mutexes in these cases instead as spin mutexes both prevent preemption and protect data. If the driver just needs to prevent preemption, it can use *_intr(). If the driver just needs to protect data, it can use a sleep mutex. Basically, *_intr() should probably be used very little in a driver, except perhaps if they are used while holding a sleep lock that protects the data used in the critical section. Note, however, that *_intr() can not be used to protect data and thus are probably not suitable for most applications. -- 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 Sun Mar 18 0:18:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 1DA2437B736; Sun, 18 Mar 2001 00:18:29 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA07138; Sun, 18 Mar 2001 19:18:22 +1100 Date: Sun, 18 Mar 2001 19:18:04 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG Subject: Re: man pages t In-Reply-To: <200103180723.f2I7NY948714@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Mar 2001, Warner Losh wrote: > In message Bruce Evans writes: > : This is a good bad example. It's too late to disable interrupts in the > : interrupt handler, because the handler might not be called until long > : after the hardware asserts an interrupt (a delay of 20 msec is not > : impossible, especially in -current). > > Even for fast interrupts? On other hardware for the job I have now we > see indications that 20ms might not be unreasonable a delay (we have > interrupts going off 22x a second, which is really more like 45ms, and > we seem to be missing interrupts on a heavily loaded system). It's not nearly that bad for fast interrupts, even in -current. An interrupt latency of 20 usec is a more normal worst case in -current (it depends on the CPU and load). But in RELENG_4 the worst case is more like 2 usec provided there are no competing fast interrupts. I'm seeing large latencies for non-fast interrupts being caused by ata interrupt activity. I don't really understand them. ithread priorities should prevent them (at least for ithreads with priority higher than the ata ithread. Of course there will be very large latencies for lower priority ithreads, especially for ata drives that can't do DMA). > : In your example, if missing the window would be fatal, to work under > : FreeBSD you need to use a fast interrupt handler under FreeBSD-4.x > : or better (fast interrupt handlers are broken in -current), and > : arrange for all other fast interrupt handlers combined to not break > : the window (this probably involves not having any other active ones). > > I use a fast interrupt handler :-). I thought that disabling all > interrupts kept even other fast interrupt handlers from running. And > that was the difference between splhigh() and disable_intr(). Then the handler will start with interrupts disabled, so no interrupt disablement is necessary. It shouldn't call splhigh()/splx() anyway (NO functions may be called from fast interrupt handlers :-). In practice, calling splhigh() is harmless but calling splx() could cause panics and other problems. It's the other parts of the driver that need to disable interrupts explicitly. They really just want to lock out the fast interrupt or duplicate the environment of the fast interrupt handler (so that they can do the things that the handler does, perhaps by calling it directly). The thread that we started from is mostly about doing this less hackishly. The locking aspects are too tangled up with interrupts and other voodoo. > The window is actually fairly large to get things going (something on > the order of 500 longwords in the fifo, which gives a latency of > something like 5ms since the frames come in every 33ms (60 fields a > second is 30 frames a second and the data is squirted out such that > 500 longwords is just under 5ms of data). We had all kinds of > problems with 4.0 and non-fast interrupts on slow machines. On fast > (600MHz+) machines we could likely get away with non-fast interrupts, > but I haven't bothered to recode it since those are the only CPUs that > the client can obtain for the boards in question (don't ask me why, I > long since gave up trying to argue with them). The not-so fast interrupts in current are adequate for a laency of 5msec. I think splhigh() would have been plenty in RELENG_4, and your problem there was that splhigh() is not really a driver interface. Normal (non-clock) drivers have to have type bio, cam, net or tty and the spls for those are not high enough. > : If missing the windows wouldn't be fatal, then just use a normal > : interrupt handler and recover from errors. Fast interrupt handlers > : are too hard to use to use routinely. > > Agreed. They should be easier. But with enough patience and skill, > they can be used when you gotta have the response time. I've found > that fast interrupts work out best when you have just a circular > buffer of stuff and you don't need to do selwake from the interrupt > handler (I'm not even sure you are allowed to do selwake from a fast > interrupt handler). Right, you are not allowed to call ANY functions from a fast interrupt handler :-). An ideal fast interrupt handler does little more than `buf[bufindex++ & MASK] = inb(PORT);' Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 5:47:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E9B9837B719; Sun, 18 Mar 2001 05:47:07 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA23770; Mon, 19 Mar 2001 00:47:04 +1100 Date: Mon, 19 Mar 2001 00:46:46 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Matthew Jacob , arch@FreeBSD.org Subject: Re: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Mar 2001, John Baldwin wrote: > On 18-Mar-01 Matthew Jacob wrote: > > Bruce- the following paragrahph is really hard to parse. I *think* you're > > saying that we cannot guarantee nesting. That's a fair addition. Anything > > else? > > Hmm, as long as you pair state changes with restores you can handle nesting in > the same way that spl's did, i.e.: > > x = intr_disable() > ... > y = intr_disable() > .... > restore_intr(y) > .... > restore_intr(x) > > will DTRT and not enable interrupts until after the second restore_intr(). > You do have to pair them up much like lock acquire/releases. The problem is if interrupts are controlled by masks. A lower priority interrupt may occur while the above code is running (unless you dumb down the masks a little to give levels). The handler for this interrupt must keep it disabled and not proceed far before continuing with the above code (since the above code has higher priority). This invalidates x and y if x and y contain the mask. > >> Some cases need to be handled like ithread priorities: a handler > >> for a high priority interrupt may have to yield to the handler for a > >> lower priority interrupt to contest a lock. This requires some non-nested > >> handling of interrupt states. I discussed this with John (jhb). He was > >> more pessimistic about it than me. > > If a machine supports an external mechanism for disabling interrupts such as a > PIC mask, then we can simply disable individual interrupts that way until the > ithread associated with an interrupt source completes. Note that we only And this is what we do on i386's. > really need to do this for level-triggered interrupts. If we don't have this > available and are forced to (ab)use the CPU interrupt level to mask interrupts, > then we instead disable all other device interrupts on this CPU when an > interrupt comes in until the associated ithread finishes. We should disable precisely all the interrupts with the same or lower priority while running the ithread. > >> I think things currently work on > >> i386's because the interrupt state isn't all actually returned by > >> save_intr() or restored by restore_intr(). Most of the state is in the > >> ICU or APIC, and we depend on this because the state is a mask and not > >> a level. Priority propagation is more complicated because low priority > >> interrupts aren't masked while high priority ones are being handled; we > >> let them occur and then mask them. If we didn't have the global state > >> in the ICU/APIC, then we would have to adjust the saved state in various > >> stack frames, but this is too hard. OTOH, on alphas the interrupt state > >> is controlled by a level and not a mask, so lower priority interrupts > >> can't occur and I think nested handling of interrupt states works right > >> provided ithread priorities work right. Only the case where the interrupt > >> state is a mask and is all returned by save_intr() is broken, and we don't > >> support any machines that require that. > > Actually, all device I/O interrupts on the alpha are at the same level, so they > aren't split across multiple levels. I didn't know that the alpha was that braindamaged :-). alpha_cpu.h actually gives 2 levels of device interrupts, ALPHA_PSL_IPL_CLOCK for clocks and ALPHA_PSL_IPL_IO for other devices. > Also, we lower the IPL back to 0 before > running an ithread, so that only the actual interrupt stack that schedules an > ithread to run runs at a raised IPL. This is a bug. In general, we can't lower the IPL below the level needed to mask the interrupt that we're handling, because level-triggered interrupts will repeat endlessly. I'm not sure why this isn't fatal for alphas. It may be handled by "lazy interrupt masking" -- let the interrupt repeat and mask it properly on the first repetition so that it won't repeat again. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 9:16:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id C7EB537B718 for ; Sun, 18 Mar 2001 09:16:40 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2IHGX699051; Sun, 18 Mar 2001 09:16:33 -0800 (PST) (envelope-from obrien) Date: Sun, 18 Mar 2001 09:16:33 -0800 From: "David O'Brien" To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010318091633.B98788@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010316134349.K29888@fw.wintelcom.net> <20010316163748Z.jkh@osd.bsdi.com> <20010316164457.A57253@hub.freebsd.org> <20010316170000.R29888@fw.wintelcom.net> <20010316174303.A9267@dragon.nuxi.com> <20010317105624.A29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010317105624.A29888@fw.wintelcom.net>; from bright@wintelcom.net on Sat, Mar 17, 2001 at 10:56:24AM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 17, 2001 at 10:56:24AM -0800, Alfred Perlstein wrote: > * David O'Brien [010316 17:43] wrote: > > On Fri, Mar 16, 2001 at 05:00:00PM -0800, Alfred Perlstein wrote: > > > Or teach the ports committers the way to bump newver.sh themselves. > > > A minor step that should be trivial for them to do. > > > > That is an inappropriate response, from someone that hacks their kernel > > daily. > > I'm not sure what you mean. I mean your responce of telling ports maintainers to hack their kernel sources (admittedly a small hack), may be out of the scope of what they care to do. How does CVSup in checkout mode handle local mods? > This whole -BETA topic is about us getting so removed from the > users that we don't realize when we do evil things to them. You mean about our non-RELEASE RELENG_4 users getting so removed from us, they read email lists, FAQs, or pay any attention to how things work here. ;-) -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 9:21:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 88A0137B718 for ; Sun, 18 Mar 2001 09:21:46 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2IHLaE99088; Sun, 18 Mar 2001 09:21:36 -0800 (PST) (envelope-from obrien) Date: Sun, 18 Mar 2001 09:21:35 -0800 From: "David O'Brien" To: Wes Peters Cc: arch@FreeBSD.ORG Subject: Re: More BETA evilness Re: BETA induced nervousness Message-ID: <20010318092135.C98788@dragon.nuxi.com> Reply-To: arch@FreeBSD.ORG References: <20010316134113.I29888@fw.wintelcom.net> <200103162300.QAA17472@usr07.primenet.com> <20010316155307.A41507@citusc17.usc.edu> <3AB3779E.6A448E9@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AB3779E.6A448E9@softweyr.com>; from wes@softweyr.com on Sat, Mar 17, 2001 at 07:41:34AM -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 X-Loop: FreeBSD.ORG On Sat, Mar 17, 2001 at 07:41:34AM -0700, Wes Peters wrote: > c) "BETA" is not really "STABLE". During the BETA phase, we often > introduce short-term instability in the process of adding some > functionality for the next release. This is a necessary and > desirable phase of development, and lasts for a short period of > time. "BETA" _is_ really "STABLE". short-term instability can be introduced at *ANY* time when doing MFCs. It just happens to occur more often near release time. Some have proclaimed they will start doing monthly MFC parties. We'll see if that happens, but the same "short-term instability" will then occur at different times. Maybe we shouldn't be calling it -STABLE at all. Maybe it should be: 4.3-BETA -> 4.3-RELEASE -> 4.4-BETA -> 4.4-RELEASE -> etc... then if our CVSupin' users won't bother to understand what using the RELENG_4 branch means. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 9:50:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 58C2037B718; Sun, 18 Mar 2001 09:50:35 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2IHoPA28440; Sun, 18 Mar 2001 09:50:25 -0800 (PST) Date: Sun, 18 Mar 2001 09:50:24 -0800 From: Alfred Perlstein To: Jordan Hubbard Cc: wes@softweyr.com, arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: [patch] Re: NO MORE '-BETA' Message-ID: <20010318095024.H29888@fw.wintelcom.net> References: <20010316071040.V29888@fw.wintelcom.net> <20010316104124Z.jkh@osd.bsdi.com> <3AB2E8DE.CEBC23D9@softweyr.com> <20010317190007Z.jkh@osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010317190007Z.jkh@osd.bsdi.com>; from jkh@osd.bsdi.com on Sat, Mar 17, 2001 at 07:00:07PM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Jordan Hubbard [010317 19:01] wrote: > > And I though bikeshed arguments were stoopid. > > No, this is without question the stupidest thread on record and a > gross abuse of the "arch" mailing list. Special thanks must go to > Alfred Perlstein for raising this issue to the point of absurdity and > hijacking god-only-knows how many hours of developer time in debating > this whole thing. With friends like this, who needs competition from > Linux? ;) Bite me libdialog boy. This is somewhat tested, what do you think? Will it screw up the release target? I can probably make a delta for -BETA (:P) as well. Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.193 diff -u -r1.193 Makefile.inc1 --- Makefile.inc1 2001/03/02 16:52:06 1.193 +++ Makefile.inc1 2001/03/18 17:46:21 @@ -301,7 +301,7 @@ # # Installs everything compiled by a 'buildworld'. # -installworld: +installworld: verscheck mkdir -p ${INSTALLTMP} for prog in [ awk cat chflags chmod chown date echo egrep find grep \ install ln make makewhatis mtree mv perl rm sed sh sysctl \ @@ -440,7 +440,7 @@ # # Install the kernel defined by INSTALLKERNEL # -installkernel: +installkernel: verscheck cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \ ${CROSSENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} install reinstallkernel: @@ -801,5 +801,24 @@ .endfor par-${__target}: ${SUBDIR:S/$/.${__target}__D/} .endfor + +verscheck: +.if !defined(NOVERSCHECK) + @uname=`uname -r` ;\ + sysname=`uname -s` ;\ + newvers=`sh ${.CURDIR}/sys/conf/newvers.sh -r` ;\ + if [ $$uname = $$newvers ] ; then \ + exit 0; \ + fi; \ + echo "--------------------------------------------------------------"; \ + echo ">>> WARNING"; \ + echo ">>> You are currently using $$sysname $$uname."; \ + echo ">>> If you install you will be upgrading" \ + "to $$sysname $$newvers."; \ + echo ">>> If you're sure you want to upgrade add 'NOVERSCHECK=YES'"; \ + echo ">>> to your make command or /etc/make.conf"; \ + echo "--------------------------------------------------------------"; \ + exit 1; +.endif .include Index: release/Makefile =================================================================== RCS file: /home/ncvs/src/release/Makefile,v retrieving revision 1.596 diff -u -r1.596 Makefile --- release/Makefile 2001/03/07 07:39:32 1.596 +++ release/Makefile 2001/03/18 17:40:41 @@ -40,6 +40,7 @@ .endif KERNCONF=GENERIC +NOVERSCHECK=YES # If you want to pass flags to the world build such as -j X, use # WORLD_FLAGS. Similarly, you can specify make flags for kernel Index: sys/conf//newvers.sh =================================================================== RCS file: /home/ncvs/src/sys/conf/newvers.sh,v retrieving revision 1.47 diff -u -r1.47 newvers.sh --- sys/conf//newvers.sh 2001/03/02 16:52:13 1.47 +++ sys/conf//newvers.sh 2001/03/18 17:47:24 @@ -40,6 +40,11 @@ RELEASE="${REVISION}-${BRANCH}" VERSION="${TYPE} ${RELEASE}" +if [ "$1" = "-r" ]; then + echo $RELEASE + exit 0 +fi + if [ "X${PARAMFILE}" != "X" ]; then RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \ ${PARAMFILE}) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 10:11:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 033CE37B718; Sun, 18 Mar 2001 10:11:53 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f2IIBpd28945; Sun, 18 Mar 2001 10:11:51 -0800 (PST) Date: Sun, 18 Mar 2001 10:11:51 -0800 From: Alfred Perlstein To: Jordan Hubbard Cc: wes@softweyr.com, arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: [patch] Re: NO MORE '-BETA' Message-ID: <20010318101151.I29888@fw.wintelcom.net> References: <20010316071040.V29888@fw.wintelcom.net> <20010316104124Z.jkh@osd.bsdi.com> <3AB2E8DE.CEBC23D9@softweyr.com> <20010317190007Z.jkh@osd.bsdi.com> <20010318095024.H29888@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010318095024.H29888@fw.wintelcom.net>; from bright@wintelcom.net on Sun, Mar 18, 2001 at 09:50:24AM -0800 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Alfred Perlstein [010318 09:50] wrote: > * Jordan Hubbard [010317 19:01] wrote: > > > And I though bikeshed arguments were stoopid. > > > > No, this is without question the stupidest thread on record and a > > gross abuse of the "arch" mailing list. Special thanks must go to > > Alfred Perlstein for raising this issue to the point of absurdity and > > hijacking god-only-knows how many hours of developer time in debating > > this whole thing. With friends like this, who needs competition from > > Linux? ;) > > Bite me libdialog boy. > > This is somewhat tested, what do you think? Will it screw up the > release target? To test this, you want to just bump the version in sys/conf/newvers.sh and it should trip the warning message. > > I can probably make a delta for -BETA (:P) as well. > > Index: Makefile.inc1 > =================================================================== > RCS file: /home/ncvs/src/Makefile.inc1,v > retrieving revision 1.193 > diff -u -r1.193 Makefile.inc1 > --- Makefile.inc1 2001/03/02 16:52:06 1.193 > +++ Makefile.inc1 2001/03/18 17:46:21 > @@ -301,7 +301,7 @@ > # > # Installs everything compiled by a 'buildworld'. > # > -installworld: > +installworld: verscheck > mkdir -p ${INSTALLTMP} > for prog in [ awk cat chflags chmod chown date echo egrep find grep \ > install ln make makewhatis mtree mv perl rm sed sh sysctl \ > @@ -440,7 +440,7 @@ > # > # Install the kernel defined by INSTALLKERNEL > # > -installkernel: > +installkernel: verscheck > cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \ > ${CROSSENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} install > reinstallkernel: > @@ -801,5 +801,24 @@ > .endfor > par-${__target}: ${SUBDIR:S/$/.${__target}__D/} > .endfor > + > +verscheck: > +.if !defined(NOVERSCHECK) > + @uname=`uname -r` ;\ > + sysname=`uname -s` ;\ > + newvers=`sh ${.CURDIR}/sys/conf/newvers.sh -r` ;\ > + if [ $$uname = $$newvers ] ; then \ > + exit 0; \ > + fi; \ > + echo "--------------------------------------------------------------"; \ > + echo ">>> WARNING"; \ > + echo ">>> You are currently using $$sysname $$uname."; \ > + echo ">>> If you install you will be upgrading" \ > + "to $$sysname $$newvers."; \ > + echo ">>> If you're sure you want to upgrade add 'NOVERSCHECK=YES'"; \ > + echo ">>> to your make command or /etc/make.conf"; \ > + echo "--------------------------------------------------------------"; \ > + exit 1; > +.endif > > .include > Index: release/Makefile > =================================================================== > RCS file: /home/ncvs/src/release/Makefile,v > retrieving revision 1.596 > diff -u -r1.596 Makefile > --- release/Makefile 2001/03/07 07:39:32 1.596 > +++ release/Makefile 2001/03/18 17:40:41 > @@ -40,6 +40,7 @@ > .endif > > KERNCONF=GENERIC > +NOVERSCHECK=YES > > # If you want to pass flags to the world build such as -j X, use > # WORLD_FLAGS. Similarly, you can specify make flags for kernel > Index: sys/conf//newvers.sh > =================================================================== > RCS file: /home/ncvs/src/sys/conf/newvers.sh,v > retrieving revision 1.47 > diff -u -r1.47 newvers.sh > --- sys/conf//newvers.sh 2001/03/02 16:52:13 1.47 > +++ sys/conf//newvers.sh 2001/03/18 17:47:24 > @@ -40,6 +40,11 @@ > RELEASE="${REVISION}-${BRANCH}" > VERSION="${TYPE} ${RELEASE}" > > +if [ "$1" = "-r" ]; then > + echo $RELEASE > + exit 0 > +fi > + > if [ "X${PARAMFILE}" != "X" ]; then > RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \ > ${PARAMFILE}) > > > > -- > -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 10:24:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from localhost.grauel.com (usr1-37.mintel.net [63.81.123.52]) by hub.freebsd.org (Postfix) with ESMTP id 6860637B718; Sun, 18 Mar 2001 10:24:34 -0800 (PST) (envelope-from rjk@grauel.com) Received: (from rjk@localhost) by localhost.grauel.com (8.11.3/8.11.1) id f2IIOLx75539; Sun, 18 Mar 2001 13:24:21 -0500 (EST) (envelope-from rjk) From: Richard J Kuhns MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15028.64849.513135.56525@localhost.grauel.com> Date: Sun, 18 Mar 2001 13:24:17 -0500 To: Alfred Perlstein Cc: Jordan Hubbard , wes@softweyr.com, arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: [patch] Re: NO MORE '-BETA' In-Reply-To: <20010318095024.H29888@fw.wintelcom.net> References: <20010316071040.V29888@fw.wintelcom.net> <20010316104124Z.jkh@osd.bsdi.com> <3AB2E8DE.CEBC23D9@softweyr.com> <20010317190007Z.jkh@osd.bsdi.com> <20010318095024.H29888@fw.wintelcom.net> X-Mailer: VM 6.90 under 21.1 (patch 13) "Crater Lake" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: ... > This is somewhat tested, what do you think? Will it screw up the > release target? > > I can probably make a delta for -BETA (:P) as well. > [ patch deleted ] Speaking as someone who just _uses_ FreeBSD for Real Work (and has been for quite a few years), I must say I find this entire discussion ludicrous. If you feel like you have to change something, though, this is as good as anything else as long as I can put something in make.conf so I can ignore it. Regards... -- Richard Kuhns rjk@grauel.com PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Road x319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 12:29:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 1872937B719; Sun, 18 Mar 2001 12:29:21 -0800 (PST) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f2IKTGR02601; Sun, 18 Mar 2001 12:29:16 -0800 (PST) (envelope-from jkh@osd.bsdi.com) To: bright@wintelcom.net Cc: wes@softweyr.com, arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: [patch] Re: NO MORE '-BETA' In-Reply-To: <20010318095024.H29888@fw.wintelcom.net> References: <3AB2E8DE.CEBC23D9@softweyr.com> <20010317190007Z.jkh@osd.bsdi.com> <20010318095024.H29888@fw.wintelcom.net> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010318122916G.jkh@osd.bsdi.com> Date: Sun, 18 Mar 2001 12:29:16 -0800 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 10 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I still have a hard time believing that users need THIS much protection from themselves and can't help but recall the whole 50's bomb shelter phenomenon where people were digging up their back yards and building concrete blockhouses just because the government had them whipped up into a full-bore "We're all gonna DIE" frenzy. Can we just END this stupid thread already? Talk about an over-reaction leading to a serious cyclone in a teapoot.... - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 15: 8:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 3AF5437B71B for ; Sun, 18 Mar 2001 15:08:39 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id QAA17916; Sun, 18 Mar 2001 16:05:15 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAtlaO8I; Sun Mar 18 16:05:07 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA18049; Sun, 18 Mar 2001 16:08:26 -0700 (MST) From: Terry Lambert Message-Id: <200103182308.QAA18049@usr05.primenet.com> Subject: Re: NO MORE '-BETA' To: arch@FreeBSD.ORG Date: Sun, 18 Mar 2001 23:08:25 +0000 (GMT) Cc: bright@wintelcom.net (Alfred Perlstein) In-Reply-To: <20010318091633.B98788@dragon.nuxi.com> from "David O'Brien" at Mar 18, 2001 09:16:33 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > That is an inappropriate response, from someone that hacks their kernel > > > daily. > > > > I'm not sure what you mean. > > I mean your responce of telling ports maintainers to hack their kernel > sources (admittedly a small hack), may be out of the scope of what they > care to do. How does CVSup in checkout mode handle local mods? Its head explodes. CVSup needs to be modified to let you tell it to automatically CVSup onto a vendor branch, so that what's in the remote repository is stored locally in a vendor branch. This would get rid of the conflicts caused by local modifications, and you could do local "merge to head" to update local sources. Unfortunately, it's very hard to get into the CVSup sources because of the language they are written in, and the tools and memory normally required to run them. > > This whole -BETA topic is about us getting so removed from the > > users that we don't realize when we do evil things to them. > > You mean about our non-RELEASE RELENG_4 users getting so removed from us, > they read email lists, FAQs, or pay any attention to how things work > here. ;-) Depends on your point of view; whose convenience is more important, the programmers', or the thousands of users per programmer who use the resulting code? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 15:30:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 1711A37B718 for ; Sun, 18 Mar 2001 15:30:42 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2INUYq19903; Sun, 18 Mar 2001 15:30:34 -0800 (PST) (envelope-from obrien) Date: Sun, 18 Mar 2001 15:30:33 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG, Alfred Perlstein Subject: Re: NO MORE '-BETA' Message-ID: <20010318153033.A19886@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010318091633.B98788@dragon.nuxi.com> <200103182308.QAA18049@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103182308.QAA18049@usr05.primenet.com>; from tlambert@primenet.com on Sun, Mar 18, 2001 at 11:08:25PM +0000 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 X-Loop: FreeBSD.ORG On Sun, Mar 18, 2001 at 11:08:25PM +0000, Terry Lambert wrote: > > care to do. How does CVSup in checkout mode handle local mods? > > Its head explodes. "check out" mode -- ie, _NOT_ CVSuping the repo, just doing the equiv of a ``cvs co''. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 15:44:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 6543A37B718; Sun, 18 Mar 2001 15:44:11 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id QAA13006; Sun, 18 Mar 2001 16:38:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAAP4a4vz; Sun Mar 18 16:38:21 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA18756; Sun, 18 Mar 2001 16:43:55 -0700 (MST) From: Terry Lambert Message-Id: <200103182343.QAA18756@usr05.primenet.com> Subject: Re: NO MORE '-BETA' To: obrien@FreeBSD.ORG Date: Sun, 18 Mar 2001 23:43:54 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG, bright@wintelcom.net (Alfred Perlstein) In-Reply-To: <20010318153033.A19886@dragon.nuxi.com> from "David O'Brien" at Mar 18, 2001 03:30:33 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > care to do. How does CVSup in checkout mode handle local mods? > > > > Its head explodes. > > "check out" mode -- ie, _NOT_ CVSuping the repo, just doing the equiv of > a ``cvs co''. Its head still explodes because of the greedy diff algorithm. Using "cvs diff -rx.x -rHEAD | patch" often works around the problem, but you still have to dick with it. Believe me: I've been fighting this problem since 1994. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 16: 6:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 3E9EF37B718; Sun, 18 Mar 2001 16:06:31 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id TAA44321; Sun, 18 Mar 2001 19:06:26 -0500 (EST) Message-Id: <200103190006.TAA44321@cs.rpi.edu> To: Robert Watson Cc: "David E. Cross" , freebsd-arch@freebsd.org, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' In-Reply-To: Message from Robert Watson of "Sat, 17 Mar 2001 12:20:38 EST." Date: Sun, 18 Mar 2001 19:06:25 -0500 From: "David E. Cross" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I think you're describing the direction that ucred is already moving in. > Take a look at struct ucred in -CURRENT, where things like the jail > pointer are now there instead of directly under struct proc. If you look > at the various POSIX.1e capability and MAC patches, you'll see that they > introduce new stuff in ucred. I actually submitted patches years ago to > add a extension field to proc, but the place to put it is really ucred. > However, you run into conflicts concerning owners of the extension field > -- I also have fairly extensive patches underway that make ucred run-time > extensible more generally, but they're at least 8 - 12 months away from > being ready to integrate because we need to do substantial performance > analysis, need better support for run-time extension and ownership, etc. Actually, that most recent change is exactly the opposite direction that I am looking to go, that was a direct change to ucred itself, so any of the userland programs that link against libkvm need to be recompiled, etc because the size of the structure changed. Also that increases the size of the proc structure for everyone (even those of us not using jail). If we extend this and have every auth chuck its own data directly into the proc like this the structure and book-keeping are going to grow to be huge, and most us us are only ever going to use one or 2 of them anyway. (Yes, I know the ucred and pcred are only links into the proc structure, so the proc structure itself doesn't change size, but if there is some program out there (lsof perhaps?) that looks at the data, it will get confused; and it is more data the kernel has to move around, even if it is totally unused) What I want to see happen is the cred strucutures become meta-structures. They have no data in themselves, but they point to data. Thus I can add a new authentication/authorization method as a module without recompiling the kernel (indeed if this is inhouse, proprietary code, I can release binaries only and not need to sync up my credential information with the rest of the world). Also each process only has the information associated with it that it really needs. If you form a jail(8) (I admit I am going out quite on a limb here, since I don't know how the jail code works ;) then a "CRED_JAIL" struct gets added to the table for that process and only the processes within the jail have it. Now, someone in the jail decides to use CIFS, that cred is added on, etc. It grows (and shrinks) as needed. There is additional overhead in having the additional pointers/indirection. I think this is "ok" for a number of reasons. First, 99.9999% of everything will be based on "CRED_UNIX", which one can guarantee will be the first entry in the list: all credential information is inherited from the parent (via fork, and modified later with sycalls such as set??id()/exec()), the parent of everything is init, which will only have CRED_UNIX available to it (as setup by the kernel). So, the majority of requests will just need to go through one lookup and not need to iterate through the entire list. With appropriate data sharing (this gets very tricky for some forms of authentication, which is why I think a cred_flags field may be desired to control how some entries handle things like exec() and fork()) there will not be any additional data copies unless explicitly asked for via a syscall to change the credentials (this is done now even from what I can tell). Finally, I can see some of the routines using a caching mechanism if they need additional performance, or impliment the entire thing as a hash, but I don't think that will be a problem given the very few authentications that one will use at any single time and the relative infrequency that they are actually checked. Finally, and in summary :) I think this is a good idea and the way-to-go just for the ideals of modularization and data-hiding. -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 16: 7:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 976A937B719 for ; Sun, 18 Mar 2001 16:07:18 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2J07Fq20248; Sun, 18 Mar 2001 16:07:15 -0800 (PST) (envelope-from obrien) Date: Sun, 18 Mar 2001 16:07:15 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010318160714.A20229@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010318153033.A19886@dragon.nuxi.com> <200103182343.QAA18756@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103182343.QAA18756@usr05.primenet.com>; from tlambert@primenet.com on Sun, Mar 18, 2001 at 11:43:54PM +0000 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 X-Loop: FreeBSD.ORG On Sun, Mar 18, 2001 at 11:43:54PM +0000, Terry Lambert wrote: > > > > care to do. How does CVSup in checkout mode handle local mods? > > > > > > Its head explodes. > > > > "check out" mode -- ie, _NOT_ CVSuping the repo, just doing the equiv of > > a ``cvs co''. > > Its head still explodes because of the greedy diff algorithm. > Using "cvs diff -rx.x -rHEAD | patch" often works around the > problem, but you still have to dick with it. Uh.. Terry how in the world are you going to use ``cvs'' to do *anything* when you will not have any ,v files (ie, the repo) present? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 16: 9:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id A0E9137B71A for ; Sun, 18 Mar 2001 16:09:16 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2J0BS195723; Sun, 18 Mar 2001 16:11:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Sun, 18 Mar 2001 16:08:47 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: 'final' man pages Cc: arch@FreeBSD.org, Matthew Jacob Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18-Mar-01 Bruce Evans wrote: > On Sun, 18 Mar 2001, John Baldwin wrote: > >> On 18-Mar-01 Matthew Jacob wrote: >> > Bruce- the following paragrahph is really hard to parse. I *think* you're >> > saying that we cannot guarantee nesting. That's a fair addition. Anything >> > else? >> >> Hmm, as long as you pair state changes with restores you can handle nesting >> in >> the same way that spl's did, i.e.: >> >> x = intr_disable() >> ... >> y = intr_disable() >> .... >> restore_intr(y) >> .... >> restore_intr(x) >> >> will DTRT and not enable interrupts until after the second restore_intr(). >> You do have to pair them up much like lock acquire/releases. > > The problem is if interrupts are controlled by masks. A lower priority > interrupt may occur while the above code is running (unless you dumb down > the masks a little to give levels). The handler for this interrupt must > keep it disabled and not proceed far before continuing with the above > code (since the above code has higher priority). This invalidates x and > y if x and y contain the mask. They won't be the same masks. Well, even if they are, you would just have intr_disable() disable all interrupts, then no further interrupts can trigger that might affect the masks. The point of intr_disable() is that the masks can't change because we can't be preempted. Having an interrupt come in is preemption, and this API explicitly prevents that. Having critcal_enter()/critical_exit() might be better names for this. >> If a machine supports an external mechanism for disabling interrupts such as >> a >> PIC mask, then we can simply disable individual interrupts that way until >> the >> ithread associated with an interrupt source completes. Note that we only > > And this is what we do on i386's. And alpha's. >> really need to do this for level-triggered interrupts. If we don't have >> this >> available and are forced to (ab)use the CPU interrupt level to mask >> interrupts, >> then we instead disable all other device interrupts on this CPU when an >> interrupt comes in until the associated ithread finishes. > > We should disable precisely all the interrupts with the same or lower > priority while running the ithread. Errrm, what about a MP system that wires all interrupts to one processor (I think some alphas may be this brain-damaged) we would want lower priority interrupts to fire so that their threads would be scheduled and then picked up by another CPU and run. Ithread priorities will ensure that ithreads are processed in the right order. No hardware masking is needed. >> Actually, all device I/O interrupts on the alpha are at the same level, so >> they >> aren't split across multiple levels. > > I didn't know that the alpha was that braindamaged :-). alpha_cpu.h actually > gives 2 levels of device interrupts, ALPHA_PSL_IPL_CLOCK for clocks and > ALPHA_PSL_IPL_IO for other devices. Well, ALPHA_PSL_IPL_CLOCK is just for the CPU clock. Other clock interrupts suck as those from mcclock0 are at IPL_IO, and currently all threaded interrupts on the alpha are at IPL_IO. >> Also, we lower the IPL back to 0 before >> running an ithread, so that only the actual interrupt stack that schedules >> an >> ithread to run runs at a raised IPL. > > This is a bug. In general, we can't lower the IPL below the level > needed to mask the interrupt that we're handling, because level-triggered > interrupts will repeat endlessly. I'm not sure why this isn't fatal > for alphas. It may be handled by "lazy interrupt masking" -- let the > interrupt repeat and mask it properly on the first repetition so that > it won't repeat again. We mask the interrupts in the PIC just like on x86, otherwise a PCI interrupt can cause problems because it is level triggered. In theory we don't even need to mask edge triggered interrupts at all as all that would happen is that the ithread's it_need bit would get set again if it is already running. > Bruce -- 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 Sun Mar 18 16:13:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 1A29237B719; Sun, 18 Mar 2001 16:13:18 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id RAA04852; Sun, 18 Mar 2001 17:09:56 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAArbaGCj; Sun Mar 18 17:09:54 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id RAA19381; Sun, 18 Mar 2001 17:13:12 -0700 (MST) From: Terry Lambert Message-Id: <200103190013.RAA19381@usr05.primenet.com> Subject: Re: NO MORE '-BETA' To: obrien@FreeBSD.ORG Date: Mon, 19 Mar 2001 00:13:12 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <20010318160714.A20229@dragon.nuxi.com> from "David O'Brien" at Mar 18, 2001 04:07:15 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > care to do. How does CVSup in checkout mode handle local mods? > > > > > > > > Its head explodes. > > > > > > "check out" mode -- ie, _NOT_ CVSuping the repo, just doing the equiv of > > > a ``cvs co''. > > > > Its head still explodes because of the greedy diff algorithm. > > Using "cvs diff -rx.x -rHEAD | patch" often works around the > > problem, but you still have to dick with it. > > Uh.. Terry how in the world are you going to use ``cvs'' to do *anything* > when you will not have any ,v files (ie, the repo) present? I don't understand the question. How do you not have the repository present after running CVSup? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 16:18:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id DFEA037B718 for ; Sun, 18 Mar 2001 16:18:51 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2J0Inm20398; Sun, 18 Mar 2001 16:18:49 -0800 (PST) (envelope-from obrien) Date: Sun, 18 Mar 2001 16:18:49 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010318161849.A20382@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010318160714.A20229@dragon.nuxi.com> <200103190013.RAA19381@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103190013.RAA19381@usr05.primenet.com>; from tlambert@primenet.com on Mon, Mar 19, 2001 at 12:13:12AM +0000 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 X-Loop: FreeBSD.ORG On Mon, Mar 19, 2001 at 12:13:12AM +0000, Terry Lambert wrote: > I don't understand the question. How do you not have the repository > present after running CVSup? Terry, RTFM!! Search for the keyword _checkout_ mode, which I've clearly written in each time. Do you not know about this CVSup feature?? -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 16:27:56 2001 Delivered-To: freebsd-arch@freebsd.org Received: from picnic.chuckr.org (picnic.chuckr.org [216.254.96.118]) by hub.freebsd.org (Postfix) with ESMTP id A0B8137B718; Sun, 18 Mar 2001 16:27:51 -0800 (PST) (envelope-from chuckr@picnic.chuckr.org) Received: from localhost (chuckr@localhost) by picnic.chuckr.org (8.11.3/8.11.3) with ESMTP id f2J1T6C27200; Sun, 18 Mar 2001 20:29:07 -0500 (EST) (envelope-from chuckr@picnic.chuckr.org) Date: Sun, 18 Mar 2001 20:29:06 -0500 (EST) From: Chuck Robey To: Terry Lambert Cc: arch@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: NO MORE '-BETA' In-Reply-To: <200103190013.RAA19381@usr05.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Mar 2001, Terry Lambert wrote: > > > > > > care to do. How does CVSup in checkout mode handle local mods? > > > > > > > > > > Its head explodes. > > > > > > > > "check out" mode -- ie, _NOT_ CVSuping the repo, just doing the equiv of > > > > a ``cvs co''. > > > > > > Its head still explodes because of the greedy diff algorithm. > > > Using "cvs diff -rx.x -rHEAD | patch" often works around the > > > problem, but you still have to dick with it. > > > > Uh.. Terry how in the world are you going to use ``cvs'' to do *anything* > > when you will not have any ,v files (ie, the repo) present? > > I don't understand the question. How do you not have the repository > present after running CVSup? Not to embarrass you, Terry, but *most* folks (not you or me, but still most folks) don't get the cvs dist, they check out the sources only. You know where the config file says "default release:"? You stuck cvs in there, but most folks stick ".". Your request would be a *wonderful* thing to have ... I want it *badly* at my own company (div of Ericsson) but unfortunately, David's right here. BTW, to net friends who may have noticed my absence, I've finally learned kernel coding (with a vengeance!) ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@chuckr.org | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 17:28:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 37A7E37B719; Sun, 18 Mar 2001 17:28:44 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id SAA07392; Sun, 18 Mar 2001 18:22:36 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpdAAAv0ayyo; Sun Mar 18 18:22:27 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA20941; Sun, 18 Mar 2001 18:28:29 -0700 (MST) From: Terry Lambert Message-Id: <200103190128.SAA20941@usr05.primenet.com> Subject: Re: NO MORE '-BETA' To: obrien@FreeBSD.ORG Date: Mon, 19 Mar 2001 01:28:29 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), arch@FreeBSD.ORG In-Reply-To: <20010318161849.A20382@dragon.nuxi.com> from "David O'Brien" at Mar 18, 2001 04:18:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I don't understand the question. How do you not have the repository > > present after running CVSup? > > Terry, RTFM!! > > Search for the keyword _checkout_ mode, which I've clearly written in > each time. Do you not know about this CVSup feature?? Mea culpa. I never used that mode. I rather expected that no one would need such a thing, since anoncvs is supported. I generally get the whole tree locally, and then checkout from that. I imagine that if you used the checkout mode in CVSup, it would stomp your local changes, rather than causing a conflict; that's actually _worse_ than what I described. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 18:39:45 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 B416E37B719 for ; Sun, 18 Mar 2001 18:39:42 -0800 (PST) (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.1/8.11.1) with SMTP id f2J2d5h51092; Sun, 18 Mar 2001 21:39:05 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 18 Mar 2001 21:39:05 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "David E. Cross" Cc: freebsd-arch@freebsd.org Subject: Re: idle wonderings about 'struct pcred' In-Reply-To: <200103190006.TAA44321@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Mar 2001, David E. Cross wrote: > What I want to see happen is the cred strucutures become meta-structures. > They have no data in themselves, but they point to data. Thus I can add This is almost precisely what [is being / has been] implemented. However, there's substantially more involved here in getting the details right, including the goal of not dramatically increasing the performance cost by adding several levels of indirection and abstraction, as well as the significantly complex task of abstracting not just the credentials, but also the access control checks, credential management calls, persistent protection mechanisms, etc. We plan to spend about the next 18 months looking at how best to implement this, using improved modularity in the credential/labeling/authorization mechanism to improve the assurance properties of the code, etc. There's a lot of work to getting this right. The first steps have consisted of moving existing authorization structures into struct ucred (such as the jail data, a change that has occurred in -CURRENT but not -STABLE), allowing the kernel ucred structure to be different from the userland ABI ucred, improving security abstractions and consistency, improving kernel object labeling, and implementing new security models so that we know the basic requirements for a more general mechanism. Generally speaking it's bad to come up with new abstractions without having a fair number of examples from which to abstract, and if the goal here is extensibility *beyond* the basic UNIX credential types, then we need to have implementations of other types to work from (you can find implementations of three MAC schemes and process capabilities on the TrustedBSD site). BTW, the cost of having a cleanly abstracted credential interface is *far* higher than the cost of the current jail pointer on each process. :-) Also, we need a number of the serious structural changes associated with SMPng (such as synchronization primitives and proc locking) to be finished before we can do a lot of this work. We're targetting a modular and general authorization framework at FreeBSD 6.0-RELEASE, with the goal of having run-time pluggable support for a number of these security add-ons. 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 Sun Mar 18 18:46:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id DE6CD37B719; Sun, 18 Mar 2001 18:46:20 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (bill.cs.rpi.edu [128.213.2.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA48006; Sun, 18 Mar 2001 21:46:18 -0500 (EST) Message-Id: <200103190246.VAA48006@cs.rpi.edu> To: Robert Watson Cc: "David E. Cross" , freebsd-arch@freebsd.org, crossd@cs.rpi.edu Subject: Re: idle wonderings about 'struct pcred' In-Reply-To: Message from Robert Watson of "Sun, 18 Mar 2001 21:39:05 EST." Date: Sun, 18 Mar 2001 21:46:18 -0500 From: "David E. Cross" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ahh... Most excellent :) [cost of jail vs. proper abstraction]: *nod*, of course, but if you keep adding on additional auth types like that, the balance will tip. Certainly, the only way this makes any sense is if the goal is to go beyond traditional unix authentication and authorization. Well, so long as this is already in progress... I think I'll just sit back and watch ;) -- David Cross | email: crossd@cs.rpi.edu Lab Director | Rm: 308 Lally Hall Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 21:51:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4F46F37B71A; Sun, 18 Mar 2001 21:51:21 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id QAA32578; Mon, 19 Mar 2001 16:51:17 +1100 Date: Mon, 19 Mar 2001 16:50:59 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.org, Matthew Jacob Subject: Re: 'final' man pages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Mar 2001, John Baldwin wrote: > On 18-Mar-01 Bruce Evans wrote: > > On Sun, 18 Mar 2001, John Baldwin wrote: > > > >> On 18-Mar-01 Matthew Jacob wrote: > >> > Bruce- the following paragrahph is really hard to parse. I *think* you're > >> > saying that we cannot guarantee nesting. That's a fair addition. Anything > >> > else? > >> > >> Hmm, as long as you pair state changes with restores you can handle nesting > >> in > >> the same way that spl's did, i.e.: > >> > >> x = intr_disable() > >> ... > >> y = intr_disable() > >> .... > >> restore_intr(y) > >> .... > >> restore_intr(x) > >> > >> will DTRT and not enable interrupts until after the second restore_intr(). > >> You do have to pair them up much like lock acquire/releases. > > > > The problem is if interrupts are controlled by masks. A lower priority > > interrupt may occur while the above code is running (unless you dumb down > > the masks a little to give levels). The handler for this interrupt must > > keep it disabled and not proceed far before continuing with the above > > code (since the above code has higher priority). This invalidates x and > > y if x and y contain the mask. > > They won't be the same masks. Well, even if they are, you would just have > intr_disable() disable all interrupts, then no further interrupts can trigger > that might affect the masks. The point of intr_disable() is that the masks > can't change because we can't be preempted. Having an interrupt come in is > preemption, and this API explicitly prevents that. Having > critcal_enter()/critical_exit() might be better names for this. Oops. I was thinking of spls for some reason. > >> If a machine supports an external mechanism for disabling interrupts such as > >> a > >> PIC mask, then we can simply disable individual interrupts that way until > >> the > >> ithread associated with an interrupt source completes. Note that we only > > > > And this is what we do on i386's. > > And alpha's. I couldn't find where this is done on alphas. I asked you in private mail, but you didn't reply on this point (although you replied on many others, thanks :). Anyway, there must be an external mechanism for the SMP case to work right. An internal (per-CPU) mechanism just can't be used to control other CPUs, except grossly and inefficiently by propagating the internal mechanism to all CPUs, or by halting or spinning all CPUs except the one which took the interrupt. So the rest of this discussion only applies to single-CPU systems with no external mechanism. The internal mechanism would probably look much like an spl mechanism, so it is inherently mismatched with our SMP-friendly mechanisms. > >> really need to do this for level-triggered interrupts. If we don't have > >> this > >> available and are forced to (ab)use the CPU interrupt level to mask > >> interrupts, > >> then we instead disable all other device interrupts on this CPU when an > >> interrupt comes in until the associated ithread finishes. > > > > We should disable precisely all the interrupts with the same or lower > > priority while running the ithread. > > Errrm, what about a MP system that wires all interrupts to one processor (I > think some alphas may be this brain-damaged) we would want lower priority > interrupts to fire so that their threads would be scheduled and then picked up > by another CPU and run. Ithread priorities will ensure that ithreads are > processed in the right order. No hardware masking is needed. See above. I can't see how to do this without an external mechanism (perhaps one transparent to the O/S). The interrupt that we're servicing must be stopped from repeating somehow. For MP systems, it must also be stopped from affecting other CPUs. Hmm. An internal mechanism could be made to work at the cost of propagating it to all CPUs provided it is mask-based and not level-based. We would just use it to mask active interrupts. For this to work right, there must be at most one interrupt source per mask bit. When this is not possible (e.g., for i386's with ICUs and lots of interrupt sources), ithread priorities can't work right unless the ithreads for all the interrupt sources that share a mask bit have the same priority. > >> Also, we lower the IPL back to 0 before > >> running an ithread, so that only the actual interrupt stack that schedules > >> an > >> ithread to run runs at a raised IPL. > > > > This is a bug. In general, we can't lower the IPL below the level > > needed to mask the interrupt that we're handling, because level-triggered > > interrupts will repeat endlessly. I'm not sure why this isn't fatal > > for alphas. It may be handled by "lazy interrupt masking" -- let the > > interrupt repeat and mask it properly on the first repetition so that > > it won't repeat again. > > We mask the interrupts in the PIC just like on x86, otherwise a PCI interrupt > can cause problems because it is level triggered. Oops. For some reason I couldn't find this masking using grep. It is even spelled the same as on i386's (ICU, not PIC :). My main point is that the "MI" code in ithread_schedule() isn't actually MI. It assumes that there is an external mechanism. Does the restriction to one device IPL on alphas have much effect given that the ICU does the actual masking? How normal are ICUs on alphas? Getting back to the original subject of changing the API for disable_intr(), etc., all these layers of interrupt mechanisms are confusing. I think most of them should be kept out of MI code. The disable_intr() level is perhaps the only layer simple enough to have an MI API. > In theory we don't even need > to mask edge triggered interrupts at all as all that would happen is that the > ithread's it_need bit would get set again if it is already running. Almost in practice too. I implemented this for the spl mechanism and still rotted bits for it in my tree. SMPog implemented it too. It should work for the same reasons as it used to. At least my version of it masks any interrupts if they occur again, to handle level-triggered interrupts transparently. But it just wastes time to let interrupts repeat when you know that they will. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 21:57:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B507A37B718; Sun, 18 Mar 2001 21:57:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2J5vmZ04161; Sun, 18 Mar 2001 21:57:48 -0800 (PST) (envelope-from dillon) Date: Sun, 18 Mar 2001 21:57:48 -0800 (PST) From: Matt Dillon Message-Id: <200103190557.f2J5vmZ04161@earth.backplane.com> To: Bruce Evans Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG Subject: Re: 'final' man pages References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> will DTRT and not enable interrupts until after the second restore_intr(). :> You do have to pair them up much like lock acquire/releases. : :The problem is if interrupts are controlled by masks. A lower priority :interrupt may occur while the above code is running (unless you dumb down :the masks a little to give levels). The handler for this interrupt must :keep it disabled and not proceed far before continuing with the above :code (since the above code has higher priority). This invalidates x and :y if x and y contain the mask. If the masking is effectively per-cpu, this isn't actually a problem. The spl*() calls had the same issue. All that happens is that the lower priority interrupt gets in, masks interrupts, then restores them prior to returning. So from the point of view of the code being interrupted the mask hasn't changed at all. However, if multiple cpu's are allowed to make these calls and the masking involves shared state, you would have a problem with the cpu's tripping over each others masks. Insofar as this thread is concerned it isn't an issue that we have to worry about. For the same reason, the per-cpu interrupt nesting count and related tests do not require any special locking even if they gets interrupted, because the state is restored prior to the interrupt returning (no matter how many interrupts occur or how deeply nested the code gets). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Mar 18 22:13:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id A9C2137B718; Sun, 18 Mar 2001 22:13:34 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2J6DWH04251; Sun, 18 Mar 2001 22:13:32 -0800 (PST) (envelope-from dillon) Date: Sun, 18 Mar 2001 22:13:32 -0800 (PST) From: Matt Dillon Message-Id: <200103190613.f2J6DWH04251@earth.backplane.com> To: Bruce Evans Cc: John Baldwin , Matthew Jacob , arch@FreeBSD.ORG Subject: Re: 'final' man pages References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I should make an addendum here, since BDE indicated 'by masks'. What I forgot to say was that, of course, for a mask-based spl mechanism to work without a giant lock, the mask needs to be per-cpu and the interrupt code either needs to check all the cpu's masks, or the aggregate needs to be cached. Caching the aggregate is actually fairly easy to do. You can simply OR-in to a single common global when adding mask elements. But you take a hit when removing mask elements (splx() equivalent). You have to iterate through all the cpu's or have some sort of master lock, which can be expensive. There is a way to do it using only bus locking, and that is to aggregate the multiple cpu's masks for any given interrupt number together into a single word. For example, if you had 4 cpu's each interrupt would eat 4 bits. Each cpu would have to use several locked OR instructions to set their individual bits and AND to clear them (because the 'mask' now spans multiple words), but the interrupt can use a single memory access to test all the per-cpu masks for a particular irq all at once, since they all reside in the same word. Another requirement when using a software interrupt mask is that you need an interrupt-in-progress mask as well as an interrupt-disable-mask. The spl*() function equivalent would have to set the interrupt-disable-mask and then spin until any running interrupt (on another cpu) completes by waiting for the equivalent interrupt-in-progress mask to clear. Once clear, the disable mask prevents further interrupts from occuring. This was the direction I proposed for SMPng as an intermediate step before going to mutexes for the interrupt subsystem but SMPng decided to go directly to the MUTEXes. Theoretically the MUTEX system is supposed to do away with this sort of masking requirement, but it requires serious work on the interrupt subsystem and mainline kernel code to operate as expected since most mainline code still assumes a mask/spl*() API. This is why current is still disabling interrupts in SMP unsafe code. If people recall, this led to a number of minor bugs rearing their heads like the FSYNC code getting into a cpu-bound loop waiting for async I/O ops to finish, etc. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 0:32:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 481F637B719 for ; Mon, 19 Mar 2001 00:32:24 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2J8WEn25670; Mon, 19 Mar 2001 00:32:14 -0800 (PST) (envelope-from obrien) Date: Mon, 19 Mar 2001 00:32:13 -0800 From: "David O'Brien" To: Terry Lambert Cc: arch@FreeBSD.ORG Subject: Re: NO MORE '-BETA' Message-ID: <20010319003213.A25641@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010318161849.A20382@dragon.nuxi.com> <200103190128.SAA20941@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103190128.SAA20941@usr05.primenet.com>; from tlambert@primenet.com on Mon, Mar 19, 2001 at 01:28:29AM +0000 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 X-Loop: FreeBSD.ORG On Mon, Mar 19, 2001 at 01:28:29AM +0000, Terry Lambert wrote: > Mea culpa. I never used that mode. I rather expected that no > one would need such a thing, since anoncvs is supported. CVSup's checkout mode has been around longer than FreeBSD has offered anoncvs service. -- -- David (obrien@FreeBSD.org) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 0:42:32 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 5F5E237B718 for ; Mon, 19 Mar 2001 00:42:28 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 31767 invoked by uid 1000); 19 Mar 2001 08:41:37 -0000 Date: Mon, 19 Mar 2001 10:41:37 +0200 From: Peter Pentchev To: arch@FreeBSD.org Subject: Replacing libmd with libcrypto [Was: Re: cvs commit: src/sys/sys md5.h src/lib/libmd Makefile md2.h md2c.c md4.h mdX.3 mdXhl.c ripemd.3 ripemd.h sha.3 sha.h] Message-ID: <20010319104137.E73138@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Resending to -arch, since this really belongs here.. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? ----- Forwarded message from Peter Pentchev ----- Date: Sun, 18 Mar 2001 12:10:44 +0200 From: Peter Pentchev To: Kris Kennaway Cc: Mark Murray , Poul-Henning Kamp , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys md5.h src/lib/libmd Makefile md2.h md2c.c md4.h mdX.3 mdXhl.c ripemd.3 ripemd.h sha.3 sha.h [..or should this be in -arch?..] Okay, when you people are talking about replacing libmd with libcrypto, do you mean moving the additional functionality of libmd to libcrypto, or incorporating all the new and exciting functions into the OpenSSL source? If the former, that would be more or less easily achieved - as pointed out on -arch, libmd and libcrypto do seem to more or less share the basic hash routines, so adding the code would be a matter of moving the mdX* files from lib/libmd/ to secure/lib/libcrypto/ and adding them to the libcrypto build process. This would still benefit from what this commit is about - adding still more functionality to extend the OpenSSL libraries. If the latter, then hmm.. Not that I think that it would be too hard to convince the OpenSSL folks to add the libmd functions, but wouldn't that.. Actually, that would be a good idea from the standpoint of compatibility with other OS's and stuff.. But I still think that adding the libmd sources to the libcrypto build process could prove easier :) G'luck, Peter -- Hey, out there - is it *you* reading me, or is it someone else? On Sat, Mar 17, 2001 at 12:43:00PM -0800, Kris Kennaway wrote: > On Sat, Mar 17, 2001 at 02:13:11PM +0200, Mark Murray wrote: > > Hi > > > > Perhaps this would be a good time to mention that I have a plan to > > nuke libmd in favour of the MD* and SH* routines in libcrypto. The > > libcrypto routines are a _lot_ faster than the libmd ones, and their > > use is more ubiquitous. > > > > For the folks who don't need/want full crypto, the plan is also to > > provide a "strip-down" option to libcrypto, in order to accomodate > > paranoid governments. > > > > This is ther first time I'm mentioning this in public, so please don't > > panic - I won't be doing anything until the right folks agree. > > This is the same thing I mentioned on -arch when this came up..I even > asked Peter to submit diffs against libcrypto so we could keep them in > sync. ----- End forwarded message ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 9: 6:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 518B537B719 for ; Mon, 19 Mar 2001 09:06:20 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f2JH64V44129; Mon, 19 Mar 2001 09:06:04 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f2JH5t004397; Mon, 19 Mar 2001 09:05:56 -0800 (PST) (envelope-from jdp) Date: Mon, 19 Mar 2001 09:05:56 -0800 (PST) Message-Id: <200103191705.f2JH5t004397@vashon.polstra.com> To: arch@freebsd.org From: John Polstra Reply-To: arch@freebsd.org Cc: tlambert@primenet.com Subject: Re: NO MORE '-BETA' In-Reply-To: <200103182343.QAA18756@usr05.primenet.com> References: <200103182343.QAA18756@usr05.primenet.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <200103182343.QAA18756@usr05.primenet.com>, Terry Lambert wrote: > > > > care to do. How does CVSup in checkout mode handle local mods? > > > > > > Its head explodes. > > > > "check out" mode -- ie, _NOT_ CVSuping the repo, just doing the equiv of > > a ``cvs co''. > > Its head still explodes because of the greedy diff algorithm. It's head does not explode, Terry. It serves no useful purpose at all to spread this kind of FUD on the mailing lists. In checkout mode, the server simply wins and your local mods go away. If it is crashing for you then most likely you have been using the "-s" option without heeding the very explicit and clear warning in the man page. Otherwise it is a bug which you have never reported to me, the maintainer of the software. Your complaint about the language tools being too big to use might have been reasonable in 1996, but it looks pretty silly these days. There are numerous commonly-used software packages which are much larger. There are ports and packages for the Modula-3 tools which are just as easy to install as any of the other ports and packages. And if you aren't willing or able to learn a new programming language then you could at least take the trouble to report any bugs you find, INCLUDING full information which would enable me to reproduce them and fix them. I do agree it would be nice if CVSup could check out the current sources and import them onto the vendor branch of a local repository. That has been on my desired feature list for a long time. Unfortunately, I don't see myself having time to implement it in the near future, unless the economy falls apart to the point that I don't have any paywork to do any more. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 9:30: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 4D65537B71A for ; Mon, 19 Mar 2001 09:29:56 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f2JHW3199529; Mon, 19 Mar 2001 09:32:07 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Mon, 19 Mar 2001 09:29:18 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: 'final' man pages Cc: Matthew Jacob , arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 19-Mar-01 Bruce Evans wrote: >> >> If a machine supports an external mechanism for disabling interrupts such >> >> as >> >> a >> >> PIC mask, then we can simply disable individual interrupts that way until >> >> the >> >> ithread associated with an interrupt source completes. Note that we only >> > >> > And this is what we do on i386's. >> >> And alpha's. > > I couldn't find where this is done on alphas. I asked you in private mail, > but you didn't reply on this point (although you replied on many others, > thanks :). Woops. The way this is done is with the it_enable() and it_disable() function pointers in struct ithd. They are set to platform-specific functions to talk to the ICU or PCI controller for that platform to enable and disable an individual interrupt source. > Anyway, there must be an external mechanism for the SMP case to work > right. An internal (per-CPU) mechanism just can't be used to control > other CPUs, except grossly and inefficiently by propagating the internal > mechanism to all CPUs, or by halting or spinning all CPUs except the one > which took the interrupt. So the rest of this discussion only applies > to single-CPU systems with no external mechanism. The internal mechanism > would probably look much like an spl mechanism, so it is inherently > mismatched with our SMP-friendly mechanisms. Yes, SMP w/o an external mechanism gets ugly. Well, you actually don't need to propagate the mask. If another CPU gets an interrupt, then it will see that the ithread is already scheduled and/or running, just mark it_need and leave the interrupt masked on the current CPU. Hmm, but then it won't be unmasked except on the CPU that finishes the ithread, so you would need to propagate unmasks at least if we ever do SMP on an arch with no external mechanism. >> >> really need to do this for level-triggered interrupts. If we don't have >> >> this >> >> available and are forced to (ab)use the CPU interrupt level to mask >> >> interrupts, >> >> then we instead disable all other device interrupts on this CPU when an >> >> interrupt comes in until the associated ithread finishes. >> > >> > We should disable precisely all the interrupts with the same or lower >> > priority while running the ithread. >> >> Errrm, what about a MP system that wires all interrupts to one processor (I >> think some alphas may be this brain-damaged) we would want lower priority >> interrupts to fire so that their threads would be scheduled and then picked >> up >> by another CPU and run. Ithread priorities will ensure that ithreads are >> processed in the right order. No hardware masking is needed. > > See above. I can't see how to do this without an external mechanism > (perhaps one transparent to the O/S). The interrupt that we're > servicing must be stopped from repeating somehow. For MP systems, it > must also be stopped from affecting other CPUs. Hmm. An internal > mechanism could be made to work at the cost of propagating it to all > CPUs provided it is mask-based and not level-based. We would just use > it to mask active interrupts. For this to work right, there must be at > most one interrupt source per mask bit. When this is not possible > (e.g., for i386's with ICUs and lots of interrupt sources), ithread > priorities can't work right unless the ithreads for all the interrupt > sources that share a mask bit have the same priority. I was mainly pointing out that if we can mask the current level, we don't need to mask all lower levels as well, as we may want a lower level ithread to run on a given CPU. However, the current CPU does always need to block the current interrupt if it is level triggered. Using an external mask to do this is much more efficient. Without it you would degenerate to blocking all other interrupts each time an interrupt came in until its thread had finished. >> >> Also, we lower the IPL back to 0 before >> >> running an ithread, so that only the actual interrupt stack that >> >> schedules >> >> an >> >> ithread to run runs at a raised IPL. >> > >> > This is a bug. In general, we can't lower the IPL below the level >> > needed to mask the interrupt that we're handling, because level-triggered >> > interrupts will repeat endlessly. I'm not sure why this isn't fatal >> > for alphas. It may be handled by "lazy interrupt masking" -- let the >> > interrupt repeat and mask it properly on the first repetition so that >> > it won't repeat again. >> >> We mask the interrupts in the PIC just like on x86, otherwise a PCI >> interrupt >> can cause problems because it is level triggered. > > Oops. For some reason I couldn't find this masking using grep. It is even > spelled the same as on i386's (ICU, not PIC :). > > My main point is that the "MI" code in ithread_schedule() isn't actually MI. > It assumes that there is an external mechanism. Well, it uses a MD hook, mtx_intr_enable(), and if you want to leave the implicit intr_disable() from the interrupt code in effect you simply don't have it do anything. This would basically leave interrupts disabled until the MD enable interrupt function called from ithread_loop() reenabled interrupts. > Does the restriction to one device IPL on alphas have much effect given > that the ICU does the actual masking? How normal are ICUs on alphas? It actually ends up being very similar to the i386. The IPL is raised on the interrupt stack (just like PSL_I is cleared on i386 on the interrupt stack) and it is lowered otherwise. We depend on the ICU masking, which is more important on the alpha as all PCI interrupts (except maybe for one of the archs (pc164?) which just uses a ICU that is broken) are level-triggered. > Getting back to the original subject of changing the API for > disable_intr(), etc., all these layers of interrupt mechanisms are > confusing. I think most of them should be kept out of MI code. The > disable_intr() level is perhaps the only layer simple enough to have > an MI API. Yes, and so far it is the only one used in MI code, as the mutexes use the foo_intr() API, and mtx_intr_enable() is actually a slight extension to that API. (It changes the saved state returned from disable_intr() so that interrupts will always be enabled when it is passed to restore_intr()). >> In theory we don't even need >> to mask edge triggered interrupts at all as all that would happen is that >> the >> ithread's it_need bit would get set again if it is already running. > > Almost in practice too. I implemented this for the spl mechanism and > still rotted bits for it in my tree. SMPog implemented it too. It > should work for the same reasons as it used to. At least my version > of it masks any interrupts if they occur again, to handle level-triggered > interrupts transparently. But it just wastes time to let interrupts > repeat when you know that they will. Yep, might as well keep them masked until you are ready for another one. > Bruce -- 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 Mar 19 16:57: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 8642637B71E; Mon, 19 Mar 2001 16:56:34 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-36.nnj.dialup.bellatlantic.net [151.198.135.36]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id TAA23200; Mon, 19 Mar 2001 19:55:05 -0500 (EST) Message-ID: <3AB6AA65.1B6ED19E@bellatlantic.net> Date: Mon, 19 Mar 2001 19:55:01 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Terry Lambert Cc: security@FreeBSD.ORG, Wes Peters , Robert Watson , fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) References: <200103180738.AAA03250@usr05.primenet.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > I want to commit PR kern/14584. I've been told that it's good > > to discuss it in -arch, -security and -fs. (It has been sort of > > discussed on -hackers already, there were not much replies). > > So I've posted a message on -arch, and now on -security and -fs. > > I've also discussed this idea shortly with Kirk McKusick at > > Usenix-2000 at the BSD BOF and he generally liked it and suggested > > to review further. > > You could do this a bit more cleanly by just stealing the sign > bit, and setting if the uid field contained a group ID. > > There would be no conversion problem for an existing system. That was my original idea but some thinking and experimentation has shown that it creates too many incompatibilities, such as: - programs displaying the owner by name would break, and that includes both the standard programs and random applications - when exported by nfs, the same problem would stand for the clients - chown will have to be changed - both the program and system call, as you mention later and possibly other sorts of breakages. > This changes the check to a one line change, conditional on > the high bit being set. No, the change would be the same, just wrapped into a condition check for this bit. > Note that this change is really necessary in the user space code > anyway: even if you make the UID and GID numeric values not > intersect, there is still the possibility of a group and user > having the same name, so a set-by-name needs a seperate flag > (thing "chown bin.bin foo", for example). In the way I propose it, the sysadmins are supposed to create a pseudo-user with the same name and ID as each group. That automagically makes all commands, such as chown and ls, work properly. Of course, that means that no real users and groups must have the same name, but the common namespace looks natural with the common ID space. Because the traditional users ang groups with low IDs do have overlapping names, and IDs, the sysctl sets the lowest ID from which the common ID space starts. If the sysctl sets this value to below 100 (traditional range for the system IDs), then the common ID code is disabled altogether. The value of 100 is set by a kernel config option and may be changed. > The benefits in not having the grovel through the FS contents, or > do a more complex ID space transformations, and the moving of the > majority of changes to user space, combined with the fact that if > you turn it off, the ownership doesn't need to be reverted, are > all plusses. This is not quite so. My patch requires only one little change in the kernel and no usel-level space changes at all. It has some expectations for the assignment of user and group IDs and names, but these expectations are justified to make the common ID space look reasonable. The downside is that it's slightly slower (for each file owner ID in the common space it has to be checked agains all process'es groups). I'm not sure yet if it allows more complex transformations and whether it does it comparable to your proposal. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 17: 1:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 0AF7537B737; Mon, 19 Mar 2001 17:01:39 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-36.nnj.dialup.bellatlantic.net [151.198.135.36]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA23273; Mon, 19 Mar 2001 20:00:40 -0500 (EST) Message-ID: <3AB6ABB7.A208EECE@bellatlantic.net> Date: Mon, 19 Mar 2001 20:00:39 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Cy Schubert - ITSD Open Systems Group Cc: security@FreeBSD.ORG, Wes Peters , Robert Watson , fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) References: <200103181447.f2IElef41927@cwsys.cwsent.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cy Schubert - ITSD Open Systems Group wrote: > > In message <3AB3FC38.94711FFF@bellatlantic.net>, Sergey Babkin writes: > > All, > > > > I want to commit PR kern/14584. I've been told that it's good > > >From an operational standpoint I see one problem. Some sites use UID > 0-999 and 65000-65535 for use by special accounts, such as www, ftp, > oracle, etc. In some cases this policy is dictated by a desire to have > some kind of commonality across various vendor platforms, some of which > reserve some odd UID's and GID's for vendor supplied software or > purposes. The only suggestion I would make is that a range could be > specified. For example instead of vfs.commonid, vfs.commonid.low and > vfs.commonid.high, allowing a site to, for example, reserve UID/GID's > 10000-19999 or any other range as common ID's. I'm not sure if it's so important: probably, normally the IDs around 65535 are used for things like nobody/nogroup. But since it's easy to implement, I guess it would not hurt. So I agree with this proposal. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 17:16:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 2458537B740; Mon, 19 Mar 2001 17:16:31 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-36.nnj.dialup.bellatlantic.net [151.198.135.36]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA23373; Mon, 19 Mar 2001 20:15:12 -0500 (EST) Message-ID: <3AB6AF1F.9452E231@bellatlantic.net> Date: Mon, 19 Mar 2001 20:15:11 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Terry Lambert Cc: Brett Glass , security@FreeBSD.ORG, Wes Peters , Robert Watson , fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) References: <200103182339.QAA18696@usr05.primenet.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > At the same time, it'd be nice to eliminate the arbitrary limitations These things are not really related to the common ID space. I definitely would not like to do them in the same patch, just to keep things separate. > > on (a) the number of groups of which a user can be a member and (b) the For this there is some macro (can't remember the name) which can be defined in the kernel config file as an option with a higher value. Setting it higher means higher system overhead but since the memory size has increased significantly over the last few years, I think that a higher default value makes sense. > > number of members in a group. Both of these limitations often bite > > administrators who, for example, want most users of a system to be > > members of a particular group or want to implement group-based access > > control schemes with a moderate degree of granularity. Classes won't > > cut it for this purpose, alas, because they're not built into file > > system security. > > I think that you will run into the limitations inherent in the > quota record storage format and NFSv2 UID/GID, well before you > face that limit. > > There is really no limit on the number of members permitted in a > group, I believe. If you are talking about line length, I'd say I think there is such a limit. Or at least it was in the 2.0.5 days. I'm not sure about the line length limit. I remember that there was such a limit in SVR4.2, so if a group line grew past some size, getgrent() and friends went crazy. > you should consider getting rid of "pico" and using a real editor. The common workaround it to split a group record into multiple lines in /etc/group, like: staff:*:20:root staff:*:20:babkin Keep no more than about ~50 users per line. This may break things like adduser but it's not a big loss. The important things, such as setting process permissions on login, work fine. > I think there are patches floating around to allow repeats of > group lines in order to set up larger lists of members, in any > case (they may already be integrated into FreeBSD; they aren't in > BSDI, from looking at the BSDI system I have access to). No patches are really required. If you discount the secondary stuff like useradd/adduser, repeated lines just work out of the box on all the Unix systems where I tried: FreeBSD, Linux, HP-UX, UnixWare, SCO OpenServer, ICL DRS/NX (old SVR4.2). -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 21:21:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 9A72737B731; Mon, 19 Mar 2001 21:21:33 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id WAA14447; Mon, 19 Mar 2001 22:14:43 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAAgvai7B; Mon Mar 19 22:14:28 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id WAA23451; Mon, 19 Mar 2001 22:21:04 -0700 (MST) From: Terry Lambert Message-Id: <200103200521.WAA23451@usr05.primenet.com> Subject: Re: about common group & user ID space (PR kern/14584) To: babkin@bellatlantic.net (Sergey Babkin) Date: Tue, 20 Mar 2001 05:20:59 +0000 (GMT) Cc: fs@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <3AB6AA65.1B6ED19E@bellatlantic.net> from "Sergey Babkin" at Mar 19, 2001 07:55:01 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You could do this a bit more cleanly by just stealing the sign > > bit, and setting if the uid field contained a group ID. > > > > There would be no conversion problem for an existing system. > > That was my original idea but some thinking and experimentation > has shown that it creates too many incompatibilities, such as: > > - programs displaying the owner by name would break, and > that includes both the standard programs and random applications > - when exported by nfs, the same problem would stand for the > clients > - chown will have to be changed - both the program and system call, > as you mention later > > and possibly other sorts of breakages. The NFS breakage is going to be there in any case; the semantics will be different on the remote machine, giving ownership to a particular user (who doesn't exist). This will turn "owner by name" numeric at best, and give ownership to a particular person, not group, at worst. You also have the problem that the FreeBSD machine has to be your NIS master; in a heterogeneous environment, Sun boxes are still better NIS servers, since they understand the full complement of NIS maps, which FreeBSD doesn't, and they support automount (as opposed to amd, which happily requires a reboot to unwedge in many situations). Any time you internalize or externalize a uid/gid space, you will have that problem. Plus, with your approach, you are either going to have to make an exception for certain ID ranges, permitting overlap, or you are going to be stuck renumbering things like "bin" and "kmem". Further, even if the FreeBSD was the NIS master for NFS name interpretation, the only safe way to make the maps transportable would be to have identical group and password name/ID pairs. This breaks for normal duplication, which exists now: you can't have two entries in either file for the same key field, since a getpwuid or getgrgid will only return the first matching value in all cases. > > This changes the check to a one line change, conditional on > > the high bit being set. > > No, the change would be the same, just wrapped into a condition > check for this bit. I think you could "fudge" the in core copy of one id to be the other, with the bit OR'ed in or AND'ed off, as appropriate... > In the way I propose it, the sysadmins are supposed to create > a pseudo-user with the same name and ID as each group. That > automagically makes all commands, such as chown and ls, work > properly. Of course, that means that no real users and groups > must have the same name, but the common namespace looks natural > with the common ID space. Because the traditional users ang groups > with low IDs do have overlapping names, and IDs, the sysctl sets > the lowest ID from which the common ID space starts. If the sysctl > sets this value to below 100 (traditional range for the > system IDs), then the common ID code is disabled altogether. > The value of 100 is set by a kernel config option and may be changed. This explodes when your remote NIS server doesn't enforce the new semantics; this is sort of the opposite of the problem I cite above with not being able to maintain a single namespace. Really, the namespace and the ID space are paired, so the only practical thing to do is to seperate the ID space and the namespace at the same time. I really think it's a lot easier to do this by stealing a bit somewhere (second one down from the sign, if the sign is to be held sacrosanct) than it is to rely on semantic enforcement by your tools. As soon as you do that, it becomes significantly less useful. At least with a stolen bit, the ownership on the remote machine works, even if it doesn't precisely "make sense" the same way it does on the hacked FreeBSD box. > > The benefits in not having the grovel through the FS contents, or > > do a more complex ID space transformations, and the moving of the > > majority of changes to user space, combined with the fact that if > > you turn it off, the ownership doesn't need to be reverted, are > > all plusses. > > This is not quite so. My patch requires only one little change in > the kernel and no usel-level space changes at all. It has some > expectations for the assignment of user and group IDs and names, > but these expectations are justified to make the common ID space > look reasonable. The downside is that it's slightly slower > (for each file owner ID in the common space it has to be checked > agains all process'es groups). I'm not sure yet if it allows > more complex transformations and whether it does it comparable > to your proposal. You could do the transformations with a mapping layer (left as an exercise for the student), but it would not really be worth it, I think. The biggest problem is that the tools have to have a gentleman's agreement between themselves across systems that everyone will sign up to honor. That's really too kludgy to trust, unless you are in a homogeneous environment (if then). Placing this as a restriction makes the idea much, much less generally useful than it would otherwise be. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Mar 19 23:29:26 2001 Delivered-To: freebsd-arch@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id A6DDF37B718; Mon, 19 Mar 2001 23:29:18 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id AAA20088; Tue, 20 Mar 2001 00:25:56 -0700 (MST) Message-Id: <4.3.2.7.2.20010320002008.00d12b50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Mar 2001 00:25:37 -0700 To: Sergey Babkin , Terry Lambert From: Brett Glass Subject: Re: about common group & user ID space (PR kern/14584) Cc: security@FreeBSD.ORG, Wes Peters , Robert Watson , fs@FreeBSD.ORG, arch@FreeBSD.ORG In-Reply-To: <3AB6AF1F.9452E231@bellatlantic.net> References: <200103182339.QAA18696@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 06:15 PM 3/19/2001, Sergey Babkin wrote: >> > on (a) the number of groups of which a user can be a member and (b) the > >For this there is some macro (can't remember the name) which >can be defined in the kernel config file as an option with >a higher value. Setting it higher means higher system overhead >but since the memory size has increased significantly over >the last few years, I think that a higher default value makes >sense. I do too. Could you submit this as a patch? >I think there is such a limit. Or at least it was in the 2.0.5 days. >I'm not sure about the line length limit. I remember that there >was such a limit in SVR4.2, so if a group line grew past some size, >getgrent() and friends went crazy. I believe that it was between 100 and 130 when it lost it. Don't know if it was the number of characters or the number of users. >The common workaround it to split a group record into multiple >lines in /etc/group, like: > >staff:*:20:root >staff:*:20:babkin > >Keep no more than about ~50 users per line. >This may break things like adduser but it's not a big loss. Breaking adduser WOULD be a loss. If one of our sysadmins-in-training was adding users to the system, he or she wouldn't know what to do next. And those of us who COULD wouldn't want to take the time. Perhaps adduser ought to be patched to deal with this... say, by understanding multiple lines and limiting the number of users on any one line. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Mar 20 18:25:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ego.mind.net (ego.mind.net [206.99.66.9]) by hub.freebsd.org (Postfix) with ESMTP id 2AD9E37B71C; Tue, 20 Mar 2001 18:25:36 -0800 (PST) (envelope-from takhus@takhus.mind.net) Received: from takhus.dyn.mind.net (AFN-Dyn-2084622070.pc.ashlandfiber.net [208.46.220.70]) by ego.mind.net (8.9.3/8.9.3) with ESMTP id SAA19471; Tue, 20 Mar 2001 18:15:19 -0800 Received: from localhost (fleisher@localhost) by takhus.dyn.mind.net (8.11.3/8.11.3) with ESMTP id f2L2FJp18281; Tue, 20 Mar 2001 18:15:19 -0800 (PST) (envelope-from takhus@takhus.mind.net) X-Authentication-Warning: takhus.dyn.mind.net: fleisher owned process doing -bs Date: Tue, 20 Mar 2001 18:15:19 -0800 (PST) From: Tony Fleisher X-Sender: fleisher@takhus.dyn.mind.net To: Brett Glass Cc: Sergey Babkin , security@FreeBSD.ORG, fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) In-Reply-To: <4.3.2.7.2.20010320002008.00d12b50@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Mar 2001, Brett Glass wrote: > At 06:15 PM 3/19/2001, Sergey Babkin wrote: > > >> > on (a) the number of groups of which a user can be a member and (b) the > > > >For this there is some macro (can't remember the name) which > >can be defined in the kernel config file as an option with > >a higher value. Setting it higher means higher system overhead > >but since the memory size has increased significantly over > >the last few years, I think that a higher default value makes > >sense. > > I do too. Could you submit this as a patch? > > >I think there is such a limit. Or at least it was in the 2.0.5 days. > >I'm not sure about the line length limit. I remember that there > >was such a limit in SVR4.2, so if a group line grew past some size, > >getgrent() and friends went crazy. > > I believe that it was between 100 and 130 when it lost it. Don't > know if it was the number of characters or the number of users. > > [details about a workaround and adduser breakage removed] I believe that the limit on the length of a line in the group file was removed prior to 3.0-RELEASE. See revision 1.14 of src/lib/libc/gen/getgrent.c by wosch. http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libc/gen/getgrent.c Regards, Tony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13: 2:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 2B88F37B71C for ; Wed, 21 Mar 2001 13:02:17 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2LL0p188827 for ; Wed, 21 Mar 2001 22:00:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org Subject: remind me again, why is MAXPHYS only 128k ? From: Poul-Henning Kamp Date: Wed, 21 Mar 2001 22:00:51 +0100 Message-ID: <88825.985208451@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are there any roadblocks for increasing MAXPHYS as a tweakable these days, or is it still an "do not alter or ELSE..." #define ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:12:51 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1872537B71E; Wed, 21 Mar 2001 13:12:48 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2LLBSh01790; Wed, 21 Mar 2001 13:11:28 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103212111.f2LLBSh01790@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: remind me again, why is MAXPHYS only 128k ? In-reply-to: Your message of "Wed, 21 Mar 2001 22:00:51 +0100." <88825.985208451@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Mar 2001 13:11:28 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Are there any roadblocks for increasing MAXPHYS as a tweakable these > days, or is it still an "do not alter or ELSE..." #define ? There isn't much hardware out there that can do anything useful with an I/O larger than 128k. There was also a lengthy discussion on I/O saturation a little while back; the short answer is just that making it larger doesn't win anything significant, and may cause unacceptable latencies in some cases. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:17:33 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 9A3F637B71D; Wed, 21 Mar 2001 13:17:30 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2LLHL189048; Wed, 21 Mar 2001 22:17:21 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mike Smith Cc: arch@freebsd.org Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 13:11:28 PST." <200103212111.f2LLBSh01790@mass.dis.org> Date: Wed, 21 Mar 2001 22:17:21 +0100 Message-ID: <89046.985209441@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103212111.f2LLBSh01790@mass.dis.org>, Mike Smith writes: >> >> Are there any roadblocks for increasing MAXPHYS as a tweakable these >> days, or is it still an "do not alter or ELSE..." #define ? > >There isn't much hardware out there that can do anything useful with an >I/O larger than 128k. Well, while that is true, things like striping and raid-5 could benefit from not being limited to a 128k stripesize for certain kinds of bulk application. I also belive tapes have been mentioned as a candidate for a larger MAXPHYS. >There was also a lengthy discussion on I/O >saturation a little while back; the short answer is just that making it >larger doesn't win anything significant, and may cause unacceptable >latencies in some cases. Right, I'm not asking for a general increase, I'm asking if it can be increased on a case-by-case basis or if the system will explode for arcane architectural reasons if I double or quadruple it on a particular system ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:25:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0D04937B71C; Wed, 21 Mar 2001 13:25:18 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA11358; Wed, 21 Mar 2001 13:25:22 -0800 Date: Wed, 21 Mar 2001 13:25:17 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: <88825.985208451@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Folks complained about some VM issues for trying to wire down a megabyte, etc. You sent me a suggestion as to how we could do specific device wiring w/o increasing MAXPHYS itself. That said, in NetBSD I've run 1024K MAXPHYS- you just have to make sure that the max buffer size doesn't track MAXPHYS 'coz you run out of memory rather quick. > > Are there any roadblocks for increasing MAXPHYS as a tweakable these > days, or is it still an "do not alter or ELSE..." #define ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:26:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E25BC37B71D; Wed, 21 Mar 2001 13:26:26 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA11370; Wed, 21 Mar 2001 13:26:31 -0800 Date: Wed, 21 Mar 2001 13:26:21 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Mike Smith Cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: <200103212111.f2LLBSh01790@mass.dis.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Mar 2001, Mike Smith wrote: > > > > Are there any roadblocks for increasing MAXPHYS as a tweakable these > > days, or is it still an "do not alter or ELSE..." #define ? > > There isn't much hardware out there that can do anything useful with an > I/O larger than 128k. There was also a lengthy discussion on I/O > saturation a little while back; the short answer is just that making it > larger doesn't win anything significant, and may cause unacceptable > latencies in some cases. That was maybe only one person's opinion. It was not a consensus by any means. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:30:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 1CBAF37B720 for ; Wed, 21 Mar 2001 13:30:32 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2LLUK189283; Wed, 21 Mar 2001 22:30:20 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 13:25:17 PST." Date: Wed, 21 Mar 2001 22:30:20 +0100 Message-ID: <89281.985210220@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthew Jacob writes: > >Folks complained about some VM issues for trying to wire down a megabyte, etc. > >You sent me a suggestion as to how we could do specific device wiring w/o >increasing MAXPHYS itself. > >That said, in NetBSD I've run 1024K MAXPHYS- you just have to make sure that >the max buffer size doesn't track MAXPHYS 'coz you run out of memory rather >quick. Yeah, it's a mistake for struct buf/bio to use a fixed array of pages (b->b_pages) If we made that a ** instead we could have a variable MAXPHYS... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:38:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id B0E8C37B71E; Wed, 21 Mar 2001 13:38:21 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LLc8a21690; Wed, 21 Mar 2001 13:38:08 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 13:38:08 -0800 (PST) From: Matt Dillon Message-Id: <200103212138.f2LLc8a21690@earth.backplane.com> To: Poul-Henning Kamp Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89046.985209441@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When I last discussed MAXPHYS with people the issue that was predominant was the b_pages[] array embedded in the struct buf and the pages[] arrays declared in the VM paging code. I was worried that an increased MAXPHYS eating too much kernel stack and too much kernel memory. We also have the issue of the physical buffers (pbufs) reserving VM space permanently. If you increase MAXPHYS you quickly start to hit kernel VM limitations. There are also issues with I/O piplining and deadlock avoidance in the VFS/BIO subsystem. The VM low memory handling is effectively tuned to the assumption that MAXPHYS is somewhere 'around' 128K. Some initial-value work for VM related sysctls would be required there (minor work I think). There are also some minor issues associated with the clustering code. In anycase, my suggestion would be to leave it alone and instead work on optimizing the RAW DEVICE I/O path to not be limited by MAXPHYS at all. Increasing it to 256K might be possible, but increasing it to 1MB is out of the question (insofar as being a default). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:42:10 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 7710037B720 for ; Wed, 21 Mar 2001 13:42:08 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LLg1921851; Wed, 21 Mar 2001 13:42:01 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 13:42:01 -0800 (PST) From: Matt Dillon Message-Id: <200103212142.f2LLg1921851@earth.backplane.com> To: Poul-Henning Kamp Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89281.985210220@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Yeah, it's a mistake for struct buf/bio to use a fixed array of pages :(b->b_pages) If we made that a ** instead we could have a variable :MAXPHYS... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 Remember that allocating struct buf's cannot block in MALLOC or anything like that. It is difficult to deal with struct buf exhaustion in vfs/bio. We can't add any new blocking conditions anywhere and still have a stable system. There are a couple of possible solutions, including preallocating a VM pages[] array of pointers that covers the *ENTIRE* struct buf KVA space and then simply assigning the appropriate point to a vm_page_t **b_pages element in the struct buf at the point where we associate KVM with the struct buf. This would give us maximum flexibility. Perhaps a pages[] array covering the entire kernel VM space would be an even better solution. 1G / 4K x 4 bytes = 1MB. Not a big deal. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:45: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1FF5C37B718 for ; Wed, 21 Mar 2001 13:44:58 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2LLhih02089; Wed, 21 Mar 2001 13:43:44 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103212143.f2LLhih02089@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: remind me again, why is MAXPHYS only 128k ? In-reply-to: Your message of "Wed, 21 Mar 2001 22:17:21 +0100." <89046.985209441@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Mar 2001 13:43:44 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <200103212111.f2LLBSh01790@mass.dis.org>, Mike Smith writes: > >> > >> Are there any roadblocks for increasing MAXPHYS as a tweakable these > >> days, or is it still an "do not alter or ELSE..." #define ? > > > >There isn't much hardware out there that can do anything useful with an > >I/O larger than 128k. > > Well, while that is true, things like striping and raid-5 could benefit > from not being limited to a 128k stripesize for certain kinds of > bulk application. You're referring here to the interface between the bio layer and the RAID layer, rather than the actual limit on a physical I/O though. I realise that the RAID layer in question pretends to be an I/O layer, hence this being an issue. I think that MAXPHYS should become DFLTMAXPHYS, and the si_iosize_max field should be allowed to be an override in either direction, so that devices that *are* OK with larger transfers can actually take advantage of them. > I also belive tapes have been mentioned as a candidate for a larger > MAXPHYS. This I think has mostly been the case with SGI systems and large tape blocks, I think, but I don't recall whether 128k was enough. > >There was also a lengthy discussion on I/O > >saturation a little while back; the short answer is just that making it > >larger doesn't win anything significant, and may cause unacceptable > >latencies in some cases. > > Right, I'm not asking for a general increase, I'm asking if it can > be increased on a case-by-case basis or if the system will explode > for arcane architectural reasons if I double or quadruple it on > a particular system ? I don't believe that any of the previous discussion uncovered anything that would explode. You would probably want to check though. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:46:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from molly.straylight.com (molly.straylight.com [209.68.199.242]) by hub.freebsd.org (Postfix) with ESMTP id AA22D37B71A for ; Wed, 21 Mar 2001 13:46:25 -0800 (PST) (envelope-from jonathan@graehl.org) Received: from dickie (case.straylight.com [209.68.199.244]) by molly.straylight.com (8.11.0/8.10.0) with SMTP id f2LLkEE12537 for ; Wed, 21 Mar 2001 13:46:14 -0800 From: "Jonathan Graehl" To: "freebsd-Arch" Subject: RE: Request for review [Re: /bin/ls patch round #2] Date: Wed, 21 Mar 2001 13:45:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <200103212119.QAA22140@khavrinen.lcs.mit.edu> Importance: Normal Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You would have to exclude most of the programs in 4.4BSD by that > definition. There is a reason why interfaces like err(3) and > daemon(3) are included in the standard C library, and the style guide > strongly recommends their usage. > > -GAWollman While I was aware of err, daemon is quite a pleasant surprise. A month ago, I looked at several FreeBSD servers (inetd, syslogd, and others) and was dismayed to find that they all had their own little variation on the same fork/setsid/chdir/dup2"/dev/null" theme. Are there any plans to change the FreeBSD servers to use err and daemon rather than their homegrown equivalents? (I'm already changing mine, since I did almost exactly the same thing, except that I have a compile time option to have the child sleep and the parent print its pid to make debugging with gdb in daemon mode possible). Is using setlogin("") recommended for root daemons? I assume daemon doesn't do it ... -- Jonathan Graehl http://jonathan.graehl.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:46:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 8DF5837B71B; Wed, 21 Mar 2001 13:46:27 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2LLkF189601; Wed, 21 Mar 2001 22:46:15 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 13:38:08 PST." <200103212138.f2LLc8a21690@earth.backplane.com> Date: Wed, 21 Mar 2001 22:46:15 +0100 Message-ID: <89599.985211175@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103212138.f2LLc8a21690@earth.backplane.com>, Matt Dillon writes: > In anycase, my suggestion would be to leave it alone and instead work on > optimizing the RAW DEVICE I/O path to not be limited by MAXPHYS at all. > Increasing it to 256K might be possible, but increasing it to 1MB is > out of the question (insofar as being a default). Well, that is stuck on the b_pages field in the (p)buf's. I was wondering if we should make that a ** instead of a *[] so that it could be sized dynamically for pbufs. Hmm.... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:51:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 9F8FF37B719; Wed, 21 Mar 2001 13:51:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LLpii22172; Wed, 21 Mar 2001 13:51:44 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 13:51:44 -0800 (PST) From: Matt Dillon Message-Id: <200103212151.f2LLpii22172@earth.backplane.com> To: Poul-Henning Kamp Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89599.985211175@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200103212138.f2LLc8a21690@earth.backplane.com>, Matt Dillon writes: : :> In anycase, my suggestion would be to leave it alone and instead work on :> optimizing the RAW DEVICE I/O path to not be limited by MAXPHYS at all. :> Increasing it to 256K might be possible, but increasing it to 1MB is :> out of the question (insofar as being a default). : :Well, that is stuck on the b_pages field in the (p)buf's. I was wondering :if we should make that a ** instead of a *[] so that it could be sized :dynamically for pbufs. : :Hmm.... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 The pbuf's use a reserved chunk of KVM, so during kernel initialization you could pre-allocate a static pages[] array that covers the entire reserved space and then make b_pages a ** and simply point it into the static array as appropriate. The physical buffer subsystem would have to 'allocate' (aka reserve) variable sized blocks out of the KVM space rather then using a fixed block size, but that would be the only issue. We could almost certainly use a faked vm_map (like the buffer cache uses) to manipulate the space, especially now that Tor has cleaned it all up. There are a few uses of pbuf's (and normal bufs for that matter) where the KVA is ignored and a kernel module will stuff its own vm_page_t's into the pbuf. I have not researched all such occurances of these but I would not expect it to be difficult to 'fix'. If they're synchronous the local pages[] could be declared on the stack. I dunno. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:52: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 13CFC37B719 for ; Wed, 21 Mar 2001 13:51:58 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2LLpi189689; Wed, 21 Mar 2001 22:51:44 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 13:42:01 PST." <200103212142.f2LLg1921851@earth.backplane.com> Date: Wed, 21 Mar 2001 22:51:44 +0100 Message-ID: <89687.985211504@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103212142.f2LLg1921851@earth.backplane.com>, Matt Dillon writes: >:Yeah, it's a mistake for struct buf/bio to use a fixed array of pages >:(b->b_pages) If we made that a ** instead we could have a variable >:MAXPHYS... >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >:phk@FreeBSD.ORG | TCP/IP since RFC 956 > > Remember that allocating struct buf's cannot block in MALLOC or anything > like that. It is difficult to deal with struct buf exhaustion in > vfs/bio. We can't add any new blocking conditions anywhere and still > have a stable system. Well, physio can wait, and that is the sticky point for tapes and such. For normal bufs the field would be allocated at boot to point to the usual sized array. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 13:54:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 438A037B722; Wed, 21 Mar 2001 13:54:36 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2LLsP189777; Wed, 21 Mar 2001 22:54:25 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matt Dillon Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 13:51:44 PST." <200103212151.f2LLpii22172@earth.backplane.com> Date: Wed, 21 Mar 2001 22:54:25 +0100 Message-ID: <89775.985211665@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103212151.f2LLpii22172@earth.backplane.com>, Matt Dillon writes: > There are a few uses of pbuf's (and normal bufs for that matter) where > the KVA is ignored and a kernel module will stuff its own vm_page_t's > into the pbuf. I have not researched all such occurances of these but > I would not expect it to be difficult to 'fix'. If they're synchronous > the local pages[] could be declared on the stack. I dunno. Physio is actually one of these... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 14:14:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 58B5D37B71C; Wed, 21 Mar 2001 14:14:38 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LMEV023966; Wed, 21 Mar 2001 14:14:31 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 14:14:31 -0800 (PST) From: Matt Dillon Message-Id: <200103212214.f2LMEV023966@earth.backplane.com> To: Poul-Henning Kamp Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89775.985211665@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :In message <200103212151.f2LLpii22172@earth.backplane.com>, Matt Dillon writes: : :> There are a few uses of pbuf's (and normal bufs for that matter) where :> the KVA is ignored and a kernel module will stuff its own vm_page_t's :> into the pbuf. I have not researched all such occurances of these but :> I would not expect it to be difficult to 'fix'. If they're synchronous :> the local pages[] could be declared on the stack. I dunno. : :Physio is actually one of these... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :phk@FreeBSD.ORG | TCP/IP since RFC 956 Yah. But it's also synchronous I believe. So you can declare a pages[] array on the stack with the correct size and assign the pbuf's b_pages to it. We still have to be careful in regards to kernel stack growth. 1MB/4096 = 256 elements = 1K of stack. That's a big problem. We could also create a pool of vm_page_t slots and then allocate blocks of slots out of the pool, though if we do that we have to worry about what happens if the pool runs out. The zalloc memory allocator mechanism I wrote for libstand (see /usr/src/lib/libstand/zalloc.c) would be perfect for this sort of pool allocator. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 14:15:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 8458F37B71B; Wed, 21 Mar 2001 14:15:51 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2LMFig23991; Wed, 21 Mar 2001 14:15:44 -0800 (PST) (envelope-from dillon) Date: Wed, 21 Mar 2001 14:15:44 -0800 (PST) From: Matt Dillon Message-Id: <200103212215.f2LMFig23991@earth.backplane.com> To: Poul-Henning Kamp Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89775.985211665@critter> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another possibility for physio would be to MALLOC the pages array at the very top level of the syscall and pass it down through for use by lower layers. At the very top level, before anything is locked, the MALLOC can block safely. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 14:24:53 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 370B037B71C for ; Wed, 21 Mar 2001 14:24:48 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2LMNfh02517; Wed, 21 Mar 2001 14:23:41 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103212223.f2LMNfh02517@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-reply-to: Your message of "Wed, 21 Mar 2001 14:14:31 PST." <200103212214.f2LMEV023966@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Mar 2001 14:23:41 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : > :Physio is actually one of these... > : > Yah. But it's also synchronous I believe. There's an async I/O interface to physio... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 14:26: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 108BD37B71D for ; Wed, 21 Mar 2001 14:26:00 -0800 (PST) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2LMOrh02530; Wed, 21 Mar 2001 14:24:53 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200103212224.f2LMOrh02530@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Matt Dillon Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-reply-to: Your message of "Wed, 21 Mar 2001 14:15:44 PST." <200103212215.f2LMFig23991@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Mar 2001 14:24:53 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Another possibility for physio would be to MALLOC the pages > array at the very top level of the syscall and pass it down > through for use by lower layers. At the very top level, > before anything is locked, the MALLOC can block safely. This would deal with the async physio case too. I'm wondering how all this will interact with the general desire to avoid mapping an I/O request into linear KVM before handing it to a driver; I suspect probably not a lot... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 14:33:20 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 7E8A337B71A; Wed, 21 Mar 2001 14:33:17 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GN5YZGFQ; Wed, 21 Mar 2001 17:33:20 -0500 Reply-To: Randell Jesup To: Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? References: <89046.985209441@critter> <200103212138.f2LLc8a21690@earth.backplane.com> From: Randell Jesup Date: 21 Mar 2001 17:34:44 -0500 In-Reply-To: Matt Dillon's message of "Wed, 21 Mar 2001 13:38:08 -0800 (PST)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matt Dillon writes: > When I last discussed MAXPHYS with people the issue that was predominant > was the b_pages[] array embedded in the struct buf and the pages[] arrays > declared in the VM paging code. I was worried that an increased MAXPHYS > eating too much kernel stack and too much kernel memory. We also have > the issue of the physical buffers (pbufs) reserving VM space permanently. > If you increase MAXPHYS you quickly start to hit kernel VM limitations. I seem to remember we thought that those could become pointers to arrays instead of in-line; or at least optionally so. CHeck the archives on freebsd.org for -arch; it wasn't that long ago. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 19:58:47 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 0C0CF37B71B; Wed, 21 Mar 2001 19:58:45 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id UAA11598; Wed, 21 Mar 2001 20:00:51 -0800 (PST) Date: Wed, 21 Mar 2001 20:00:50 -0800 (PST) From: Julian Elischer To: Matt Dillon Cc: Poul-Henning Kamp , Mike Smith , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: <200103212215.f2LMFig23991@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG it has always been my opinion that the kernel should only handle physical pages for these sorts of things and any device drive should convert to virtual if it needs it. 'buffers' should be stored as a list of physical pages, and that list could be used directly by IO routines wishing to queue IO on the buffer. similarly Physio should produce a list of physical pages instead of a kvm pointer. Physio can certainly mallooc such a physical list. (one needs to bear in mind aio in this discussion.) On Wed, 21 Mar 2001, Matt Dillon wrote: > Another possibility for physio would be to MALLOC the pages > array at the very top level of the syscall and pass it down > through for use by lower layers. At the very top level, > before anything is locked, the MALLOC can block safely. > > -Matt > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 20:11:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id BDA3D37B71E; Wed, 21 Mar 2001 20:10:51 -0800 (PST) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-117-202.nnj.dialup.bellatlantic.net [151.198.117.202]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id XAA12126; Wed, 21 Mar 2001 23:10:46 -0500 (EST) Message-ID: <3AB97B45.37E4957F@bellatlantic.net> Date: Wed, 21 Mar 2001 23:10:45 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: Terry Lambert Cc: fs@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: about common group & user ID space (PR kern/14584) References: <200103200521.WAA23451@usr05.primenet.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > > You could do this a bit more cleanly by just stealing the sign > > > bit, and setting if the uid field contained a group ID. > > > > > That was my original idea but some thinking and experimentation > > has shown that it creates too many incompatibilities, such as: > > > > - programs displaying the owner by name would break, and > > that includes both the standard programs and random applications > > - when exported by nfs, the same problem would stand for the > > clients > > - chown will have to be changed - both the program and system call, > > as you mention later > > > > and possibly other sorts of breakages. > > The NFS breakage is going to be there in any case; the semantics > will be different on the remote machine, giving ownership to a > particular user (who doesn't exist). This will turn "owner by > name" numeric at best, and give ownership to a particular person, > not group, at worst. It is expected that the people would bring their whole u/gid/namespace (or at least its portion described by the sysctls as common space) into the required consistent form before enabling this feature. This is why I don't want this feature enabled by default. I plan to implement it over NFS as well but if the NFS server does not support this feature, then yes, the ownership will be given to the pseudo-user with ID coinciding withthe group ID only (and if the namespace is consistent then such a pseudouser with the same name and id as the group must exist). > You also have the problem that the FreeBSD machine has to be > your NIS master; in a heterogeneous environment, Sun boxes are > still better NIS servers, since they understand the full > complement of NIS maps, which FreeBSD doesn't, and they support > automount (as opposed to amd, which happily requires a reboot > to unwedge in many situations). > > Any time you internalize or externalize a uid/gid space, you > will have that problem. No, I don't. The origin of the passwd/group files is irrelevant. Only their contents is important. And yes, if someone is using NIS, their choice would be to either set the commonalized portion of the ID space as local or make the ids/names unique in the NIS maps. Or, of course, not enable this feature. > Plus, with your approach, you are either going to have to make > an exception for certain ID ranges, permitting overlap, or you > are going to be stuck renumbering things like "bin" and "kmem". Yes, the common id range is tuned by sysctl. > Further, even if the FreeBSD was the NIS master for NFS name > interpretation, the only safe way to make the maps transportable > would be to have identical group and password name/ID pairs. > This breaks for normal duplication, which exists now: you can't > have two entries in either file for the same key field, since > a getpwuid or getgrgid will only return the first matching value > in all cases. That's why I consider the uniqueness rule so important in the distribution of uids/gids/names: - each user ang group must have a different name in the common namespace - each user ang group must have a different id in the common id space - for each group there must be a pseudo-user with the same ID and name and because by historical compatibility reasons applying these requirements to the whole id space is impossible, only part of the id space is enabled as compliant. > > > This changes the check to a one line change, conditional on > > > the high bit being set. > > > > No, the change would be the same, just wrapped into a condition > > check for this bit. > > I think you could "fudge" the in core copy of one id to be the > other, with the bit OR'ed in or AND'ed off, as appropriate... Hm, probably yes, they can be put into a loop. > > In the way I propose it, the sysadmins are supposed to create > > a pseudo-user with the same name and ID as each group. That > > This explodes when your remote NIS server doesn't enforce the > new semantics; this is sort of the opposite of the problem I > cite above with not being able to maintain a single namespace. The passwd/group files do not enforce it either. So it's just a convention to which the sysadmins should comply. If they can't comply they must not enable this feature. > I really think it's a lot easier to do this by stealing a bit > somewhere (second one down from the sign, if the sign is to be > held sacrosanct) than it is to rely on semantic enforcement by > your tools. As soon as you do that, it becomes significantly > less useful. At least with a stolen bit, the ownership on the > remote machine works, even if it doesn't precisely "make sense" > the same way it does on the hacked FreeBSD box. Wihtout the stolen bit it works on the remote machine as well, and even names will be shown properly because NFS implies the same users/groups on both machines. Just the permissions on the remote machines will be more restrictive. > The biggest problem is that the tools have to have a gentleman's > agreement between themselves across systems that everyone will > sign up to honor. That's really too kludgy to trust, unless you > are in a homogeneous environment (if then). Placing this as a > restriction makes the idea much, much less generally useful than > it would otherwise be. Well, the standard permissions scheme and especially NFS has this sort of agreement as well. Nothing stops an NFS client from assigning the IDs and names completely differently than on the server. Or another typical breakage is when an user in not listed in /etc/group for his primary group. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 20:26: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 29D2C37B71B for ; Wed, 21 Mar 2001 20:26:06 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id UAA72645; Wed, 21 Mar 2001 20:25:29 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200103220425.UAA72645@gndrsh.dnsmgr.net> Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: <200103212142.f2LLg1921851@earth.backplane.com> from Matt Dillon at "Mar 21, 2001 01:42:01 pm" To: dillon@earth.backplane.com (Matt Dillon) Date: Wed, 21 Mar 2001 20:25:28 -0800 (PST) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), mjacob@feral.com, arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ... > Perhaps a pages[] array covering the entire kernel VM space would be an > even better solution. 1G / 4K x 4 bytes = 1MB. Not a big deal. Please be carefull about making assumptions that all FreeBSD boxes run with 1G of kernel VM space: real memory = 1073725440 (1048560K bytes) avail memory = 1040474112 (1016088K bytes) Preloaded elf kernel "kernel" at 0x90294000. ^^ --- pmap.h.orig Fri Aug 4 18:31:07 2000 +++ pmap.h Tue Nov 28 14:59:17 2000 @@ -92,9 +92,9 @@ #endif #ifndef NKPDE #ifdef SMP -#define NKPDE 254 /* addressable number of page tables/pde's */ +#define NKPDE 446 /* addressable number of page tables/pde's */ #else -#define NKPDE 255 /* addressable number of page tables/pde's */ +#define NKPDE 447 /* addressable number of page tables/pde's */ #endif /* SMP */ #endif And our next round of machines will probably push this up to 3G of KVA space (yes, we are doing some very large stuff inside the kernel). -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 21:48:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 65ABF37B71E; Wed, 21 Mar 2001 21:48:31 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2M5mL194013; Thu, 22 Mar 2001 06:48:21 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mike Smith Cc: Matt Dillon , arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 14:24:53 PST." <200103212224.f2LMOrh02530@mass.dis.org> Date: Thu, 22 Mar 2001 06:48:21 +0100 Message-ID: <94011.985240101@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200103212224.f2LMOrh02530@mass.dis.org>, Mike Smith writes: >> Another possibility for physio would be to MALLOC the pages >> array at the very top level of the syscall and pass it down >> through for use by lower layers. At the very top level, >> before anything is locked, the MALLOC can block safely. > >This would deal with the async physio case too. > >I'm wondering how all this will interact with the general desire to avoid >mapping an I/O request into linear KVM before handing it to a driver; I >suspect probably not a lot... That is more dependent on fixing the device driver API than anything else. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 21:53:44 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9465B37B71B for ; Wed, 21 Mar 2001 21:53:40 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id VAA12998; Wed, 21 Mar 2001 21:53:41 -0800 Date: Wed, 21 Mar 2001 21:53:37 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: <94011.985240101@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Mar 2001, Poul-Henning Kamp wrote: > In message <200103212224.f2LMOrh02530@mass.dis.org>, Mike Smith writes: > >> Another possibility for physio would be to MALLOC the pages > >> array at the very top level of the syscall and pass it down > >> through for use by lower layers. At the very top level, > >> before anything is locked, the MALLOC can block safely. > > > >This would deal with the async physio case too. > > > >I'm wondering how all this will interact with the general desire to avoid > >mapping an I/O request into linear KVM before handing it to a driver; I > >suspect probably not a lot... > > That is more dependent on fixing the device driver API than anything > else. Device driver API? The device driver API should be busdma, shouldn't it? The platform implementation for busdma can figure out what it needs to do- probably without any driver having to actually look at anything but the data direction flags for a bio, no? If a bio request describes a physical page list, busdma converts this into the appropriate tokens for the bus the device's dma engine is on. If the bio request describes KVM, then the platform busdma code finds the physical pages and does the same. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 22: 0: 4 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id ACF1937B71C for ; Wed, 21 Mar 2001 21:59:59 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f2M5xl194554; Thu, 22 Mar 2001 06:59:47 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: Your message of "Wed, 21 Mar 2001 21:53:37 PST." Date: Thu, 22 Mar 2001 06:59:47 +0100 Message-ID: <94552.985240787@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Matthew Jacob writes: >On Thu, 22 Mar 2001, Poul-Henning Kamp wrote: > >> In message <200103212224.f2LMOrh02530@mass.dis.org>, Mike Smith writes: >> >> Another possibility for physio would be to MALLOC the pages >> >> array at the very top level of the syscall and pass it down >> >> through for use by lower layers. At the very top level, >> >> before anything is locked, the MALLOC can block safely. >> > >> >This would deal with the async physio case too. >> > >> >I'm wondering how all this will interact with the general desire to avoid >> >mapping an I/O request into linear KVM before handing it to a driver; I >> >suspect probably not a lot... >> >> That is more dependent on fixing the device driver API than anything >> else. > >Device driver API? The device driver API should be busdma, shouldn't it? We are talking about the devsw->strategy() API here. We need a way to stay moderately backwards compatible. The main change is to move b_pages into struct bio and find out how to identify drivers which need a mapping and give it to them in spec_strategy(); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Mar 21 22: 2:54 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1393937B71C for ; Wed, 21 Mar 2001 22:02:52 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id WAA13053; Wed, 21 Mar 2001 22:02:53 -0800 Date: Wed, 21 Mar 2001 22:02:49 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? In-Reply-To: <94552.985240787@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > >Device driver API? The device driver API should be busdma, shouldn't it? > > We are talking about the devsw->strategy() API here. We need a way to > stay moderately backwards compatible. > > The main change is to move b_pages into struct bio and find out how > to identify drivers which need a mapping and give it to them in > spec_strategy(); 'kay- sorry- I wasn't on topic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 2:52:28 2001 Delivered-To: freebsd-arch@freebsd.org Received: from garm.bart.nl (garm.bart.nl [194.158.170.13]) by hub.freebsd.org (Postfix) with ESMTP id 1215D37B72D; Thu, 22 Mar 2001 02:52:19 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.chronias.ninth-circle.org (root@cable.ninth-circle.org [195.38.232.6]) by garm.bart.nl (8.10.1/8.10.1) with ESMTP id f2MAqFY56398; Thu, 22 Mar 2001 11:52:15 +0100 (CET) Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.2/8.11.0) id f2MAqCR08023; Thu, 22 Mar 2001 11:52:12 +0100 (CET) (envelope-from asmodai) Date: Thu, 22 Mar 2001 11:52:12 +0100 From: Jeroen Ruigrok/Asmodai To: Peter Pentchev Cc: arch@freebsd.org, mark@freebsd.org Subject: Re: Replacing libmd with libcrypto [Was: Re: cvs commit: src/sys/sys md5.h src/lib/libmd Makefile md2.h md2c.c md4.h mdX.3 mdXhl.c ripemd.3 ripemd.h sha.3 sha.h] Message-ID: <20010322115212.B7147@daemon.ninth-circle.org> References: <20010319104137.E73138@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010319104137.E73138@ringworld.oblivion.bg>; from roam@orbitel.bg on Mon, Mar 19, 2001 at 10:41:37AM +0200 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20010319 10:00], Peter Pentchev (roam@orbitel.bg) wrote: >Okay, when you people are talking about replacing libmd with libcrypto, >do you mean moving the additional functionality of libmd to libcrypto, >or incorporating all the new and exciting functions into the OpenSSL >source? Using libcrypto what is now being linked to libmd. I did this, based on Mark's guidance a couple of weeks/months ago, and we didn't notice much problems. The only back then was that we weren't sure if SSL had md4 or something old which libmd still had. I remember Mark telling that that isn't an issue any more. >If the former, that would be more or less easily achieved - as pointed >out on -arch, libmd and libcrypto do seem to more or less share the basic >hash routines, so adding the code would be a matter of moving the mdX* >files from lib/libmd/ to secure/lib/libcrypto/ and adding them to >the libcrypto build process. This would still benefit from what this >commit is about - adding still more functionality to extend the OpenSSL >libraries. No need to move files from libmd to libcrypto. Libcrypto supports them natively. I already had a bunch of patches and Mark and me were discussing this back and forth in private for a while, but I am currently semi-out-of-business due to my primary machine at home having hardware issues. It will be replaced ASAP [when cash comes in again, this week or next] and then I am going to continue this work. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Sweet taste of vindication, It turns to ashes in your mouth... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 3: 0:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id C427437B71F for ; Thu, 22 Mar 2001 03:00:20 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 1542 invoked by uid 1000); 22 Mar 2001 10:59:27 -0000 Date: Thu, 22 Mar 2001 12:59:27 +0200 From: Peter Pentchev To: Jeroen Ruigrok/Asmodai Cc: arch@freebsd.org, mark@freebsd.org Subject: Re: Replacing libmd with libcrypto [Was: Re: cvs commit: src/sys/sys md5.h src/lib/libmd Makefile md2.h md2c.c md4.h mdX.3 mdXhl.c ripemd.3 ripemd.h sha.3 sha.h] Message-ID: <20010322125927.C1173@ringworld.oblivion.bg> Mail-Followup-To: Jeroen Ruigrok/Asmodai , arch@freebsd.org, mark@freebsd.org References: <20010319104137.E73138@ringworld.oblivion.bg> <20010322115212.B7147@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010322115212.B7147@daemon.ninth-circle.org>; from asmodai@wxs.nl on Thu, Mar 22, 2001 at 11:52:12AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm.. I know libcrypto supports the Init(), Update(), Final() and stuff.. what about the high-level functions though? *File(), *Data()? I wasn't able to find those anywhere under src/crypto/openssl/crypto/ .. G'luck, Peter -- Do you think anybody has ever had *precisely this thought* before? On Thu, Mar 22, 2001 at 11:52:12AM +0100, Jeroen Ruigrok/Asmodai wrote: > -On [20010319 10:00], Peter Pentchev (roam@orbitel.bg) wrote: > >Okay, when you people are talking about replacing libmd with libcrypto, > >do you mean moving the additional functionality of libmd to libcrypto, > >or incorporating all the new and exciting functions into the OpenSSL > >source? > > Using libcrypto what is now being linked to libmd. I did this, based on > Mark's guidance a couple of weeks/months ago, and we didn't notice much > problems. The only back then was that we weren't sure if SSL had md4 or > something old which libmd still had. > I remember Mark telling that that isn't an issue any more. > > >If the former, that would be more or less easily achieved - as pointed > >out on -arch, libmd and libcrypto do seem to more or less share the basic > >hash routines, so adding the code would be a matter of moving the mdX* > >files from lib/libmd/ to secure/lib/libcrypto/ and adding them to > >the libcrypto build process. This would still benefit from what this > >commit is about - adding still more functionality to extend the OpenSSL > >libraries. > > No need to move files from libmd to libcrypto. Libcrypto supports them > natively. > > I already had a bunch of patches and Mark and me were discussing this > back and forth in private for a while, but I am currently > semi-out-of-business due to my primary machine at home having hardware > issues. It will be replaced ASAP [when cash comes in again, this week > or next] and then I am going to continue this work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 11:47:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id D215937B71D for ; Thu, 22 Mar 2001 11:47:10 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id MAA04925 for ; Thu, 22 Mar 2001 12:41:02 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpdAAAKOaGHj; Thu Mar 22 12:40:50 2001 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id MAA15517 for arch@FreeBSD.ORG; Thu, 22 Mar 2001 12:46:55 -0700 (MST) From: Terry Lambert Message-Id: <200103221946.MAA15517@usr06.primenet.com> Subject: 4MB pages To: arch@FreeBSD.ORG Date: Thu, 22 Mar 2001 19:46:30 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I know that this is going to look like I should have posted it on the "-arch-questions" list, but there isn't one, and it involves future work (I think), so here goes... Has anyone tried playing with 4MB pages for doing other things? Specifically, has anyone played with them for mappings for all the text pages in an executable, or a large contiguous data mapping for something like a DVDROM or anonymous regions? I'm interested in playing around with this, and it seems to me the only place this flag is ever set is in the initial kernel mapping and mmap of physical devices? This is what pmap_bootstrap() and pmap_object_init_pt() leads me to believe... is this correct? That would imply that the DVD case would "just work", if the right dead chicken were waved over it... start, stop, size, etc. parameters to mmap() (would like to know if it needs a special kick in the pants). What about the /dev/zero case (to grab anonymous memory via mmap())? It seems that this would be incredibly useful for CPU emulation for something like running foreign code by mapping it into a big page in an emulator, and emulating the instruction set against the code, in memory. Will /dev/zero "just work" because it's a device (OBJT_DEVICE)? Will ALL devices "just work"? I can't tell what this would do to the pagability -- pmap_enter and family seem to want to panic, so would this only be useful on a machine with a huge amount of RAM, or only for using one page at a time as a window, if it were too large? As usual, I'm playing with 4.x, not 5.x, so feel free to tell me that this has already been thought of, and therefore is not an issue for -arch. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 12:48: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 7E35237B71A for ; Thu, 22 Mar 2001 12:47:50 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f2MKkMf51646 for ; Thu, 22 Mar 2001 22:47:07 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200103222047.f2MKkMf51646@gratis.grondar.za> To: arch@freebsd.org Subject: KAME, IPSec, OpenBSD and FreeBSD Date: Thu, 22 Mar 2001 22:47:30 +0200 From: Mark Murray Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I am busy porting the OpenBSD sys/crypto (kernel crypto lib) to FreeBSD. This will give us a good api and access to hardware encryption (which is a very good thing for IPSec on a busy server). It is 95% finished. I could use some volunteer help merging over the OpenBSD 'way of doing things' to FreeBSD. This involves a bit of KAME re-engineering and some other slog-work. Any offers? You'll need to be very familiar with how sys/netinet, sys/netinet6 and friends work. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 14:54:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 748E137B71B for ; Thu, 22 Mar 2001 14:54:21 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2MMs3G88237 for ; Thu, 22 Mar 2001 14:54:03 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.4.0.FreeBSD:010322145349:773=_" Date: Thu, 22 Mar 2001 14:53:53 -0800 (PST) From: John Baldwin To: arch@FreeBSD.org Subject: Critical Regions Round II Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.4.0.FreeBSD:010322145349:773=_ Content-Type: text/plain; charset=us-ascii Hopefully this will make everyone happy. Prior to SMPng we had the following functions related to interrupts: disable_intr() - x86 only and just did a 'cli' enable_intr() - x86 only and just did a 'sti' With the initial SMPng commit this was added to to allow nested disabling of interrupts: save_intr() - return current interrupt state restore_intr() - revert to previously read interrupt state Thus one would do: u_int foo; foo = save_intr(); disable_intr(); .... restore_intr(foo); Also, this entire API was forced out into MI code. After the discussion on the mailing list I propose the following that will hopefully make everyone happy: disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is a MD function enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a MD function save_intr() - gone restore_intr() - gone critical_enter() - enters a critical region of code that must not be preempted critical_exit() - leaves a critical region of code The critical_enter/exit functions use an opaque type 'critical_t' for the value that critical_enter() returns that must be passed to critical_exit(). Thus, the above code now becomes: critical_t foo; foo = critical_enter(); ... critical_exit(foo); This API includes the same optimizations mentioned for the Alpha as the last proposal. A manpage for critical_enter/exit is attached. -- 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/ --_=XFMail.1.4.0.FreeBSD:010322145349:773=_ Content-Disposition: attachment; filename="critical_enter.9" Content-Transfer-Encoding: 7bit Content-Description: critical_enter.9 Content-Type: text/plain; charset=us-ascii; name=critical_enter.9; SizeOnDisk=3235 .\" Copyright (c) 2001 John H. Baldwin .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" $FreeBSD$ .\" .Dd March 22, 2001 .Dt CRITICAL_ENTER 9 .Os .Sh NAME .Nm critical_enter , .Nm critical_exit .Nd enter and exit a critical region .Sh SYNOPSIS .Fd #include .Fd #include .Ft critical_t .Fn critical_enter "void" .Ft void .Fn critical_exit "critical_t savecrit" .Sh DESCRIPTION These functions are used to prevent preemption in a critcal region of code. All that is guaranteed is that the current CPU will not be preempted by an external interrupt. The current CPU may still trigger faults and exceptions during a critical section. The .Fn critical_enter function returns an opaque value of type .Vt critical_t . This value must be passed to the .Fn critical_exit function when leaving the critical region. .Pp Note that these functions are not required to provide any inter-CPU synchronization, data protection, or memory ordering guarantees and thus should .Sy not be used to protect shared data structures. .Pp These functions should be used with care as an infinite loop within a critical region will deadlock the CPU. .Sh RETURN VALUES The .Fn critical_enter function returns an opaque value that must be passed to a corresponding call to .Fn critical_exit . .Sh EXAMPLES This example demonstrates the use of .Fn critical_enter and .Fn critical_exit to guarantee atomic access to the DMA controller. .Bd -literal -offset indent int isa_dmastatus(int chan) { u_long cnt = 0; int ffport, waport; u_long low1, high1, low2, high2; critical_t savecrit; ... savecrit = critical_enter(); outb(ffport, 0); low1 = inb(waport); high1 = inb(waport); outb(ffport, 0); low2 = inb(waport); high2 = inb(waport); critical_exit(savecrit); ... } .Ed .Sh HISTORY These functions were introduced in .Fx 5.0 . --_=XFMail.1.4.0.FreeBSD:010322145349:773=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 15:13:50 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C1A3237B719; Thu, 22 Mar 2001 15:13:45 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA16990; Thu, 22 Mar 2001 15:13:50 -0800 Date: Thu, 22 Mar 2001 15:13:45 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG critical_enter/critical_exit seem fine, but you can save yourself some compiler space by just having it return a void *. What's wrong with alpha having disable_intr() calls MD/platform function that disables mainbridge ints enable_intr() calls MD/platform function that enables mainbridge ints I believe that this actually is possible. > Hopefully this will make everyone happy. > > Prior to SMPng we had the following functions related to interrupts: > > disable_intr() - x86 only and just did a 'cli' > enable_intr() - x86 only and just did a 'sti' > > With the initial SMPng commit this was added to to allow nested disabling > of interrupts: > > save_intr() - return current interrupt state > restore_intr() - revert to previously read interrupt state > > Thus one would do: > > u_int foo; > > foo = save_intr(); > disable_intr(); > .... > restore_intr(foo); > > Also, this entire API was forced out into MI code. After the discussion on > the mailing list I propose the following that will hopefully make everyone > happy: > > disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is > a MD function > enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a > MD function > > save_intr() - gone > restore_intr() - gone > > critical_enter() - enters a critical region of code that must not be > preempted > critical_exit() - leaves a critical region of code > > The critical_enter/exit functions use an opaque type 'critical_t' for the > value that critical_enter() returns that must be passed to critical_exit(). > Thus, the above code now becomes: > > critical_t foo; > > foo = critical_enter(); > ... > critical_exit(foo); > > This API includes the same optimizations mentioned for the Alpha as the > last proposal. A manpage for critical_enter/exit is attached. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 15:32:41 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6836337B71B for ; Thu, 22 Mar 2001 15:32:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2MNW9G89289; Thu, 22 Mar 2001 15:32:09 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Thu, 22 Mar 2001 15:32:00 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Mar-01 Matthew Jacob wrote: > > critical_enter/critical_exit seem fine, but you can save yourself some > compiler space by just having it return a void *. So far critical_t is a register_t on all arch's it is implemented on so far. Well, it probably should be a register_t, I think I'm using __uint32_t and the like right now: x86: /* Critical section value */ typedef __uint32_t critical_t; alpha: /* Critical section value */ typedef __uint32_t critical_t; ia64: /* Critical section value */ typedef __uint64_t critical_t; Hrm, is a ldq any different from a ldl to the alpha? If ldq is faster I could make it be a register_t (and thus a __int64_t). I'll probably change it to register_t on x86 and ia64 as it simply holds the saved value of a register (eflags on x86, psr on ia64). > What's wrong with alpha having > > disable_intr() calls MD/platform function that disables mainbridge ints > enable_intr() calls MD/platform function that enables mainbridge ints > > I believe that this actually is possible. That's fine, however, with this change, disable/enable_intr() are actually called in very few places. Mostly in trap() on x86 due to hacks to work around Cyrix bugs, and in configure(). Everything else uses critical_*. Well, the joy driver needs fixing (it should use critical_*) as does the bktr driver. The x86 pcvt driver is also obnoxious, but its x86 specific, and the pc98 spkr and dma drivers should be using critical_* so that they work in a nested fashion. Hmm, and x86 profiling, though again, that can use critical_*. Kernel x86 profiling with SMP is broken in lots of interesting ways. >> Hopefully this will make everyone happy. >> >> Prior to SMPng we had the following functions related to interrupts: >> >> disable_intr() - x86 only and just did a 'cli' >> enable_intr() - x86 only and just did a 'sti' >> >> With the initial SMPng commit this was added to to allow nested disabling >> of interrupts: >> >> save_intr() - return current interrupt state >> restore_intr() - revert to previously read interrupt state >> >> Thus one would do: >> >> u_int foo; >> >> foo = save_intr(); >> disable_intr(); >> .... >> restore_intr(foo); >> >> Also, this entire API was forced out into MI code. After the discussion on >> the mailing list I propose the following that will hopefully make everyone >> happy: >> >> disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is >> a MD function >> enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a >> MD function >> >> save_intr() - gone >> restore_intr() - gone >> >> critical_enter() - enters a critical region of code that must not be >> preempted >> critical_exit() - leaves a critical region of code >> >> The critical_enter/exit functions use an opaque type 'critical_t' for the >> value that critical_enter() returns that must be passed to critical_exit(). >> Thus, the above code now becomes: >> >> critical_t foo; >> >> foo = critical_enter(); >> ... >> critical_exit(foo); >> >> This API includes the same optimizations mentioned for the Alpha as the >> last proposal. A manpage for critical_enter/exit is attached. >> >> > -- 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 Thu Mar 22 15:47: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3813137B71C; Thu, 22 Mar 2001 15:47:03 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA17127; Thu, 22 Mar 2001 15:47:07 -0800 Date: Thu, 22 Mar 2001 15:47:02 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Mar 2001, John Baldwin wrote: > > On 22-Mar-01 Matthew Jacob wrote: > > > > critical_enter/critical_exit seem fine, but you can save yourself some > > compiler space by just having it return a void *. > > So far critical_t is a register_t on all arch's it is implemented on so far. > Well, it probably should be a register_t, I think I'm using __uint32_t and > the like right now: > > x86: > /* Critical section value */ > typedef __uint32_t critical_t; > > alpha: > /* Critical section value */ > typedef __uint32_t critical_t; > > ia64: > /* Critical section value */ > typedef __uint64_t critical_t; > > Hrm, is a ldq any different from a ldl to the alpha? Umm... yup... 8 bytes instead of 4... > If ldq is faster I could > make it be a register_t (and thus a __int64_t). I'll probably change it to > register_t on x86 and ia64 as it simply holds the saved value of a register > (eflags on x86, psr on ia64). I don't think the speed is an issue either way. > > > What's wrong with alpha having > > > > disable_intr() calls MD/platform function that disables mainbridge > ints > > enable_intr() calls MD/platform function that enables mainbridge ints > > > > I believe that this actually is possible. > > That's fine, however, with this change, disable/enable_intr() are actually > called in very few places. Mostly in trap() on x86 due to hacks to work around > Cyrix bugs, and in configure(). Everything else uses critical_*. > > Well, the joy driver needs fixing (it should use critical_*) as does the bktr > driver. The x86 pcvt driver is also obnoxious, but its x86 specific, and the > pc98 spkr and dma drivers should be using critical_* so that they work in a > nested fashion. Hmm, and x86 profiling, though again, that can use critical_*. > Kernel x86 profiling with SMP is broken in lots of interesting ways. Let's put it this way...if I have to solve what appear to be obscure bugs by disabling interrupts in the alpha MD code somewhere, I'll instantiate such a function (again) if it's no longer there. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 16:42:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id C270F37B71F for ; Thu, 22 Mar 2001 16:42:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2N0gBG91278; Thu, 22 Mar 2001 16:42:11 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Thu, 22 Mar 2001 16:42:03 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Mar-01 Matthew Jacob wrote: >> Hrm, is a ldq any different from a ldl to the alpha? > > Umm... yup... 8 bytes instead of 4... I meant more in terms of speed, sorry. :) I knew the 8 vs. 4 bit. :) >> If ldq is faster I could >> make it be a register_t (and thus a __int64_t). I'll probably change it to >> register_t on x86 and ia64 as it simply holds the saved value of a register >> (eflags on x86, psr on ia64). > > I don't think the speed is an issue either way. Ok, then I'll use register_t since the IPL is part of the process status register and since it's put in a0 before the PAL call.. >> > What's wrong with alpha having >> > >> > disable_intr() calls MD/platform function that disables >> > mainbridge >> ints >> > enable_intr() calls MD/platform function that enables mainbridge ints >> > >> > I believe that this actually is possible. >> >> That's fine, however, with this change, disable/enable_intr() are actually >> called in very few places. Mostly in trap() on x86 due to hacks to work >> around >> Cyrix bugs, and in configure(). Everything else uses critical_*. >> >> Well, the joy driver needs fixing (it should use critical_*) as does the >> bktr >> driver. The x86 pcvt driver is also obnoxious, but its x86 specific, and >> the >> pc98 spkr and dma drivers should be using critical_* so that they work in a >> nested fashion. Hmm, and x86 profiling, though again, that can use >> critical_*. >> Kernel x86 profiling with SMP is broken in lots of interesting ways. > > > Let's put it this way...if I have to solve what appear to be obscure bugs by > disabling interrupts in the alpha MD code somewhere, I'll instantiate such a > function (again) if it's no longer there. Ok. Or you could always just call alpha_pal_swpipl(). :) -- 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 Thu Mar 22 16:45:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F6CE37B71D; Thu, 22 Mar 2001 16:45:44 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA17388; Thu, 22 Mar 2001 16:45:48 -0800 Date: Thu, 22 Mar 2001 16:45:43 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Let's put it this way...if I have to solve what appear to be obscure bugs by > > disabling interrupts in the alpha MD code somewhere, I'll instantiate such a > > function (again) if it's no longer there. > > Ok. Or you could always just call alpha_pal_swpipl(). :) I could. But I might actually want to hit the mainbridge source. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 17: 3:17 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 427EB37B71B for ; Thu, 22 Mar 2001 17:03:12 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2N12pG91964; Thu, 22 Mar 2001 17:02:51 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Thu, 22 Mar 2001 17:02:42 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Mar-01 Matthew Jacob wrote: > >> > Let's put it this way...if I have to solve what appear to be obscure bugs >> > by >> > disabling interrupts in the alpha MD code somewhere, I'll instantiate such >> > a >> > function (again) if it's no longer there. >> >> Ok. Or you could always just call alpha_pal_swpipl(). :) > > I could. But I might actually want to hit the mainbridge source. That would be different from the current disable/enable_intr functions on x86 and ia64, which actually toggle CPU state. On the alpha this is akin to dinking with the IPL. AFAIK, there is no common API for accessing mainbridge/ICU masks to disable individual sources. On x86 we use individual outb's to the ICU's (or writes to the I/O APIC for SMP) and on the alpha we have the platform foo_enable/disable_intr() hooks. On ia64 we don't bother with external interrupts yet. :) However, this leaves enable/disable_intr() as MD functions that are purely up to whatever use a given arch finds for them should it choose to implement them. But I think we are mostly just agreeing with each other. -- 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 Thu Mar 22 17: 5:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B056D37B71F; Thu, 22 Mar 2001 17:05:46 -0800 (PST) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id RAA17533; Thu, 22 Mar 2001 17:05:50 -0800 Date: Thu, 22 Mar 2001 17:05:46 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > MD functions that are purely up to whatever use a given arch finds for them > should it choose to implement them. But I think we are mostly just agreeing > with each other. I agree. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 22:37:49 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BA45237B71B; Thu, 22 Mar 2001 22:37:38 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA08481; Fri, 23 Mar 2001 17:37:36 +1100 Date: Fri, 23 Mar 2001 17:36:48 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.ORG Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Mar 2001, John Baldwin wrote: > Hopefully this will make everyone happy. You are an optimist :-). > Prior to SMPng we had the following functions related to interrupts: > > disable_intr() - x86 only and just did a 'cli' > enable_intr() - x86 only and just did a 'sti' SMPog actually made these do things like 'cli(); s_lock(&clock_lock)' in many cases (most of the non-broken cases). > With the initial SMPng commit this was added to to allow nested disabling > of interrupts: I originally tried hard to avoid nested disabling of interrupts. The x86 functions to support it were intentionally left out of early versions of the x86 cpufunc.h. The principle is that nested disabling of interrupts is as evil as recursive locking. However, it is very convenient. It was necessary to support profiling of code that is running with interrupts disabled (even though that code disabled interrupts to prevent potentially lengthy interference by things like profilers), so support for it was added in rev.1.21 of the x86 cpufunc.h. It is necessary to support debugging of code that os running with interrupts disabled (even though interference by debuggers screws up the timing much worse than interference by profilers). > save_intr() - return current interrupt state > restore_intr() - revert to previously read interrupt state This was really a renaming of the x86-specific interfaces read_eflags() and write_eflags(). I object to the x86 code being changed to use the new names. The x86 code that disables interrupts mostly wants precisely the MD interfaces, not the MI abstraction of them. It just happens that the MI versions are binary-identical with the MD versions. > Also, this entire API was forced out into MI code. After the discussion on > the mailing list I propose the following that will hopefully make everyone > happy: > > disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is > a MD function > enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a > MD function I want these to be named cli() and sti() for x86 only (maybe clpsri() and stpsri() for ia64 :-). MD functions should have MD names. > save_intr() - gone > restore_intr() - gone The MD versions of these may still be needed to implement critical_*(). > critical_enter() - enters a critical region of code that must not be > preempted > critical_exit() - leaves a critical region of code > > The critical_enter/exit functions use an opaque type 'critical_t' for the > value that critical_enter() returns that must be passed to critical_exit(). OK, but see other replies. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Mar 22 23:26: 3 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 8917737B718; Thu, 22 Mar 2001 23:25:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA12815; Fri, 23 Mar 2001 18:25:56 +1100 Date: Fri, 23 Mar 2001 18:25:09 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: Matthew Jacob , arch@FreeBSD.ORG Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Mar 2001, John Baldwin wrote: > On 22-Mar-01 Matthew Jacob wrote: > > What's wrong with alpha having > > > > disable_intr() calls MD/platform function that disables mainbridge > ints > > enable_intr() calls MD/platform function that enables mainbridge ints 1. Someone might use them in MI code if they have generic names like that. 2. The MD versions might be a little different from the MI versions and from each other, so they should have different names. > That's fine, however, with this change, disable/enable_intr() are actually > called in very few places. Mostly in trap() on x86 due to hacks to work around > Cyrix bugs, and in configure(). Everything else uses critical_*. > > Well, the joy driver needs fixing (it should use critical_*) as does the bktr > driver. The x86 pcvt driver is also obnoxious, but its x86 specific, and the > pc98 spkr and dma drivers should be using critical_* so that they work in a > nested fashion. Most of these drivers show how not to use disable_intr(). I think most of them should have used splhigh(). The translation of splhigh() to SMPng is mtx_lock*() plus maybe giving the driver a realtime priority, not critical_enter(). > Hmm, and x86 profiling, though again, that can use critical_*. > Kernel x86 profiling with SMP is broken in lots of interesting ways. Profiling for all arches currently needs to use something both more and less than critical_*: - more, because the profiling state is shared between all CPUs. I guess disabling interrupts will be sufficient when profiling works properly under SMP. I don't see how call graphs can work if calls for all CPUs are recorded in the same profiling state. - less, because critical_* should be subject to profiling, so it can't be called from profiling code. Profiling can easily use MD interfaces for locking since what it uses is defined by the MD macros MCOUNT_DECL(), MCOUNT_ENTER() and MCOUNT_EXIT(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 7:27:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from light.imasy.or.jp (light.imasy.or.jp [202.227.24.4]) by hub.freebsd.org (Postfix) with ESMTP id 0514C37B71A for ; Fri, 23 Mar 2001 07:27:21 -0800 (PST) (envelope-from ume@FreeBSD.org) Received: (from uucp@localhost) by light.imasy.or.jp (8.11.3+3.4W/8.11.3/light) with UUCP id f2NFR1C28223; Sat, 24 Mar 2001 00:27:01 +0900 (JST) (envelope-from ume@FreeBSD.org) Received: from peace.mahoroba.org (IDENT:TAOxqZG/ItJAfnYWfNyrXKkQXQg6bFpnqyTRZ0x3H7+G646XFTs4T6ZO7tomjtHz@peace.mahoroba.org [3ffe:505:2:0:200:f8ff:fe05:3eae]) by mail.mahoroba.org (8.11.3/8.11.3/chaos) with ESMTP/inet6 id f2NFN8624017; Sat, 24 Mar 2001 00:23:09 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Sat, 24 Mar 2001 00:23:08 +0900 (JST) Message-Id: <20010324.002308.36954645.ume@FreeBSD.org> To: mark@grondar.za Cc: arch@freebsd.org Subject: Re: KAME, IPSec, OpenBSD and FreeBSD From: Hajimu UMEMOTO In-Reply-To: <200103222047.f2MKkMf51646@gratis.grondar.za> References: <200103222047.f2MKkMf51646@gratis.grondar.za> X-Mailer: xcite1.38> Mew version 1.95b115 on Emacs 20.7 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91 05 D0 B3 EF 36 9B 6A BC X-URL: http://www.imasy.org/~ume/ X-OS: FreeBSD 5.0-CURRENT Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Thu, 22 Mar 2001 22:47:30 +0200 >>>>> Mark Murray said: mark> Any offers? You'll need to be very familiar with how mark> sys/netinet, sys/netinet6 and friends work. I just sent to you directry, then the mail was rejected. I dunno why. So, I reply to this mail. >>>>> On Thu, 22 Mar 2001 12:01:32 +0200 >>>>> Mark Murray said: mark> I am very interested in improving FreeBSD's in-kernel crypto, and mark> I'd like to use the OpenBSD code. Amongs other things, this will mark> give us access to excellent hardware encryption. Since, KAME is ported to all BSDs which includes OpenBSD, I think it should be once merged to KAME, then porting to FreeBSD is better. Since IPsec part of FreeBSD came from KAME and IPsec is still working progress in KAME, I suggest that you should ask KAME guys (especially itojun) about the possibility of merging. mark> Are you able to help with this to get the rest of the kernel mark> (the IPSec and IPv6 stuff) working? Sorry, I'm too busy now with supporting IPv6 for CVSup and other IPv6 related issue. BTW, I'll start merging recent KAME into 5-CURRENT after 4.3-RELEASE is out. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 12:30: 8 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 0E12037B71A; Fri, 23 Mar 2001 12:30:04 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id MAA07048; Fri, 23 Mar 2001 12:28:00 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.1/8.11.1) id f2NKRS928064; Fri, 23 Mar 2001 12:27:28 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200103232027.f2NKRS928064@arch20m.dellroad.org> Subject: Re: Critical Regions Round II In-Reply-To: "from John Baldwin at Mar 22, 2001 02:53:53 pm" To: John Baldwin Date: Fri, 23 Mar 2001 12:27:28 -0800 (PST) Cc: arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin writes: > Also, this entire API was forced out into MI code. After the discussion on > the mailing list I propose the following that will hopefully make everyone > happy: > > disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is > a MD function > enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a > MD function Apologies in advance if I'm missing something obvious.. Shouldn't these be, e.g., i386_disable_intr(), i386_enable_intr() and ia64_enable_intr(), ia64_disable_intr() That is, it seems like "machine dependent" has a strict meaning, it means: specific to a single (one) architecture. Or are we expecting to have code that looks like this: #if defined(__i386__) || defined(__ia64__) disable_intr() #endif ?? -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 13:50:21 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 78A0237B719; Fri, 23 Mar 2001 13:50:11 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id OAA08205; Fri, 23 Mar 2001 14:50:10 -0700 (MST) (envelope-from ken) Date: Fri, 23 Mar 2001 14:50:10 -0700 From: "Kenneth D. Merry" To: scsi@FreeBSD.org Cc: arch@FreeBSD.org Subject: CAM error recovery changes going in on Monday Message-ID: <20010323145010.A8162@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is just a heads-up to everyone that the CAM error recovery changes will be going into -current on Monday, barring any unforseen problems. This is a substantial re-write of the error recovery code. It includes adding a new library, libsbuf, so that sbufs will be available to userland applications. The sbuf stuff has been reviewed by DES, and the makefile framework for the library has been reviewed by Marcel and John Polstra. The latest diffs are available here: http://people.FreeBSD.org/~ken/cam.error_recovery_diffs.20010323 (about 268K, 9000+ lines of context diffs) Anyway, if anyone has any comments, problems, feedback, etc., please let me know. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 14:16:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id B9F6737B71A; Fri, 23 Mar 2001 14:16:07 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.3/8.9.1) id XAA22937; Fri, 23 Mar 2001 23:16:02 +0100 (CET) (envelope-from sos) From: Soren Schmidt Message-Id: <200103232216.XAA22937@freebsd.dk> Subject: Re: CAM error recovery changes going in on Monday In-Reply-To: <20010323145010.A8162@panzer.kdm.org> from "Kenneth D. Merry" at "Mar 23, 2001 02:50:10 pm" To: ken@kdm.org (Kenneth D. Merry) Date: Fri, 23 Mar 2001 23:16:02 +0100 (CET) Cc: scsi@FreeBSD.ORG, arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Kenneth D. Merry wrote: > > This is just a heads-up to everyone that the CAM error recovery changes > will be going into -current on Monday, barring any unforseen problems. > > This is a substantial re-write of the error recovery code. It includes > adding a new library, libsbuf, so that sbufs will be available to userland > applications. > > The sbuf stuff has been reviewed by DES, and the makefile framework for the > library has been reviewed by Marcel and John Polstra. > > The latest diffs are available here: > > http://people.FreeBSD.org/~ken/cam.error_recovery_diffs.20010323 > > (about 268K, 9000+ lines of context diffs) > > Anyway, if anyone has any comments, problems, feedback, etc., please let me > know. Thats not going to be easy: fetch: cam.error_recovery_diffs.20010323: Forbidden -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 15: 0:43 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 884FF37B719; Fri, 23 Mar 2001 15:00:36 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA08750; Fri, 23 Mar 2001 16:00:27 -0700 (MST) (envelope-from ken) Date: Fri, 23 Mar 2001 16:00:27 -0700 From: "Kenneth D. Merry" To: Soren Schmidt Cc: scsi@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: CAM error recovery changes going in on Monday Message-ID: <20010323160027.A8720@panzer.kdm.org> References: <20010323145010.A8162@panzer.kdm.org> <200103232216.XAA22937@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200103232216.XAA22937@freebsd.dk>; from sos@freebsd.dk on Fri, Mar 23, 2001 at 11:16:02PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 23, 2001 at 23:16:02 +0100, Soren Schmidt wrote: > It seems Kenneth D. Merry wrote: > > > > This is just a heads-up to everyone that the CAM error recovery changes > > will be going into -current on Monday, barring any unforseen problems. > > > > This is a substantial re-write of the error recovery code. It includes > > adding a new library, libsbuf, so that sbufs will be available to userland > > applications. > > > > The sbuf stuff has been reviewed by DES, and the makefile framework for the > > library has been reviewed by Marcel and John Polstra. > > > > The latest diffs are available here: > > > > http://people.FreeBSD.org/~ken/cam.error_recovery_diffs.20010323 > > > > (about 268K, 9000+ lines of context diffs) > > > > Anyway, if anyone has any comments, problems, feedback, etc., please let me > > know. > > Thats not going to be easy: > > fetch: cam.error_recovery_diffs.20010323: Forbidden Oops, fixed. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 18:27:15 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 09F6D37B725 for ; Fri, 23 Mar 2001 18:26:48 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2O2PuG30907; Fri, 23 Mar 2001 18:25:57 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Fri, 23 Mar 2001 18:26:05 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org, Matthew Jacob Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Mar-01 Bruce Evans wrote: > On Thu, 22 Mar 2001, John Baldwin wrote: > >> On 22-Mar-01 Matthew Jacob wrote: >> > What's wrong with alpha having >> > >> > disable_intr() calls MD/platform function that disables >> > mainbridge >> ints >> > enable_intr() calls MD/platform function that enables mainbridge ints > > 1. Someone might use them in MI code if they have generic names like that. > 2. The MD versions might be a little different from the MI versions and > from each other, so they should have different names. > >> That's fine, however, with this change, disable/enable_intr() are actually >> called in very few places. Mostly in trap() on x86 due to hacks to work >> around >> Cyrix bugs, and in configure(). Everything else uses critical_*. >> >> Well, the joy driver needs fixing (it should use critical_*) as does the >> bktr >> driver. The x86 pcvt driver is also obnoxious, but its x86 specific, and >> the >> pc98 spkr and dma drivers should be using critical_* so that they work in a >> nested fashion. > > Most of these drivers show how not to use disable_intr(). I think most > of them should have used splhigh(). The translation of splhigh() to > SMPng is mtx_lock*() plus maybe giving the driver a realtime priority, > not critical_enter(). Ok. Hmm, the only things that I think really need critical_enter() would be some of the i386 cpu init stuff and drivers that use fast interrupt handlers? I can actually provide a list of things that use critical_enter/exit now that can be at least converted to splfoo(). Actually, the joy driver only uses disable/enable_intr on x86 and uses splfoo() on the alpha, though I think it really does need critical_enter/exit, as it uses while doing the actual inb's on the joy data port. Although, I'm not sure how well that will work on SMP where a fast interrupt could always trigger on another CPU while the first CPU is in a driver. Using a spinlock would make this work as far as protecting the shared data in question, but then you have the CPU getting the interrupt spinning in a loop until the other CPU releases it. I guess this is how it works in 4.x for fast interrupts though. >> Hmm, and x86 profiling, though again, that can use critical_*. >> Kernel x86 profiling with SMP is broken in lots of interesting ways. > > Profiling for all arches currently needs to use something both more > and less than critical_*: > - more, because the profiling state is shared between all CPUs. I guess > disabling interrupts will be sufficient when profiling works properly > under SMP. I don't see how call graphs can work if calls for all CPUs > are recorded in the same profiling state. Hmmmm. This will need to use per-CPU profiling state then, unless we are going to destroy all parallelism in the kernel in the profiling case. :( > - less, because critical_* should be subject to profiling, so it can't > be called from profiling code. They are static inlines, though, correct? So they shouldn't be calling mcount? Or am I wrong about inlines and mcount? Also, I think I may have a somewhat ugly way of fixing the SMP mcount_enter/mcount_exit. (side note) > Profiling can easily use MD interfaces for locking since what it uses is > defined by the MD macros MCOUNT_DECL(), MCOUNT_ENTER() and MCOUNT_EXIT(). > > Bruce -- 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 Fri Mar 23 18:27:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 098E537B724 for ; Fri, 23 Mar 2001 18:26:48 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2O2PwG30911; Fri, 23 Mar 2001 18:25:58 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Fri, 23 Mar 2001 18:26:07 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Mar-01 Bruce Evans wrote: > On Thu, 22 Mar 2001, John Baldwin wrote: > >> Hopefully this will make everyone happy. > > You are an optimist :-). Apparently, though I'd like to get this done soon, as it is holding up other work (I have too many interdependent patch sets on my laptop). >> Prior to SMPng we had the following functions related to interrupts: >> >> disable_intr() - x86 only and just did a 'cli' >> enable_intr() - x86 only and just did a 'sti' > > SMPog actually made these do things like 'cli(); s_lock(&clock_lock)' > in many cases (most of the non-broken cases). Yes, for sio/cy, etc. >> With the initial SMPng commit this was added to to allow nested disabling >> of interrupts: > > I originally tried hard to avoid nested disabling of interrupts. The > x86 functions to support it were intentionally left out of early > versions of the x86 cpufunc.h. The principle is that nested disabling > of interrupts is as evil as recursive locking. However, it is very > convenient. It was necessary to support profiling of code that is > running with interrupts disabled (even though that code disabled > interrupts to prevent potentially lengthy interference by things like > profilers), so support for it was added in rev.1.21 of the x86 cpufunc.h. > It is necessary to support debugging of code that os running with > interrupts disabled (even though interference by debuggers screws up > the timing much worse than interference by profilers). It's also needed for recursive locking of spinlocks, or for another spinlock to be acquired while holding some other spinlock. (We can't allow preemption while holding a spinlock or we can get into trivial deadlocks.) >> save_intr() - return current interrupt state >> restore_intr() - revert to previously read interrupt state > > This was really a renaming of the x86-specific interfaces read_eflags() > and write_eflags(). I object to the x86 code being changed to use the > new names. The x86 code that disables interrupts mostly wants precisely > the MD interfaces, not the MI abstraction of them. It just happens that > the MI versions are binary-identical with the MD versions. Ok, I could go with that. (/me deletes half of his patch.) >> Also, this entire API was forced out into MI code. After the discussion on >> the mailing list I propose the following that will hopefully make everyone >> happy: >> >> disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is >> a MD function >> enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a >> MD function > > I want these to be named cli() and sti() for x86 only (maybe clpsri() and > stpsri() for ia64 :-). MD functions should have MD names. Ok. >> save_intr() - gone >> restore_intr() - gone > > The MD versions of these may still be needed to implement critical_*(). Yes, in fact they are. critical_enter() on x86 uses read_eflags/disable_intr, and critical_exit() uses write_eflags(). On the alpha both functions just call alpha_pal_swpipl(), and on ia64 it is somewhat similar to x86. >> critical_enter() - enters a critical region of code that must not be >> preempted >> critical_exit() - leaves a critical region of code >> >> The critical_enter/exit functions use an opaque type 'critical_t' for the >> value that critical_enter() returns that must be passed to critical_exit(). > > OK, but see other replies. Ok, I'll try and separate this from my other patches and put it up for people to gawk at^H^H^H^H^H^H^Hreview. > Bruce -- 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 Fri Mar 23 18:27:24 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 93F8037B732 for ; Fri, 23 Mar 2001 18:27:13 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2O2Q3G30932; Fri, 23 Mar 2001 18:26:03 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <200103232027.f2NKRS928064@arch20m.dellroad.org> Date: Fri, 23 Mar 2001 18:26:12 -0800 (PST) From: John Baldwin To: Archie Cobbs Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Mar-01 Archie Cobbs wrote: > John Baldwin writes: >> Also, this entire API was forced out into MI code. After the discussion on >> the mailing list I propose the following that will hopefully make everyone >> happy: >> >> disable_intr() - x86 / ia64 only, just clears the IF or psr.i bit, and is >> a MD function >> enable_intr() - x86 / ia64 only, just sets the IF or psr.i bit, and is a >> MD function > > Apologies in advance if I'm missing something obvious.. > > Shouldn't these be, e.g., > > i386_disable_intr(), i386_enable_intr() > > and > > ia64_enable_intr(), ia64_disable_intr() > > That is, it seems like "machine dependent" has a strict meaning, > it means: specific to a single (one) architecture. Sticking all MD stuff under a ${MACHINE_ARCH}_* namespace might be an interesting project in the future, but it wouldn't be a small undertaking. > Or are we expecting to have code that looks like this: > > #if defined(__i386__) || defined(__ia64__) > disable_intr() > #endif > > ?? No, this code should not be used outside of sys/${MACHINE_ARCH}, which is mostly how things were (aside from broken things like the joy driver) before SMPng. -- 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 Fri Mar 23 19: 0:14 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 31A6E37B71A; Fri, 23 Mar 2001 19:00:08 -0800 (PST) (envelope-from archie@dellroad.org) Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id SAA09300; Fri, 23 Mar 2001 18:55:54 -0800 (PST) Received: (from archie@localhost) by arch20m.dellroad.org (8.11.1/8.11.1) id f2O2tM029010; Fri, 23 Mar 2001 18:55:22 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200103240255.f2O2tM029010@arch20m.dellroad.org> Subject: Re: Critical Regions Round II In-Reply-To: "from John Baldwin at Mar 23, 2001 06:26:12 pm" To: John Baldwin Date: Fri, 23 Mar 2001 18:55:22 -0800 (PST) Cc: arch@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin writes: > > Shouldn't these be, e.g., > > > > i386_disable_intr(), i386_enable_intr() > > > > and > > > > ia64_enable_intr(), ia64_disable_intr() > > > > That is, it seems like "machine dependent" has a strict meaning, > > it means: specific to a single (one) architecture. > > Sticking all MD stuff under a ${MACHINE_ARCH}_* namespace might be an > interesting project in the future, but it wouldn't be a small undertaking. Gotcha. Well anyway we could make a small start with these two functions :-) -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 19:11:34 2001 Delivered-To: freebsd-arch@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id A977137B71B for ; Fri, 23 Mar 2001 19:11:29 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 6655 invoked by uid 666); 24 Mar 2001 03:13:05 -0000 Received: from i003-226.nv.iinet.net.au (HELO elischer.org) (203.59.3.226) by mail.m.iinet.net.au with SMTP; 24 Mar 2001 03:13:05 -0000 Message-ID: <3ABC105D.E01C0842@elischer.org> Date: Fri, 23 Mar 2001 19:11:25 -0800 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: John Baldwin Cc: Archie Cobbs , arch@FreeBSD.org Subject: Re: Critical Regions Round II References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > Archie said: > > Shouldn't these be, e.g., > > > > i386_disable_intr(), i386_enable_intr() > > > > and > > > > ia64_enable_intr(), ia64_disable_intr() > > > > That is, it seems like "machine dependent" has a strict meaning, > > it means: specific to a single (one) architecture. > > Sticking all MD stuff under a ${MACHINE_ARCH}_* namespace might be an > interesting project in the future, but it wouldn't be a small undertaking. > > > Or are we expecting to have code that looks like this: > > > > #if defined(__i386__) || defined(__ia64__) > > disable_intr() > > #endif > > > > ?? > > No, this code should not be used outside of sys/${MACHINE_ARCH}, which is > mostly how things were (aside from broken things like the joy driver) before > SMPng. I think the names should include either md_ or I386_ as a leadin so that people who are 'copying' to make their own drivers a made fully aware of what is going on. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Mar 23 21:17: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 4BF9F37B719; Fri, 23 Mar 2001 21:17:05 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f2O5GQG36272; Fri, 23 Mar 2001 21:16:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: Fri, 23 Mar 2001 21:16:37 -0800 (PST) From: John Baldwin To: John Baldwin Subject: Re: Critical Regions Round II Cc: arch@FreeBSD.org, Bruce Evans Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24-Mar-01 John Baldwin wrote: >> This was really a renaming of the x86-specific interfaces read_eflags() >> and write_eflags(). I object to the x86 code being changed to use the >> new names. The x86 code that disables interrupts mostly wants precisely >> the MD interfaces, not the MI abstraction of them. It just happens that >> the MI versions are binary-identical with the MD versions. > > Ok, I could go with that. (/me deletes half of his patch.) Actually, I thought about this some more. Most of the places that do this (for example, before setting cr0 or something else critical) don't really care about any of the flags values, they are just keeping from being preempted, so I think that using critical_* in those places is more appropriate. If something needs to read eflags and act on it, then one would use read_eflags(). MD code still calls MI functions in other places. -- 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 Sat Mar 24 0:24:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 3873837B718; Sat, 24 Mar 2001 00:24:08 -0800 (PST) (envelope-from mark@grondar.za) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f2O8O2f62111; Sat, 24 Mar 2001 10:24:04 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200103240824.f2O8O2f62111@gratis.grondar.za> To: Hajimu UMEMOTO Cc: arch@FreeBSD.ORG From: markm@FreeBSD.ORG Subject: Re: KAME, IPSec, OpenBSD and FreeBSD References: <20010324.002308.36954645.ume@FreeBSD.org> In-Reply-To: <20010324.002308.36954645.ume@FreeBSD.org> ; from Hajimu UMEMOTO "Sat, 24 Mar 2001 00:23:08 +0900." Date: Sat, 24 Mar 2001 10:25:12 +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I just sent to you directry, then the mail was rejected. I dunno why. > So, I reply to this mail. Many apologies - I'm tuning spam filters. > mark> I am very interested in improving FreeBSD's in-kernel crypto, and > mark> I'd like to use the OpenBSD code. Amongs other things, this will > mark> give us access to excellent hardware encryption. > > Since, KAME is ported to all BSDs which includes OpenBSD, I think it > should be once merged to KAME, then porting to FreeBSD is better. That makes sense to me. > Since IPsec part of FreeBSD came from KAME and IPsec is still working > progress in KAME, I suggest that you should ask KAME guys (especially > itojun) about the possibility of merging. I'll do that. > BTW, I'll start merging recent KAME into 5-CURRENT after 4.3-RELEASE > is out. Great! :-) :-) I'm going ahead with the sys/crypto in the meanwhile (unless this is a bad idea - please let me know) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 0:39:52 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 018DD37B71B; Sat, 24 Mar 2001 00:39:39 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA24659; Sat, 24 Mar 2001 19:39:32 +1100 Date: Sat, 24 Mar 2001 19:38:57 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Julian Elischer Cc: John Baldwin , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Critical Regions Round II In-Reply-To: <3ABC105D.E01C0842@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Mar 2001, Julian Elischer wrote: > John Baldwin wrote: > > Archie said: > > > Shouldn't these be, e.g., > > > > > > i386_disable_intr(), i386_enable_intr() > > > > > > and > > > > > > ia64_enable_intr(), ia64_disable_intr() > > No, this code should not be used outside of sys/${MACHINE_ARCH}, which is > > mostly how things were (aside from broken things like the joy driver) before > > SMPng. > > I think the names should include either md_ or I386_ as a leadin so that people > who are 'copying' to make their own drivers a made fully aware > of what is going on. The MD names should simply be accessible in MI code. There are currently too many of them in . A few broken drivers access MD interfaces directly: grepping for 'include.*i386/' gives: dev/aha/aha_mca.c:#include dev/ar/if_ar_isa.c:#include dev/ar/if_ar_isa.c:#include dev/ar/if_ar_isa.c:#include dev/asr/asr.c:#include dev/asr/i2oadptr.h:# include "i386/pci/i2omsg.h" dev/asr/i2obscsi.h:# include "i386/pci/i2omsg.h" /* Include the Base Message file */ dev/asr/i2oexec.h:# include "i386/pci/i2omsg.h" /* Include the Base Message file */ dev/asr/i2oexec.h:# include "i386/pci/i2outil.h" dev/asr/i2omsg.h:# include "i386/pci/i2otypes.h" dev/asr/i2otypes.h:# include "i386/pci/i2odep.h" dev/asr/i2outil.h:# include "i386/pci/i2omsg.h" /* Include the Base Message file */ dev/asr/osd_util.h:# include "i386/isa/dpt_osd_defs.h" dev/asr/osd_util.h:# include "i386/isa/dpt_osd_defs.h" dev/asr/sys_info.h:# include "i386/isa/dpt_osd_util.h" dev/asr/sys_info.h:# include "i386/isa/dpt_osd_util.h" dev/buslogic/bt_mca.c:#include dev/ct/bshw_machdep.c:#include dev/ct/bshw_machdep.c:#include dev/ct/bshw_machdep.c:#include dev/ct/bshw_machdep.c:#include dev/ct/ct.c:#include dev/ct/ct.c:#include dev/ct/ct.c:#include dev/ct/ct_isa.c:#include dev/ct/ct_isa.c:#include dev/ct/ct_isa.c:#include dev/ct/ct_isa.c:#include dev/ct/ctvar.h:#include dev/dgb/dgb.c:#include dev/dgb/dgm.c:#include dev/dpt/dpt_control.c:#include dev/ep/if_ep_isa.c:#include dev/fe/if_fe.c:#include dev/fe/if_fe_cbus.c:#include dev/fe/if_fe_isa.c:#include dev/fe/if_fe_pccard.c:#include dev/ie/if_ie.c:#include dev/ie/if_ie.c:#include dev/ie/if_ie.c:#include dev/ie/if_ie.c:#include dev/lnc/if_lnc_pc98.c:#include dev/ncv/ncr53c500.c:#include dev/ncv/ncr53c500.c:#include dev/ncv/ncr53c500.c:#include dev/ncv/ncr53c500.c:#include dev/ncv/ncr53c500.c:#include dev/ncv/ncr53c500_pccard.c:#include dev/nsp/nsp.c:#include dev/nsp/nsp.c:#include dev/nsp/nsp.c:#include dev/nsp/nsp_pccard.c:#include dev/pdq/pdq_ifsubr.c:#include dev/stg/tmc18c30.c:#include dev/stg/tmc18c30.c:#include dev/stg/tmc18c30.c:#include dev/stg/tmc18c30_pccard.c:#include Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 1:27: 7 2001 Delivered-To: freebsd-arch@freebsd.org Received: from filk.iinet.net.au (syncopation-dns.iinet.net.au [203.59.24.29]) by hub.freebsd.org (Postfix) with SMTP id E33D737B71B for ; Sat, 24 Mar 2001 01:27:00 -0800 (PST) (envelope-from julian@elischer.org) Received: (qmail 19783 invoked by uid 666); 24 Mar 2001 09:28:36 -0000 Received: from i076-179.nv.iinet.net.au (HELO elischer.org) (203.59.76.179) by mail.m.iinet.net.au with SMTP; 24 Mar 2001 09:28:36 -0000 Message-ID: <3ABC685F.93B11487@elischer.org> Date: Sat, 24 Mar 2001 01:26:55 -0800 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: Bruce Evans Cc: John Baldwin , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Critical Regions Round II References: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Fri, 23 Mar 2001, Julian Elischer wrote: > > > John Baldwin wrote: > > > Archie said: > > > > Shouldn't these be, e.g., > > > > > > > > i386_disable_intr(), i386_enable_intr() > > > > > > > > and > > > > > > > > ia64_enable_intr(), ia64_disable_intr() > > > No, this code should not be used outside of sys/${MACHINE_ARCH}, which is > > > mostly how things were (aside from broken things like the joy driver) before > > > SMPng. > > > > I think the names should include either md_ or I386_ as a leadin so that people > > who are 'copying' to make their own drivers a made fully aware > > of what is going on. > > The MD names should simply be accessible in MI code. There are ^in > currently too many of them in . A few broken drivers > access MD interfaces directly: grepping for 'include.*i386/' gives: > > dev/ar/if_ar_isa.c:#include chip definitions should become machine independent. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 1:38:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A901437B718; Sat, 24 Mar 2001 01:38:13 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA27046; Sat, 24 Mar 2001 20:38:11 +1100 Date: Sat, 24 Mar 2001 20:37:35 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: Critical Regions Round II In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Mar 2001, John Baldwin wrote: > On 24-Mar-01 John Baldwin wrote: > >> This was really a renaming of the x86-specific interfaces read_eflags() > >> and write_eflags(). I object to the x86 code being changed to use the > >> new names. The x86 code that disables interrupts mostly wants precisely > >> the MD interfaces, not the MI abstraction of them. It just happens that > >> the MI versions are binary-identical with the MD versions. > > > > Ok, I could go with that. (/me deletes half of his patch.) > > Actually, I thought about this some more. Most of the places that do this (for > example, before setting cr0 or something else critical) don't really care about > any of the flags values, they are just keeping from being preempted, so I think > that using critical_* in those places is more appropriate. If something needs > to read eflags and act on it, then one would use read_eflags(). MD code still > calls MI functions in other places. But these places mostly need to know precisely what critical_* prevents. I'm not sure that the semantics of critical_* can or should be defined precisely enough for MD code to rely on. Here is one way that critical_enter() might be different from `read_eflags(); disable_intr()' on i386's: that latter certainly disables interrupts, but the former might only disable them virtually (let them occur, but don't let them proceed far, except possibly if they are fastintrs). Only very critical, very MD code should care about the difference between interrupts being disabled and interrupts apparently being disabled. The cr0-setting code is barely critical enough to care (but disabling interrupts early in the boot should be moot; it's simplest to disable interrupts globally and depend on this). BTW, the cr0-setting code seems to be entirely SMP-unaware; it seems to be only called for 1 CPUs (but this is OK since it is only used for old CPUs that don't support SMP). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 3:23:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 33F4837B718; Sat, 24 Mar 2001 03:23:28 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA31347; Sat, 24 Mar 2001 22:23:23 +1100 Date: Sat, 24 Mar 2001 22:22:47 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Julian Elischer Cc: John Baldwin , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Critical Regions Round II In-Reply-To: <3ABC685F.93B11487@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 24 Mar 2001, Julian Elischer wrote: > Bruce Evans wrote: > > currently too many of them in . A few broken drivers > > access MD interfaces directly: grepping for 'include.*i386/' gives: > > > > > dev/ar/if_ar_isa.c:#include > > chip definitions should become machine independent. Especially when they already have. was moved to (which is currently the sole inhabitant of Message-Id: <200103241339.f2ODdnG71383@zibbi.icomtek.csir.co.za> Subject: Re: Critical Regions Round II In-Reply-To: from Bruce Evans at "Mar 24, 2001 10:22:47 pm" To: bde@zeta.org.au (Bruce Evans) Date: Sat, 24 Mar 2001 15:39:49 +0200 (SAT) Cc: julian@elischer.org (Julian Elischer), jhb@FreeBSD.ORG (John Baldwin), archie@dellroad.org (Archie Cobbs), arch@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > currently too many of them in . A few broken drivers > > > access MD interfaces directly: grepping for 'include.*i386/' gives: > > > > > > > > dev/ar/if_ar_isa.c:#include > > > > chip definitions should become machine independent. > > Especially when they already have. was moved to > (which is currently the sole inhabitant of but is still referenced in one file in the ar driver. This file seems > to be garbage (repo-copying gave 1 old copy and 2 new copies of if_ar.c). It was repocopy-ed so that I can break out the isa bits. I have done the sr driver already, just not the ar yet. So don't worry about that file, I'll get to it and then the #includes will change. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 11:12:47 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 6D75137B71B for ; Sat, 24 Mar 2001 11:12:38 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 34540 invoked by uid 1000); 24 Mar 2001 19:11:40 -0000 Date: Sat, 24 Mar 2001 21:11:40 +0200 From: Peter Pentchev To: arch@FreeBSD.org Subject: Building only a specified list of kernel modules Message-ID: <20010324211140.C4304@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Any severe objections to the attached patch? (and no, I still have not taken the time to put my ICBM address into freebsd.committers.markers, so any objections will have to be in the form of e-mail ;) Something similar could be added for the sound/, netgraph/, et al multi-tiered subdirs. Could try this in a followup patch tomorrow, need sleep right now :( G'luck, Peter -- I am jealous of the first word in this sentence. Index: src/etc/defaults/make.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/make.conf,v retrieving revision 1.153 diff -u -r1.153 make.conf --- src/etc/defaults/make.conf 2001/03/14 11:30:57 1.153 +++ src/etc/defaults/make.conf 2001/03/24 19:07:06 @@ -116,6 +116,31 @@ # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD=true # do not build modules when building kernel # +# To only build specific kernel modules +# +#MODULES_LIST= 3dfx accf_data accf_http agp aha amr an aue \ +# cam ccd cd9660 coda cue dc de ed fdesc fxp if_disc if_ef \ +# if_ppp if_sl if_tap if_tun ip6fw ipfilter ipfw ispfw joy kue \ +# libmchain linux lnc md mfs mii mlx msdos ncp netgraph nfs ntfs nullfs \ +# nwfs pcn portal procfs random \ +# rl rp sf sis sk sn sound sppp ste sym syscons sysvipc ti tl twe tx \ +# udbp ugen uhid ukbd ulpt umapfs umass umodem ums union urio usb \ +# uscanner \ +# vinum vpo vr vx wb wx xl +# +# Additional kernel modules to build on i386 +# +#MODULES_LIST_I386= aac aic ar asr atspeaker bktr coff el fpu gnufpu \ +# ibcs2 linprocfs mly pecoff ray s3 splash sr streams vesa wi +# +# Additional kernel modules to build on PC98 +# +#MODULES_LIST_PC98= snc +# +# Additional kernel modules to build on Alpha +# +#MODULES_LIST_ALPHA= osf1 +# # # The following controls building optional IDEA code in libcrypto and # certain ports. Patents are involved - you must not use this unless Index: src/sys/modules/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/Makefile,v retrieving revision 1.171 diff -u -r1.171 Makefile --- src/sys/modules/Makefile 2001/03/09 20:10:30 1.171 +++ src/sys/modules/Makefile 2001/03/24 19:07:06 @@ -2,10 +2,17 @@ # XXX present but broken: ip_mroute_mod +# When modules are added/removed from the following SUBDIR lists, +# please make sure the corresponding MODULES_LIST defines +# in /etc/defaults/make.conf are updated as well. + .if exists(${.CURDIR}/../crypto) && !defined(NOCRYPT) _random= random .endif +.if defined(MODULES_LIST) +SUBDIR= ${MODULES_LIST} +.else SUBDIR= 3dfx accf_data accf_http agp aha amr an aue \ cam ccd cd9660 coda cue dc de ed fdesc fxp if_disc if_ef \ if_ppp if_sl if_tap if_tun ip6fw ipfilter ipfw ispfw joy kue \ @@ -15,19 +22,32 @@ udbp ugen uhid ukbd ulpt umapfs umass umodem ums union urio usb \ uscanner \ vinum vpo vr vx wb wx xl +.endif # XXX some of these can move to the general case when de-i386'ed .if ${MACHINE_ARCH} == "i386" +.if defined(MODULES_LIST_I386) +SUBDIR+=${MODULES_LIST_I386} +.else SUBDIR+=aac aic ar asr atspeaker bktr coff el fpu gnufpu ibcs2 linprocfs mly \ pecoff ray s3 splash sr streams vesa wi .endif +.endif .if ${MACHINE} == "pc98" +.if defined(MODULES_LIST_PC98) +SUBDIR+=${MODULES_LIST_PC98} +.else SUBDIR+=snc .endif +.endif .if ${MACHINE_ARCH} == "alpha" +.if defined(MODULES_LIST_ALPHA) +SUBDIR+=${MODULES_LIST_ALPHA} +.else SUBDIR+=osf1 +.endif .endif .include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 11:50:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from nebula.cybercable.fr (d217.dhcp212-126.cybercable.fr [212.198.126.217]) by hub.freebsd.org (Postfix) with ESMTP id 1D88137B718 for ; Sat, 24 Mar 2001 11:50:39 -0800 (PST) (envelope-from mux@qualys.com) Received: (from mux@localhost) by nebula.cybercable.fr (8.11.3/8.11.3) id f2OJo5m10859 for arch@FreeBSD.org; Sat, 24 Mar 2001 20:50:05 +0100 (CET) (envelope-from mux) Date: Sat, 24 Mar 2001 20:50:05 +0100 From: Maxime Henrion To: arch@FreeBSD.org Subject: Re: Building only a specified list of kernel modules Message-ID: <20010324205005.D777@nebula.cybercable.fr> References: <20010324211140.C4304@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010324211140.C4304@ringworld.oblivion.bg>; from roam@orbitel.bg on Sat, Mar 24, 2001 at 09:11:40PM +0200 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Pentchev wrote: > Hi, > > Any severe objections to the attached patch? (and no, I still have not > taken the time to put my ICBM address into freebsd.committers.markers, > so any objections will have to be in the form of e-mail ;) > > Something similar could be added for the sound/, netgraph/, et al > multi-tiered subdirs. Could try this in a followup patch tomorrow, > need sleep right now :( > > G'luck, > Peter [patch skipped] Sorry, I just posted a similar patch to -hackers and have seen Peter's one just after having sent mine. I think we had the same idea because we were both on IRC today where it came into the discussion. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code Key fingerprint = F9B6 1D5A 4963 331C 88FC CA6A AB50 1EF2 8CBE 99D6 Public Key : http://www.epita.fr/~henrio_m/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 13:52:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 4C60637B71E for ; Sat, 24 Mar 2001 13:52:26 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@dhcp152.geekhouse.net [192.168.1.152]) by moby.geekhouse.net (8.11.3/8.11.3) with ESMTP id f2OLqcj18825; Sat, 24 Mar 2001 13:52:40 -0800 (PST) (envelope-from jhb@FreeBSD.org) 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: <20010324211140.C4304@ringworld.oblivion.bg> Date: Sat, 24 Mar 2001 13:51:54 -0800 (PST) From: John Baldwin To: Peter Pentchev Subject: RE: Building only a specified list of kernel modules Cc: arch@FreeBSD.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24-Mar-01 Peter Pentchev wrote: > Hi, > > Any severe objections to the attached patch? (and no, I still have not > taken the time to put my ICBM address into freebsd.committers.markers, > so any objections will have to be in the form of e-mail ;) > > Something similar could be added for the sound/, netgraph/, et al > multi-tiered subdirs. Could try this in a followup patch tomorrow, > need sleep right now :( > > G'luck, > Peter Peter Wemm has a much more flexible plan involving config(8) to solve this. Instead of specifying the modules in a global sense, you would list the modules you want to build in your kernel config file. Then they would be built in the same environment (same options, etc.) as the kernel. This allows you to build modules with INVARIANTS, etc. or MD optimizations more easily. It will also cut down on compile time as the modules will be built in sys/compile/FOO using the same .o files as the kernel if ones are shared. This will also probably obsolete all of the src/sys/modules hierarchy, but I'm sure Peter can provide more details if you want them. :) -- 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 Sat Mar 24 15: 6:11 2001 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id 5441137B71A for ; Sat, 24 Mar 2001 15:06:08 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f2ON64005540; Sat, 24 Mar 2001 15:06:04 -0800 (PST) (envelope-from obrien) Date: Sat, 24 Mar 2001 15:06:04 -0800 From: "David O'Brien" To: Peter Pentchev Cc: arch@FreeBSD.org Subject: Re: Building only a specified list of kernel modules Message-ID: <20010324150603.A5365@dragon.nuxi.com> Reply-To: obrien@FreeBSD.org References: <20010324211140.C4304@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010324211140.C4304@ringworld.oblivion.bg>; from roam@orbitel.bg on Sat, Mar 24, 2001 at 09:11:40PM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 24, 2001 at 09:11:40PM +0200, Peter Pentchev wrote: > Any severe objections to the attached patch? (and no, I still have not > taken the time to put my ICBM address into freebsd.committers.markers, > so any objections will have to be in the form of e-mail ;) I like this patch for RELENG_4 which will not get any of Peter's new and improved config(8) work. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 23:18: 1 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 4689C37B71A for ; Sat, 24 Mar 2001 23:17:55 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 36445 invoked by uid 1000); 25 Mar 2001 07:16:57 -0000 Date: Sun, 25 Mar 2001 10:16:57 +0300 From: Peter Pentchev To: Maxime Henrion Cc: arch@FreeBSD.org Subject: Re: Building only a specified list of kernel modules Message-ID: <20010325101657.A36335@ringworld.oblivion.bg> Mail-Followup-To: Maxime Henrion , arch@FreeBSD.org References: <20010324211140.C4304@ringworld.oblivion.bg> <20010324205005.D777@nebula.cybercable.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010324205005.D777@nebula.cybercable.fr>; from mux@qualys.com on Sat, Mar 24, 2001 at 08:50:05PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 24, 2001 at 08:50:05PM +0100, Maxime Henrion wrote: > Peter Pentchev wrote: > > Hi, > > > > Any severe objections to the attached patch? (and no, I still have not > > taken the time to put my ICBM address into freebsd.committers.markers, > > so any objections will have to be in the form of e-mail ;) > > > > Something similar could be added for the sound/, netgraph/, et al > > multi-tiered subdirs. Could try this in a followup patch tomorrow, > > need sleep right now :( > > > > G'luck, > > Peter > [patch skipped] > > Sorry, I just posted a similar patch to -hackers and have seen Peter's > one just after having sent mine. I think we had the same idea because > we were both on IRC today where it came into the discussion. Yeah, blame it all on newfangled means of communication :P With all due respect, I think my patch would work better in the case when one wants to disable all modules except for a select few; yours would include a whole lot of NO_KMOD_*, which, given the sheer number of buildable modules (which is a good thing), would sum up to more than half of /etc/make.conf ;) G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 23:21:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 74DE937B74F for ; Sat, 24 Mar 2001 23:21:10 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 36534 invoked by uid 1000); 25 Mar 2001 07:20:13 -0000 Date: Sun, 25 Mar 2001 10:20:13 +0300 From: Peter Pentchev To: David O'Brien Cc: arch@FreeBSD.org Subject: Re: Building only a specified list of kernel modules Message-ID: <20010325102013.B36335@ringworld.oblivion.bg> Mail-Followup-To: David O'Brien , arch@FreeBSD.org References: <20010324211140.C4304@ringworld.oblivion.bg> <20010324150603.A5365@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010324150603.A5365@dragon.nuxi.com>; from obrien@FreeBSD.org on Sat, Mar 24, 2001 at 03:06:04PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 24, 2001 at 03:06:04PM -0800, David O'Brien wrote: > On Sat, Mar 24, 2001 at 09:11:40PM +0200, Peter Pentchev wrote: > > Any severe objections to the attached patch? (and no, I still have not > > taken the time to put my ICBM address into freebsd.committers.markers, > > so any objections will have to be in the form of e-mail ;) > > I like this patch for RELENG_4 which will not get any of Peter's new and > improved config(8) work. Yes, IMHO RELENG_4 systems could benefit from this, especially those for which root fs space is at a premium. G'luck, Peter -- This sentence no verb. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Mar 24 23:57:37 2001 Delivered-To: freebsd-arch@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id D420F37B71E for ; Sat, 24 Mar 2001 23:57:29 -0800 (PST) (envelope-from roam@orbitel.bg) Received: (qmail 38630 invoked by uid 1000); 25 Mar 2001 07:56:32 -0000 Date: Sun, 25 Mar 2001 10:56:32 +0300 From: Peter Pentchev To: arch@FreeBSD.org Subject: Re: Building only a specified list of kernel modules Message-ID: <20010325105631.C36335@ringworld.oblivion.bg> Mail-Followup-To: arch@FreeBSD.org References: <20010324211140.C4304@ringworld.oblivion.bg> <20010324150603.A5365@dragon.nuxi.com> <20010325102013.B36335@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010325102013.B36335@ringworld.oblivion.bg>; from roam@orbitel.bg on Sun, Mar 25, 2001 at 10:20:13AM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Mar 25, 2001 at 10:20:13AM +0300, Peter Pentchev wrote: > On Sat, Mar 24, 2001 at 03:06:04PM -0800, David O'Brien wrote: > > On Sat, Mar 24, 2001 at 09:11:40PM +0200, Peter Pentchev wrote: > > > Any severe objections to the attached patch? (and no, I still have not > > > taken the time to put my ICBM address into freebsd.committers.markers, > > > so any objections will have to be in the form of e-mail ;) > > > > I like this patch for RELENG_4 which will not get any of Peter's new and > > improved config(8) work. > > Yes, IMHO RELENG_4 systems could benefit from this, especially those > for which root fs space is at a premium. OK, here's a RELENG_4 patch, which also controls building the various netgraph, syscons and sound modules (since I'm using the audio/aureal-kmod port, not an in-tree driver, the ability to have just snd.ko and snd_pcm.ko in there is, well, cool ;) G'luck, Peter -- This sentence contains exactly threee erors. Index: src/etc/defaults/make.conf =================================================================== RCS file: /home/ncvs/src/etc/defaults/make.conf,v retrieving revision 1.97.2.45 diff -u -r1.97.2.45 make.conf --- src/etc/defaults/make.conf 2001/03/22 01:43:39 1.97.2.45 +++ src/etc/defaults/make.conf 2001/03/25 07:46:03 @@ -119,6 +119,48 @@ # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD=true # do not build modules when building kernel # +# To only build specific kernel modules +# +#MODULES_LIST= accf_data accf_http agp aha amr an aue \ +# ccd cd9660 coda cue dc fdesc fxp if_disc if_ef if_ppp \ +# if_sl if_tap if_tun ip6fw ipfilter ipfw ispfw joy kernfs kue \ +# linux md mfs mii mlx msdos ncp pcn netgraph nfs ntfs nullfs \ +# nwfs portal procfs rl sf sis sk sound ste syscons ti tl twe \ +# ugen uhid ukbd ulpt umapfs umass umodem ums union usb uscanner \ +# vinum vn vpo vr wb wx xl +# +# Additional kernel modules to build on i386 +# +#MODULES_LIST_I386= aac asr bktr coff fpu gnufpu ibcs2 linprocfs mly ray \ +# splash streams svr4 vesa wi +# +# Additional kernel modules to build on PC98 +# +#MODULES_LIST_PC98= snc +# +# Additional kernel modules to build on Alpha +# +#MODULES_LIST_ALPHA= osf1 +# +# Netgraph modules to build +# +#MODULES_LIST_NETGRAPH= async bpf bridge cisco echo ether frame_relay hole \ +# iface ksocket lmi mppc netgraph one2many ppp pppoe pptpgre rfc1490 \ +# socket tee tty UI vjc +# +# Sound modules to build +# +#MODULES_LIST_SOUND= ad1816 cmi cs4281 csa ds1 emu10k1 es137x ess fm801 \ +# maestro maestro3 mss neomagic sb16 sb8 sbc solo t4dwave via82c686 +# +# Syscons modules to build (mainly screensavers) +# +#MODULES_LIST_SYSCONS= blank daemon fade fire green logo rain snake star warp +# +# Additional syscons modules to build on i386 +# +#MODULES_LIST_SYSCONS_I386= apm +# # # The following controls building optional IDEA code in libcrypto and # certain ports. Patents are involved - you must not use this unless Index: src/sys/modules/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/Makefile,v retrieving revision 1.110.2.23 diff -u -r1.110.2.23 Makefile --- src/sys/modules/Makefile 2001/03/13 01:26:22 1.110.2.23 +++ src/sys/modules/Makefile 2001/03/25 07:46:03 @@ -2,6 +2,9 @@ # XXX present but broken: ip_mroute_mod pcic +.if defined(MODULES_LIST) +SUBDIR= ${MODULES_LIST} +.else SUBDIR= accf_data accf_http agp aha amr an aue \ ccd cd9660 coda cue dc fdesc fxp if_disc if_ef if_ppp \ if_sl if_tap if_tun ip6fw ipfilter ipfw ispfw joy kernfs kue \ @@ -9,19 +12,32 @@ nwfs portal procfs rl sf sis sk sound ste syscons ti tl twe \ ugen uhid ukbd ulpt umapfs umass umodem ums union usb uscanner \ vinum vn vpo vr wb wx xl +.endif # XXX some of these can move to the general case when de-i386'ed .if ${MACHINE_ARCH} == "i386" +.if defined(MODULES_LIST_I386) +SUBDIR+=${MODULES_LIST_I386} +.else SUBDIR+=aac asr bktr coff fpu gnufpu ibcs2 linprocfs mly ray splash streams \ svr4 vesa wi .endif +.endif .if ${MACHINE} == "pc98" +.if defined(MODULES_LIST_PC98) +SUBDIR+=${MODULES_LIST_PC98} +.else SUBDIR+=snc .endif +.endif .if ${MACHINE_ARCH} == "alpha" +.if defined(MODULES_LIST_ALPHA) +SUBDIR+=${MODULES_LIST_ALPHA} +.else SUBDIR+=osf1 +.endif .endif .include Index: src/sys/modules/netgraph/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/netgraph/Makefile,v retrieving revision 1.8.2.4 diff -u -r1.8.2.4 Makefile --- src/sys/modules/netgraph/Makefile 2000/11/22 19:06:12 1.8.2.4 +++ src/sys/modules/netgraph/Makefile 2001/03/25 07:46:03 @@ -1,11 +1,15 @@ # $Whistle: Makefile,v 1.5 1999/01/24 06:48:37 archie Exp $ # $FreeBSD: src/sys/modules/netgraph/Makefile,v 1.8.2.4 2000/11/22 19:06:12 archie Exp $ +.if defined(MODULES_LIST_NETGRAPH) +SUBDIR= ${MODULES_LIST_NETGRAPH} +.else SUBDIR= async bpf bridge cisco echo ether frame_relay hole iface ksocket lmi \ netgraph one2many ppp pppoe pptpgre rfc1490 socket tee tty UI vjc .if !defined(NOCRYPT) && exists(${.CURDIR}/../../crypto/rc4/rc4.c) SUBDIR+= mppc +.endif .endif .include Index: src/sys/modules/sound/driver/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/sound/driver/Makefile,v retrieving revision 1.5.2.6 diff -u -r1.5.2.6 Makefile --- src/sys/modules/sound/driver/Makefile 2001/03/04 08:15:29 1.5.2.6 +++ src/sys/modules/sound/driver/Makefile 2001/03/25 07:46:03 @@ -1,6 +1,10 @@ # $FreeBSD: src/sys/modules/sound/driver/Makefile,v 1.5.2.6 2001/03/04 08:15:29 scottl Exp $ -SUBDIR = ad1816 cmi cs4281 csa ds1 emu10k1 es137x ess fm801 maestro -SUBDIR += maestro3 mss neomagic sb16 sb8 sbc solo t4dwave via82c686 +.if defined(MODULES_LIST_SOUND) +SUBDIR= ${MODULES_LIST_SOUND} +.else +SUBDIR= ad1816 cmi cs4281 csa ds1 emu10k1 es137x ess fm801 maestro +SUBDIR+=maestro3 mss neomagic sb16 sb8 sbc solo t4dwave via82c686 +.endif .include Index: src/sys/modules/syscons/Makefile =================================================================== RCS file: /home/ncvs/src/sys/modules/syscons/Makefile,v retrieving revision 1.11.2.1 diff -u -r1.11.2.1 Makefile --- src/sys/modules/syscons/Makefile 2000/05/06 02:09:48 1.11.2.1 +++ src/sys/modules/syscons/Makefile 2001/03/25 07:46:03 @@ -1,5 +1,8 @@ # $FreeBSD: src/sys/modules/syscons/Makefile,v 1.11.2.1 2000/05/06 02:09:48 obrien Exp $ +.if defined(MODULES_LIST_SYSCONS) +SUBDIR= ${MODULES_LIST_SYSCONS} +.else SUBDIR = SUBDIR += blank SUBDIR += daemon @@ -11,9 +14,14 @@ SUBDIR += snake SUBDIR += star SUBDIR += warp +.endif .if ${MACHINE_ARCH} == "i386" +.if defined(MODULES_LIST_SYSCONS_I386) +SUBDIR+=${MODULES_LIST_SYSCONS_I386} +.else SUBDIR += apm +.endif .endif .include To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message