From owner-freebsd-arch Sun Nov 14 4:50:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C580C14DB2 for ; Sun, 14 Nov 1999 04:50:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA17163 for ; Sun, 14 Nov 1999 13:50:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA39497 for freebsd-arch@freebsd.org; Sun, 14 Nov 1999 13:50:16 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id BE39C14DB2 for ; Sun, 14 Nov 1999 04:50:08 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt38.pcnet.net [206.105.29.112]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id HAA22473; Sun, 14 Nov 1999 07:48:48 -0500 (EST) Message-ID: <382EAFF8.7E144B94@vigrid.com> Date: Sun, 14 Nov 1999 07:50:00 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Michael Schuster - TSC SunOS Germany , "freebsd-arch@FreeBSD.ORG" Subject: Re: Threads goals and implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sat, 13 Nov 1999, Daniel M. Eischen wrote: > > > It is probable that we will need a different syscall calling convension > > > to handle teh async nature of the world. If we use a second syscall gate, > > > we can intermix old and new system calls during development. > > > > OK, I can see how a different syscall gate might be useful during > > development. > > more than that.. Old binaries must continue to run, and thus programs > linked with libc might continue to use the old syscalls (probably less > overhead) while prrograms using libc_r will call the new call-gate > with a protocol mor esuited to the new ideas. I guess I don't see why we would _need_ new system calls. A process marks itself as wanting SAs and you put SA hooks in the sleep/wakeup functions. The SA hooks are conditional on the process being marked as wanting SAs. Old binaries using the old libc/libc_r wouldn't be marked as wanting SAs, so they'd continue to operate in the same way. I know I'm simplifying things a bit. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Nov 14 11:58:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7589414BC2 for ; Sun, 14 Nov 1999 11:58:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA20009 for ; Sun, 14 Nov 1999 20:58:49 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA40833 for freebsd-arch@freebsd.org; Sun, 14 Nov 1999 20:58:48 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id C124D14BC2; Sun, 14 Nov 1999 11:58:35 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40327>; Mon, 15 Nov 1999 06:52:14 +1100 Content-return: prohibited Date: Mon, 15 Nov 1999 06:58:26 +1100 From: Peter Jeremy Subject: Re: /usr/local In-reply-to: <19991112090136.A87828@dragon.nuxi.com> To: "David O'Brien" Cc: Dag-Erling Smorgrav , freebsd-arch@freebsd.org Reply-To: peter.jeremy@alcatel.com.au Message-Id: <99Nov15.065214est.40327@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0pre3i Content-type: text/plain; charset=us-ascii References: <19991112090136.A87828@dragon.nuxi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-Nov-13 04:01:36 +1100, David O'Brien wrote: >On Fri, Nov 12, 1999 at 10:46:23AM +0100, Dag-Erling Smorgrav wrote: >> How would people feel about adding /usr/local/include and >> /usr/local/lib to gcc's default header and library search paths, ... >Adding -IPREFIX/include to gcc burns this into the binary, and that is >not easy for a sysadmin to change. Note that gcc supports a `specs' file which can do this sort of thing (the non-existent /usr/libdata/gcc/specs). It should be fairly easy to change things to install this file. (Admittedly, it's not the easiest thing to hand-edit). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 15 2:56:38 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9367815028 for ; Mon, 15 Nov 1999 02:56:35 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA04177 for ; Mon, 15 Nov 1999 11:56:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA43941 for freebsd-arch@freebsd.org; Mon, 15 Nov 1999 11:56:34 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id C8B6F15028 for ; Mon, 15 Nov 1999 02:56:09 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id LAA27992; Mon, 15 Nov 1999 11:55:53 +0100 (CET) Date: Mon, 15 Nov 1999 11:55:52 +0100 From: Martin Cracauer To: Marcel Moolenaar Cc: Martin Cracauer , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991115115552.A27870@cons.org> References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <382FDBE2.D075594@scc.nl>; from Marcel Moolenaar on Mon, Nov 15, 1999 at 11:09:38AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Marcel, Bruce, I moved this to -arch, since we have to make some long-term decisions here: 1) Does FreeBSD prefer to pass information like this as unnamed array of bytes or as structs with proper fields? 2) How big may we make struct sigcontext? The 512 bytes that is named for now is quite a big step from the 100 bytes it had before FPU state savings). I have a strong preference to anser 1) with "yes". Be assurend that my comments aren't in a any way an attack on you, but since we both committed to the signal code lately and I did my work with 1 == YES and you with 1 == NO (partly removing type-save constructions of my former code), we should resolve this now. In <382FDBE2.D075594@scc.nl>, Marcel Moolenaar wrote: > Martin Cracauer wrote: > > > > Martin implemented saving it before you complicated things by changing > > > the signal handling :-). I didn't like it because it moved the definitions > > > of i386 FP structs to the wrong place (). It's not > > > clear that there is a right place. > > > > The reasoning is like this: > > > > 0) If the state of the FPU is passed to a signal handler, it is > > preferrable to do so in a struct with proper names, not just an > > array of bytes. > > I disagree. Signal handlers don't use context information for (wild > guess) 99.9% of the time. Bloating signalling definitions with details > of the many different hardware configurations (even within a single > architecture) is not the way to go. Maybe we have a different definition of "bloat", but since the size is the same, this doesn't count as "bloat for me. > For every FP emulator with it's own > state information, we are forced to have unions and the like. The non-GPL emulator can't support a production FreeBSD system anymore. The GPL emulator is reasonably compatible even when it comes to its stored state. > No, it's > better to be vague in struct sigcontext and let the program use a cast > when it wants to dig in the gory details of the machine state. As I said, I disagree. FreeBSD/alpha also exposes its FPU state in struct sigcontext (although the FPU is simpler). > > 1) Applications that use signal handlers with extended parameters > > (SA_SIGINFO or old BSD-style three arguments) are supposed to > > include , but nothing else. > > SUSv2 defines sa_sigaction as: > void (*) (int, siginfo_t*, void*) sa_sigaction; > > Notice the `void*' where the `ucontext_t*' is supposed to be. SUSv2 > simply says that the handler may cast the `void*' to get to the gory > details and ucontext_t itself contains an abstract type (mcontext_t) > that represents machine specific state. When I implemented SA_SIGINFO, you could get it in a type-save way as a member of the second argument. This capability has been removed by your newer signal changes. > Point: You don't want low-level details embedded in high-level > definitions. We pass the FPU state some way or another. If we pass it, we should do it as type-save as possible. A proper description of the i386 FPU is already present in the kernel sources and used at other places, I just want to reuse the same definition in a ny place where is FPU is represented in a stored state. > > struct save87 is now 176 bytes, Marcel currently reserves 180. struct > > sigcontext without FPU state is 100 bytes, so we are at 276 bytes at > > least. > > > > Would it be unreasonable to bump it to 512 bytes to be done with it > > once and for all? Might have positive effects on cache behaviour as > > well. > > In that case, make ucontext_t 512 bytes and scale struct sigcontext > accordingly. > > > We may also need an way to tell an application at runtime how far the > > struct is filled. > > You need exactly 1 bit to tell the application if the FPU state is valid > or not, right? I don't think that is sufficient in the general case. We don't want to know whether a kernel that is capable of storing the FPU state did so (it does so in any case). We want to know whether the kernel is new enough that is even knows that the FPU state might be stored here. If it doesn't it can't set this bit. Longer explanation: In a kernel version 1 'struct sigcontext' has a number of fields making 100 bytes and padding to 512 bytes. struct sigcontext { char bla[100]; char padding[412]; }; In version 2, the FPU state is added and padding adjusted: struct sigcontext { char bla[100]; char fpu[200] char padding[212]; }; In version 3, some other state is added: struct sigcontext { char bla[100]; char fpu[200] cht otherstate[12] char padding[200]; }; Now, how can an application tell what is filled and what is not? A #define in the header file isn't suitable, since a binary compiled on one version might be moved to a didfferent kernel. An application might assume that a given state is always at the same place, i.e. it might not happen that otherstate is stored where fpu was assumed. Newer kernels add fields, they never move or delete fields. I think it is best to add a field n_extensions: struct sigcontext { char bla[100]; int n_extensions; /* 3 in this case */ char fpu[200] chat otherstate[12] char padding[200]; }; If an application wants to access one of the extensions, it must know its number (via a #define) and then test for n_extensions >= N. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 15 3:47:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9F2A614F7C for ; Mon, 15 Nov 1999 03:47:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA06037 for ; Mon, 15 Nov 1999 12:47:37 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA44083 for freebsd-arch@freebsd.org; Mon, 15 Nov 1999 12:47:36 +0100 (MET) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 649021500E for ; Mon, 15 Nov 1999 03:47:25 -0800 (PST) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11nKbo-000P6n-00; Mon, 15 Nov 1999 11:47:45 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id MAA14981; Mon, 15 Nov 1999 12:46:55 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <382FF2AF.545C8C81@scc.nl> Date: Mon, 15 Nov 1999 12:46:55 +0100 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Martin Cracauer Cc: Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Cracauer wrote: > > Marcel, Bruce, > > I moved this to -arch, since we have to make some long-term decisions > here: > > 1) Does FreeBSD prefer to pass information like this as unnamed array > of bytes or as structs with proper fields? > > 2) How big may we make struct sigcontext? The 512 bytes that is named > for now is quite a big step from the 100 bytes it had before FPU > state savings). > > I have a strong preference to anser 1) with "yes". Do you want A or B? ... yes. Euh, what is it? :-) I'd say that we should find the balance. If more detail requires us to rearrange a lot of the headers in /sys//include and /sys/sys, then I'd say we should use arrays. > In <382FDBE2.D075594@scc.nl>, Marcel Moolenaar wrote: > > Martin Cracauer wrote: > > > > > > Martin implemented saving it before you complicated things by changing > > > > the signal handling :-). I didn't like it because it moved the definitions > > > > of i386 FP structs to the wrong place (). It's not > > > > clear that there is a right place. > > > > > > The reasoning is like this: > > > > > > 0) If the state of the FPU is passed to a signal handler, it is > > > preferrable to do so in a struct with proper names, not just an > > > array of bytes. > > > > I disagree. Signal handlers don't use context information for (wild > > guess) 99.9% of the time. Bloating signalling definitions with details > > of the many different hardware configurations (even within a single > > architecture) is not the way to go. > > Maybe we have a different definition of "bloat", but since the size is > the same, this doesn't count as "bloat for me. The bloat is in what you get when you include > > No, it's > > better to be vague in struct sigcontext and let the program use a cast > > when it wants to dig in the gory details of the machine state. > > As I said, I disagree. FreeBSD/alpha also exposes its FPU state in > struct sigcontext (although the FPU is simpler). Sort of: long sc_xxx2[3]; /* sc_fp_trap_pc, sc_fp_trigger_sum, sc_fp_trigger_inst */ > > > 1) Applications that use signal handlers with extended parameters > > > (SA_SIGINFO or old BSD-style three arguments) are supposed to > > > include , but nothing else. > > > > SUSv2 defines sa_sigaction as: > > void (*) (int, siginfo_t*, void*) sa_sigaction; > > > > Notice the `void*' where the `ucontext_t*' is supposed to be. SUSv2 > > simply says that the handler may cast the `void*' to get to the gory > > details and ucontext_t itself contains an abstract type (mcontext_t) > > that represents machine specific state. > > When I implemented SA_SIGINFO, you could get it in a type-save way as > a member of the second argument. This capability has been removed by > your newer signal changes. Yes, because ucontext_t is not part of siginfo_t and adding it there only creates unnecessary dependencies and pitfalls. Not to mention the size increase and the shear unportability of the approach. You don't want to implement RT signals with a bloated siginfo_t... > > Point: You don't want low-level details embedded in high-level > > definitions. > > We pass the FPU state some way or another. If we pass it, we should do > it as type-save as possible. As is *reasonably* possible. > A proper description of the i386 FPU is already present in the kernel > sources and used at other places, I just want to reuse the same > definition in a ny place where is FPU is represented in a stored > state. A change in how the state is saved would then automaticly result in an interface change while this should not be the case (I should know, I did exactly the same thing :-) > > > struct save87 is now 176 bytes, Marcel currently reserves 180. struct > > > sigcontext without FPU state is 100 bytes, so we are at 276 bytes at > > > least. > > > > > > Would it be unreasonable to bump it to 512 bytes to be done with it > > > once and for all? Might have positive effects on cache behaviour as > > > well. > > > > In that case, make ucontext_t 512 bytes and scale struct sigcontext > > accordingly. > > > > > We may also need an way to tell an application at runtime how far the > > > struct is filled. > > > > You need exactly 1 bit to tell the application if the FPU state is valid > > or not, right? > > I don't think that is sufficient in the general case. If you refer to the general case here, then also do it for the saved state. In the general case, that may be very incompatible for each different FPU and or emulator, which is not limited to what we have now. > We don't want to know whether a kernel that is capable of storing the > FPU state did so (it does so in any case). We want to know whether the > kernel is new enough that is even knows that the FPU state might be > stored here. If it doesn't it can't set this bit. Thus, a new kernel sets a bit where an old kernel does not set it... > Longer explanation: > > In a kernel version 1 'struct sigcontext' has a number of fields > making 100 bytes and padding to 512 bytes. > > struct sigcontext { > char bla[100]; > char padding[412]; > }; > > In version 2, the FPU state is added and padding adjusted: > struct sigcontext { > char bla[100]; > char fpu[200] > char padding[212]; > }; > > In version 3, some other state is added: > struct sigcontext { > char bla[100]; > char fpu[200] > cht otherstate[12] > char padding[200]; > }; > > Now, how can an application tell what is filled and what is not? A > #define in the header file isn't suitable, since a binary compiled on > one version might be moved to a didfferent kernel. If a new kernel breaks old binaries, then it's not backwards compatible :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 15 4:10:14 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 52DFA14C89 for ; Mon, 15 Nov 1999 04:10:05 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA06435 for ; Mon, 15 Nov 1999 13:10:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA44260 for freebsd-arch@freebsd.org; Mon, 15 Nov 1999 13:10:04 +0100 (MET) Received: from knight.cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 8564C14C89 for ; Mon, 15 Nov 1999 04:09:16 -0800 (PST) (envelope-from cracauer@knight.cons.org) Received: (from cracauer@localhost) by knight.cons.org (8.9.3/8.9.3) id NAA28470; Mon, 15 Nov 1999 13:08:55 +0100 (CET) Date: Mon, 15 Nov 1999 13:08:54 +0100 From: Martin Cracauer To: Marcel Moolenaar Cc: Martin Cracauer , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991115130854.A28445@cons.org> References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <382FF2AF.545C8C81@scc.nl>; from Marcel Moolenaar on Mon, Nov 15, 1999 at 12:46:55PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <382FF2AF.545C8C81@scc.nl>, Marcel Moolenaar wrote: > Martin Cracauer wrote: > > > > Marcel, Bruce, > > > > I moved this to -arch, since we have to make some long-term decisions > > here: > > > > 1) Does FreeBSD prefer to pass information like this as unnamed array > > of bytes or as structs with proper fields? > > > > 2) How big may we make struct sigcontext? The 512 bytes that is named > > for now is quite a big step from the 100 bytes it had before FPU > > state savings). > > > > I have a strong preference to anser 1) with "yes". > > Do you want A or B? ... yes. > Euh, what is it? :-) > I'd say that we should find the balance. If more detail requires us to > rearrange a lot of the headers in /sys//include and /sys/sys, then > I'd say we should use arrays. Rearrange is the wrong word. We move struct definitions that describe state that is passed to signal handlers to include files included from . The hole FPU include file structure cries for restructuring anyway, as bruce will probably point out :-) > > In <382FDBE2.D075594@scc.nl>, Marcel Moolenaar wrote: > > > Martin Cracauer wrote: > > > > > > > > Martin implemented saving it before you complicated things by changing > > > > > the signal handling :-). I didn't like it because it moved the definitions > > > > > of i386 FP structs to the wrong place (). It's not > > > > > clear that there is a right place. > > > > > > > > The reasoning is like this: > > > > > > > > 0) If the state of the FPU is passed to a signal handler, it is > > > > preferrable to do so in a struct with proper names, not just an > > > > array of bytes. > > > > > > I disagree. Signal handlers don't use context information for (wild > > > guess) 99.9% of the time. Bloating signalling definitions with details > > > of the many different hardware configurations (even within a single > > > architecture) is not the way to go. > > > > Maybe we have a different definition of "bloat", but since the size is > > the same, this doesn't count as "bloat for me. > > The bloat is in what you get when you include OK, you're speaking compile-time bloat here. What I'm trying to do is to access members of a data struct by reusing a struct definition that is already in our tree, and not requireing the user to access the members by couting bytes and then cast. That not bloat, that's moving struct definitions to where they are needed. > > > No, it's > > > better to be vague in struct sigcontext and let the program use a cast > > > when it wants to dig in the gory details of the machine state. > > > > As I said, I disagree. FreeBSD/alpha also exposes its FPU state in > > struct sigcontext (although the FPU is simpler). > > Sort of: > long sc_xxx2[3]; /* sc_fp_trap_pc, sc_fp_trigger_sum, > sc_fp_trigger_inst */ > > > > > 1) Applications that use signal handlers with extended parameters > > > > (SA_SIGINFO or old BSD-style three arguments) are supposed to > > > > include , but nothing else. > > > > > > SUSv2 defines sa_sigaction as: > > > void (*) (int, siginfo_t*, void*) sa_sigaction; > > > > > > Notice the `void*' where the `ucontext_t*' is supposed to be. SUSv2 > > > simply says that the handler may cast the `void*' to get to the gory > > > details and ucontext_t itself contains an abstract type (mcontext_t) > > > that represents machine specific state. > > > > When I implemented SA_SIGINFO, you could get it in a type-save way as > > a member of the second argument. This capability has been removed by > > your newer signal changes. > > Yes, because ucontext_t is not part of siginfo_t and adding it there > only creates unnecessary dependencies and pitfalls. Not to mention the > size increase and the shear unportability of the approach. Sorry, you are wrong here. It doesn't increase the amount of data that is stored or copies for signal handlers. Befor my changes, the struct sigcontext was pushed on the signal handler argument stack as if it was a fith (hidden) argument, then the (visible, documented) pointer passed as the thrird argument pointed to that location. After my changes, the struct was put into the struct sigcontext and the third argument points back there. That's just an rearrangement, not bloating anything. As for unportable, it is of course unportable to use struct sigcontext. That doesn't mean it isn't useful to let the user access it without a manual cast when he uses it. > You don't want to implement RT signals with a bloated siginfo_t... If the RT signals don't use a struct sigcontext at all (and I mean, the kernel implementation doesn't need one when sending the signal and returing from it, no matter whether the application's signal handler can access it), then you can omit it. > > > Point: You don't want low-level details embedded in high-level > > > definitions. > > > > We pass the FPU state some way or another. If we pass it, we should do > > it as type-save as possible. > > As is *reasonably* possible. > > > A proper description of the i386 FPU is already present in the kernel > > sources and used at other places, I just want to reuse the same > > definition in a ny place where is FPU is represented in a stored > > state. > > A change in how the state is saved would then automaticly result in an > interface change while this should not be the case (I should know, I did > exactly the same thing :-) I don't understand why the fact the the description might not useful in the emulator case prevents us from securing the case for the hardware FPU case. > > > > struct save87 is now 176 bytes, Marcel currently reserves 180. struct > > > > sigcontext without FPU state is 100 bytes, so we are at 276 bytes at > > > > least. > > > > > > > > Would it be unreasonable to bump it to 512 bytes to be done with it > > > > once and for all? Might have positive effects on cache behaviour as > > > > well. > > > > > > In that case, make ucontext_t 512 bytes and scale struct sigcontext > > > accordingly. > > > > > > > We may also need an way to tell an application at runtime how far the > > > > struct is filled. > > > > > > You need exactly 1 bit to tell the application if the FPU state is valid > > > or not, right? > > > > I don't think that is sufficient in the general case. > > If you refer to the general case here, then also do it for the saved > state. In the general case, that may be very incompatible for each > different FPU and or emulator, which is not limited to what we have now. We're talking different levels of generality here. I'm talking about more extensions to the "things" that a signal handler gets passed. > > We don't want to know whether a kernel that is capable of storing the > > FPU state did so (it does so in any case). We want to know whether the > > kernel is new enough that is even knows that the FPU state might be > > stored here. If it doesn't it can't set this bit. > > Thus, a new kernel sets a bit where an old kernel does not set it... > > > Longer explanation: > > > > In a kernel version 1 'struct sigcontext' has a number of fields > > making 100 bytes and padding to 512 bytes. > > > > struct sigcontext { > > char bla[100]; > > char padding[412]; > > }; > > > > In version 2, the FPU state is added and padding adjusted: > > struct sigcontext { > > char bla[100]; > > char fpu[200] > > char padding[212]; > > }; > > > > In version 3, some other state is added: > > struct sigcontext { > > char bla[100]; > > char fpu[200] > > cht otherstate[12] > > char padding[200]; > > }; > > > > Now, how can an application tell what is filled and what is not? A > > #define in the header file isn't suitable, since a binary compiled on > > one version might be moved to a didfferent kernel. > > If a new kernel breaks old binaries, then it's not backwards compatible > :-) A newer kernel can't even break old binaries that fail to use this scheme. The scheme I propose is to support newer binaries on older kernels. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 15 6:57:20 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0ACD814DEF for ; Mon, 15 Nov 1999 06:56:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id PAA09071 for ; Mon, 15 Nov 1999 15:56:46 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA44781 for freebsd-arch@freebsd.org; Mon, 15 Nov 1999 15:56:45 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 19AD014DEF for ; Mon, 15 Nov 1999 06:55:55 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id PAA84809 for arch@FreeBSD.org; Mon, 15 Nov 1999 15:30:29 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Mon, 15 Nov 1999 15:30:27 +0100 From: Marcel Moolenaar Message-ID: <38301903.52DDD6C4@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <382E8A1B.B7D9B7F0@scc.nl>, <19991115130854.A28445@cons.org> Subject: Re: cvs commit: src/sys/i386/include signal.h Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Cracauer wrote: > > > > > I disagree. Signal handlers don't use context information for (wild > > > > guess) 99.9% of the time. Bloating signalling definitions with details > > > > of the many different hardware configurations (even within a single > > > > architecture) is not the way to go. > > > > > > Maybe we have a different definition of "bloat", but since the size is > > > the same, this doesn't count as "bloat for me. > > > > The bloat is in what you get when you include > > OK, you're speaking compile-time bloat here. > > What I'm trying to do is to access members of a data struct by reusing > a struct definition that is already in our tree, and not requireing > the user to access the members by couting bytes and then cast. > > That not bloat, that's moving struct definitions to where they are > needed. But not *when* they are needed. As I said, only a very small number of applications actually need to use the context information passed on to the signal handler. I think it's better that these applications need to include another header for the in-depth definitions than that every C-source file that include signal.h gets poluted with these definitions. > > > When I implemented SA_SIGINFO, you could get it in a type-save way as > > > a member of the second argument. This capability has been removed by > > > your newer signal changes. > > > > Yes, because ucontext_t is not part of siginfo_t and adding it there > > only creates unnecessary dependencies and pitfalls. Not to mention the > > size increase and the shear unportability of the approach. > > Sorry, you are wrong here. It doesn't increase the amount of data that > is stored or copies for signal handlers. The sigframe is not increased by it, but that's the only place. > > You don't want to implement RT signals with a bloated siginfo_t... > > If the RT signals don't use a struct sigcontext at all (and I mean, > the kernel implementation doesn't need one when sending the signal and > returing from it, no matter whether the application's signal handler > can access it), then you can omit it. There's no need for every global and/or local declaration of siginfo_t to carry struct sigcontext. Neither do you want such a bloated structure passed as the argument of the RT signal syscalls back to the kernel. Especially when you're thinking of increasing sigcontext to about .5KB. It doesn't belong there. It shouldn't be there. > > A change in how the state is saved would then automaticly result in an > > interface change while this should not be the case (I should know, I did > > exactly the same thing :-) > > I don't understand why the fact the the description might not useful > in the emulator case prevents us from securing the case for the > hardware FPU case. Are you saying that you want a FP state structure that matches the hardware and is indifferent to how emulators store their state? This means you present a structure that only makes sense in a single case. That's even worse than using an array in all cases. > > If you refer to the general case here, then also do it for the saved > > state. In the general case, that may be very incompatible for each > > different FPU and or emulator, which is not limited to what we have now. > > We're talking different levels of generality here. I'm talking about > more extensions to the "things" that a signal handler gets passed. You're right. I'm not :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 15 8:14:28 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 84896150EC for ; Mon, 15 Nov 1999 08:14:13 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA10206 for ; Mon, 15 Nov 1999 17:14:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA45080 for freebsd-arch@freebsd.org; Mon, 15 Nov 1999 17:14:07 +0100 (MET) Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id E716014FD0 for ; Mon, 15 Nov 1999 08:06:45 -0800 (PST) (envelope-from grog@mojave.sitaranetworks.com) Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id CAA21054; Tue, 16 Nov 1999 02:36:19 +1030 (CST) (envelope-from grog@mojave.sitaranetworks.com) Message-ID: <19991113211846.31442@mojave.sitaranetworks.com> Date: Sat, 13 Nov 1999 21:18:46 -0500 From: Greg Lehey To: "Kenneth D. Merry" , Simon Shapiro Cc: Randell Jesup , freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) Reply-To: Greg Lehey References: <382B52F9.2C6D1E00@simon-shapiro.org> <199911120116.SAA30871@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199911120116.SAA30871@panzer.kdm.org>; from Kenneth D. Merry on Thu, Nov 11, 1999 at 06:16:16PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 12 November 1999 at 0:17:56 -0500, Simon Shapiro wrote: > "Kenneth D. Merry" wrote: >> Simon Shapiro wrote... >>> "Kenneth D. Merry" wrote: >>>> Simon Shapiro wrote... >>>>> "Kenneth D. Merry" wrote: >>>>>> How can you get speeds like that with just a 32-bit PCI bus? The specs for >>>>>> the PowerEdge 1300 say it has 5 32-bit PCI slots: >>>>> >>>>> These numbers are for block devices. The kernel obviously >>>>> caches some of this. I should look next time at emory usage; >>>>> The machine has 1GB of memory. The dataset is about 15GB per >>>>> array. >>>> >>>> Is that for random or sequential I/O? With sequential I/O, you would >>>> probably blow away any caching effects. With random I/O, though, you might >>>> get significant help from the cache, especially with that much RAM. >>> >>> Random, of course. >> >> Okay, that fits the results. I missed the beginning of this discussion, but I'd be interested in seeing how you measured it. I'd be interested to see what's going on here. I've seen some very weird corruption in Vinum (though not on the stack; instead, I get specific corruption of buffer headers, which is asynchronous to anything that Vinum is doing: in other words, it it not obviously related to the execution of any particular part of Vinum). Having said that, you shouldn't be running against the block device. We know that there are some problems there, and they're not going to be fixed. For example, it's relatively trivial to panic the machine doing a newfs on a block device. It's easier with Vinum, but it sometimes works with normal disk block devices as well. Since user access to block devices is going away, this will not be fixed. On Thursday, 11 November 1999 at 22:30:22 -0700, Kenneth D. Merry wrote: > Simon Shapiro wrote... >> "Kenneth D. Merry" wrote: >>> It could be that the combination of the DPT controller's 256MB cache and >>> fancy queueing, and your 1GB of RAM is causing the amazingly fast disk speeds. >> >> These DPTs seem to be optimal for RAID-5, very good at RAID-0 >> and nothing exciting for single disks. I have some FC-AL >> gear on order. >> >> What worries me is not the perfromance, but the corruption >> of the stack that I see. I'd be interested to see what's going on here. I've seen some very weird corruption in Vinum (though not on the stack; instead, I get specific corruption of buffer headers, which is asynchronous to anything that Vinum is doing: in other words, it it not obviously related to the execution of any particular part of Vinum). Having said that, you shouldn't be running against the block device. We know that there are some problems there, and they're not going to be fixed. For example, it's relatively trivial to panic the machine doing a newfs on a block device. It's easier with Vinum, but it sometimes works with normal disk block devices as well. Since user access to block devices is going away, this will not be fixed. >> For example, I can run the same 400 processes against the >> raw device all day and all night without a hitch. >> Run them against a block device and something bizzare >> happens; A filesystem get corrupted, the Adaptec driver >> times out, tsleep segfaults, something. At times I can >> get the error in the driver, but then it makes no sense >> either. There are tons of self-checks and state >> verifications in the code. None trip, or when they do >> they are as illogical as the null pointer inside tsleep. > > Well, since you've done a lot of work to try to isolate the problem in your > code, but haven't tracked it down, I'd suggest taking your code out of the > picture as a variable. > > Create a CCD or Vinum array, using the same disks on Adaptec controllers. > Run the same tests, against the raw and block devices, and see if you get > the same sort of weird behavior. > > If you do, you have solid proof that it's not your code, since your code > wasn't in the kernel. If you don't, unfortunately, you don't have solid > proof either way. (Since in that case, it could be some set of > circumstances that your driver tickles that CCD or Vinum don't.) Recall also my problems. You might end up falling over in a different way, in which case you don't know whther > One other thing to make sure of is that you're running a -stable with > Justin's Adaptec driver bug fix from September 20th. It fixed some cases > where corruption could happen with Ultra 2 Adaptec controllers. FWIW, the problems I have seen have been on other host adapters. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Nov 15 18:11:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C610F14C43 for ; Mon, 15 Nov 1999 18:11:50 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA16355 for ; Tue, 16 Nov 1999 03:11:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA47825 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 03:11:47 +0100 (MET) Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id 4DC5214C43 for ; Mon, 15 Nov 1999 18:11:36 -0800 (PST) (envelope-from areilly@nsw.bigpond.net.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA10843 for ; Tue, 16 Nov 1999 13:11:34 +1100 (EDT) X-BPC-Relay-Envelope-From: areilly@nsw.bigpond.net.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-49-170.nsw.bigpond.net.au [24.192.49.170]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id NAA02825 for ; Tue, 16 Nov 1999 13:11:31 +1100 (EDT) Received: (qmail 41915 invoked by uid 1000); 16 Nov 1999 02:11:31 -0000 From: "Andrew Reilly" Date: Tue, 16 Nov 1999 13:11:31 +1100 To: Martin Cracauer Cc: Marcel Moolenaar , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h Message-ID: <19991116131131.A40907@gurney.reilly.home> References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <19991115115552.A27870@cons.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Nov 15, 1999 at 11:55:52AM +0100, Martin Cracauer wrote: > In version 3, some other state is added: > struct sigcontext { > char bla[100]; > char fpu[200] > cht otherstate[12] > char padding[200]; > }; The P-III SSE registers are already making a claim on otherstate[], aren't they? There's a port (audio/gogo) that would use these registers if FreeBSD didn't mind. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 10: 4:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3233915239 for ; Tue, 16 Nov 1999 10:04:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA29040 for ; Tue, 16 Nov 1999 19:04:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA51124 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 19:04:27 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 1166215299 for ; Tue, 16 Nov 1999 10:03:40 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id NAA01763 for ; Tue, 16 Nov 1999 13:00:35 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h References: <382E8A1B.B7D9B7F0@scc.nl> <19991115095729.A27507@cons.org> <382FDBE2.D075594@scc.nl> <19991115115552.A27870@cons.org> <382FF2AF.545C8C81@scc.nl> <19991115130854.A28445@cons.org> From: Randell Jesup Date: 16 Nov 1999 13:03:52 -0500 In-Reply-To: Martin Cracauer's message of "Mon, 15 Nov 1999 13:08:54 +0100" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Martin Cracauer writes: >> > Maybe we have a different definition of "bloat", but since the size is >> > the same, this doesn't count as "bloat for me. >> >> The bloat is in what you get when you include > >OK, you're speaking compile-time bloat here. And that's pretty minor as bloat goes. >What I'm trying to do is to access members of a data struct by reusing >a struct definition that is already in our tree, and not requireing >the user to access the members by couting bytes and then cast. Counting bytes and casting is evil incarnate. (Ok, so I have a strong opinion on the subject.) >That not bloat, that's moving struct definitions to where they are >needed. I agree. I haven't looked at the files, and I don't know if this would be considered an 'acceptable' way of dealing with the issue, but if some people are dead set against including the structure defs from signal.h for the default (common) case, then how about some form of: #define __SIGNAL_H_PLEASE_INCLUDE_STRUTURES_FOR_SIGNAL_INFORMATION #include (Ick) IMHO -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com CDA II has been passed and signed, sigh. The lawsuit has been filed. Please support the organizations fighting it - ACLU, EFF, CDT, etc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 10:28:18 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7E2771522F for ; Tue, 16 Nov 1999 10:28:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA29286 for ; Tue, 16 Nov 1999 19:28:11 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA51262 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 19:28:10 +0100 (MET) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by hub.freebsd.org (Postfix) with ESMTP id 6FC7B15225; Tue, 16 Nov 1999 10:27:04 -0800 (PST) (envelope-from shin@nd.net.fujitsu.co.jp) Received: from localhost (kame209.kame.net [203.178.141.209]) by orange.kame.net (8.9.1+3.1W/3.7W) with ESMTP id DAA14988; Wed, 17 Nov 1999 03:26:05 +0900 (JST) To: pb@fasterix.freenix.org Cc: cvs-committers@freebsd.org Cc: freebsd-arch@freebsd.org Cc: sakane@kame.net Subject: Re: [Solicite review for KAME 2nd patch](netinet6 basic part addtion) In-Reply-To: <19991112152848.A90019@fasterix.frmug.org> References: <19991112115745B.shin@nd.net.fujitsu.co.jp> <19991112152848.A90019@fasterix.frmug.org> <19991113012530.A62524@fasterix.frmug.org> X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew) X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991117032655J.shin@nd.net.fujitsu.co.jp> Date: Wed, 17 Nov 1999 03:26:55 +0900 From: Yoshinobu Inoue X-Dispatcher: imput version 990905(IM130) Lines: 149 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG # This mail is a reply to the comment for my 2nd patch of KAME # merging into freebsd-current. # I cc this also to freebsd-arch, and would like the patch also # to be reviewed by freebsd-arch members. # Patches are placed at # http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kame-into-fbc.html # Thanks in advance! > > Please give me comments. > > Here are some relatively minor comments where I feel like I have > something interesting to say. I haven't taken the time to read the > patches in detail yet, I'll do that later. Thanks for your comments and patches! > > (1)KAME added new files sys/net/net_osdep.{c,h} for source code > > compatibility between different BSDs. > > Several KAME files depends on them. > > Could I just add those files to FreeBSD-current? > > Given that sys/net/*.h is supposed to end up in /usr/include/net, > IMHO a better way to handle that stuff would be to insert the > appropriate defines in the relevant include files, with associated > comment that it should be kept for compatibility purposes with > other BSDs. That would have the interesting side-effect of being > "more" compatible with other BSDs without even having to include > some special file. > > For example ifa_list should be defined where ifa_link is, i.e. > net/if_var.h. I moved them. > > (3)struct inpcb in sys/netinet/in_pcb.h is shared between > > netinet and netinet6, and much change is done on it. > > There are some needless tab <-> space diffs there, in inp_hash, > inp_list and inp_portlist for example. Also, I think the structure > had been carefully optimized so that the most accessed fields are > in the first 16 bytes (a i386-cache optimization I suppose), it > would be nice to keep that if possible. I mistakenly thought that a tab is also necessary after queue macro member as well as after var type or struct. I think I fixed all of them. About in_pcb first 16 bytes, I tried to re-order each members in my new patch, but addr part is difficult because it is now shared with IPv6 addr, and anyway, IPv6 addrs can not be put into 16 bytes. Should I add new pointer members which point to actual addr part and put them into first 16 bytes, or is it meaningless? > A followup on my first comments. > > 1) regarding the PF_KEY stuff, you define several extensions > for crypto algorithms not in RFC 2367, using SADB_EALG_ as a > prefix instead of SADB_EALG_X_ as requested by the RFC. > > Furthermore, the names you chose seem to be different from names > in OpenBSD (2.5) headers. > > (see http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pfkeyv2.h?rev=1.12) > > OpenBSD uses these, I think it would make sense to take the same > conventions (unless there's other in-progress RFC work for this > on which you based your code, of course): > > #define SADB_X_EALG_BLF 3 > #define SADB_X_EALG_CAST 4 > > Same remark for keyed MD5 and SHA1, OpenBSD uses these: > #define SADB_X_AALG_MD5 6 > #define SADB_X_AALG_SHA1 7 About this, I had a discussion with an actual implementer of that part. The part of KAME code you specified is based on a old draft of RFC2367 and he know it doesn't confrom to RFC2367. But real problem is that RFC2367 is not complete in many part, and each IPsec implementations(including KAME) has its own extensions(not only above part), and are not portable each other, anyway. He think updating current pfkey header as RFC2367 is meaingless, and wish to update it based on some commonly agreed new pfkey spec, and wish to just keep it as is for now. > 2) rather than having net/pfkeyv2.h an empty include calling > netkey/keyv2.h, wouldn't it be more sensible to do the opposite? > As I understand it, net/pfkeyv2.h is the "standard" name from > RFC 2367. It is mainly historical reason. Now it seems to be best timing to change the file to correct place, so I moved netkey/keyv2.h to net/pfkeyv2.h. > 3) there are many places with #ifdef code for NetBSD or OpenBSD; > couldn't at least some of these be removed? > > 4) related question for #ifdef FreeBSD: shouldn't the #ifdef go > away? I removed many #ifdef's including them, which seemed to be removable. > 5) a nitpick regarding indentation, there are a _lot_ of places where > "else" is indented like this, which is not allowed by style(9): > } > else { > > This should rather be: > } else { > > 6) another nitpick, there are many places with a needless trailing > space. > > I'm sending you a patch to your patch (!) to correct some of 5) > and 6). This is just intended as a manual reference for you, as I > made it by hand so it breaks the line numbers in your diffs. Thanks a lot! I removed unnecessary white spaces, and fixed indentations. Also I noticed several INET6s in header files, so I removed them as much as possible. New patches are placed below. http://paradise.kame.net/v6proxy/diana2/shin/work/freebsd/kame-into-fbc.html >> By the way, should this kind of review request be sent to >> freebsd-current, usually? >Yes. Actually freebsd-arch would probably be the best place for this. >You might consider reposting this there and asking for followups to be >discussed there. This time, I added cc to freebsd-arch as commented at the top. Thanks for all the comments again. Yoshinobu Inoue To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 10:50:29 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B2BD14C8E for ; Tue, 16 Nov 1999 10:50:22 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA29468 for ; Tue, 16 Nov 1999 19:50:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA51376 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 19:50:16 +0100 (MET) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (Postfix) with SMTP id 809F714A15 for ; Tue, 16 Nov 1999 10:47:15 -0800 (PST) (envelope-from shimon@simon-shapiro.org) Received: (qmail 69216 invoked from network); 16 Nov 1999 18:47:14 -0000 Received: from localhost.simon-shapiro.org (HELO simon-shapiro.org) (127.0.0.1) by localhost.simon-shapiro.org with SMTP; 16 Nov 1999 18:47:14 -0000 Message-ID: <3831A6B2.433979FE@simon-shapiro.org> Date: Tue, 16 Nov 1999 13:47:14 -0500 From: Simon Shapiro Organization: Simon's Garage X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: en-US MIME-Version: 1.0 To: Greg Lehey Cc: "Kenneth D. Merry" , Randell Jesup , freebsd-arch@freebsd.org Subject: Re: I/O Evaluation Questions (Long but interesting!) References: <382B52F9.2C6D1E00@simon-shapiro.org> <199911120116.SAA30871@panzer.kdm.org> <19991113211846.31442@mojave.sitaranetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: ... > I missed the beginning of this discussion, but I'd be interested in > seeing how you measured it. ftp://simon-shapiro.org/crash/tools/st.d.c To compile: make st.d && install -c- m 755 st.d /usr/local/bin To run (example): st.d -f /dev/ri2o5s4a -S -i 200 & ... kill -info %1 ... kill -hup %1 * Compilation is self explanatory. * st.d with no arguments gives usage. Somewhare on the same fto server is a user manual for st.d. * -f /dev/ri2o0s4a specifies that the I/O is against the first i2o bblock storage device, the fourth slice, first partition, as a character device. * -S says find the size of that device (stat does not tell it) and report it on stdout. * -i 200 says fork 200 instances (workers) * Defaults say do random read of 4KB blocks. * kill -info to the parent causes statistics to pring. * kill -hup causes all workers to exit, a final report to print. > I'd be interested to see what's going on here. I've seen some very > weird corruption in Vinum (though not on the stack; instead, I get > specific corruption of buffer headers, which is asynchronous to > anything that Vinum is doing: in other words, it it not obviously > related to the execution of any particular part of Vinum). A bit complicated, but bear with me: (micro-tutorial of i2o OSM block I/O execution flow): * We ignore initialization and open/close here. * Strategy called; Pop a command block off the Free Q. Assign the buf struct to this CB, parse the buf into an i2o inbund message, and add to the tail of the Waiting Q. Generate a software interrupt and returns. * Software interrupt scans the Submitted Q, verified the IOP has room on the Inbound FIFO, and pushes as many inbound messages into the IOP inbound FIFO. Each message thus pushed is marked and added to the tail of the Waiting Queue. * The IOP does its thing, DMAs whatever into user memory and generates a hardware interrupt. * Hisr identifies the completion, pops the CB off the Waiting Q, copies some state into the CB, adds the CB to the tail of the Completed Q and returns. * Software ISR walks the completed Q. Pops a CB off the Q, analyzes its completetion, (normally) calls biodone, adds the CB to the FreeQ, and returns. Obviously there are more details, SPLs, locks, state machine fingerprints, etc. The mechanism works well and is mighty fast. About every 2-3 million operations, under heavy CPU load (the load on the IOP is less than 50% - Cannot load it with FreeBSD with a single CPU), the Completed Q gets corrupted. It becomes a single CB, which points to itself. This CB has already been done (biodone has been called on it), and has the state flags of a member of the Free Q. Compiling the driver with -volatile -f volatile-global has no significant impact. From about a week of digging, we cannot identify where the failure is. Tracing is difficult, for the abvious reasons. > Having said that, you shouldn't be running against the block device. > We know that there are some problems there, and they're not going to > be fixed. For example, it's relatively trivial to panic the machine > doing a newfs on a block device. It's easier with Vinum, but it > sometimes works with normal disk block devices as well. Since user > access to block devices is going away, this will not be fixed. This problem happens quickly with the block device, and more slowly with the raw device. But still happens. Playing with timing, one can cause the problem to move from the driver to something irrelevant, like the filesystem. It panics during newfs, cpio, fsck, or anything else with some bizzarre errors I reported before. I belive it is related to how busy the CPU is on the Unix side. This is perhaps why vinum sees it in more places than i2o (uses more logic). Your last statement is unclear to me. If users have no access to block devices, there will be no buffered I/O? > > Well, since you've done a lot of work to try to isolate the problem in your > > code, but haven't tracked it down, I'd suggest taking your code out of the > > picture as a variable. > > > > Create a CCD or Vinum array, using the same disks on Adaptec controllers. > > Run the same tests, against the raw and block devices, and see if you get > > the same sort of weird behavior. > > > > If you do, you have solid proof that it's not your code, since your code > > wasn't in the kernel. If you don't, unfortunately, you don't have solid > > proof either way. (Since in that case, it could be some set of > > circumstances that your driver tickles that CCD or Vinum don't.) > > Recall also my problems. You might end up falling over in a different > way, in which case you don't know whther Agree. ... > > One other thing to make sure of is that you're running a -stable with > > Justin's Adaptec driver bug fix from September 20th. It fixed some cases > > where corruption could happen with Ultra 2 Adaptec controllers. > > FWIW, the problems I have seen have been on other host adapters. I am almost certain the IOP is not the culprit here. It is either a race condition in the OSM or some volatile memory is not. -- Sincerely Yours, Shimon@Simon-Shapiro.ORG 404.664.6401 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 10:51:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id EADC5152BD for ; Tue, 16 Nov 1999 10:51:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA29486 for ; Tue, 16 Nov 1999 19:51:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA51410 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 19:51:28 +0100 (MET) Received: from fasterix.frmug.org (s192.paris-90.cybercable.fr [212.198.90.192]) by hub.freebsd.org (Postfix) with ESMTP id 87C9614C8E; Tue, 16 Nov 1999 10:51:12 -0800 (PST) (envelope-from pb@fasterix.frmug.org) Received: (from pb@localhost) by fasterix.frmug.org (8.9.3/8.9.3/pb-19990315) id TAA47907; Tue, 16 Nov 1999 19:51:03 +0100 (CET) Message-ID: <19991116195103.Q1243@fasterix.frmug.org> Date: Tue, 16 Nov 1999 19:51:03 +0100 From: Pierre Beyssac To: Yoshinobu Inoue Cc: cvs-committers@freebsd.org, freebsd-arch@freebsd.org, sakane@kame.net Subject: Re: [Solicite review for KAME 2nd patch](netinet6 basic part addtion) References: <19991112115745B.shin@nd.net.fujitsu.co.jp> <19991112152848.A90019@fasterix.frmug.org> <19991113012530.A62524@fasterix.frmug.org> <19991112152848.A90019@fasterix.frmug.org> <19991117032655J.shin@nd.net.fujitsu.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.92.8i In-Reply-To: <19991117032655J.shin@nd.net.fujitsu.co.jp>; from Yoshinobu Inoue on Wed, Nov 17, 1999 at 03:26:55AM +0900 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 17, 1999 at 03:26:55AM +0900, Yoshinobu Inoue wrote: > About in_pcb first 16 bytes, I tried to re-order each members > in my new patch, but addr part is difficult because it is now > shared with IPv6 addr, and anyway, IPv6 addrs can not be put > into 16 bytes. > > Should I add new pointer members which point to actual addr > part and put them into first 16 bytes, or is it meaningless? I doubt that would be useful. It's probably better to leave that alone. For the rest of the "first 16 bytes" stuff, I think someone with better knowledge than I have of the specific networking structures optimizations for i386 should have a look. > He think updating current pfkey header as RFC2367 is > meaingless, and wish to update it based on some commonly > agreed new pfkey spec, and wish to just keep it as is for now. That's probably wise, as I hope at least Blowfish will be included in the next revision of the RFC since it's as popular as DES in most implementations... -- Pierre Beyssac pb@fasterix.frmug.org pb@fasterix.freenix.org BSD : il y a moins bien, mais c'est coté en bourse Free domains: http://www.eu.org/ or mail dns-manager@EU.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 12: 4:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C83A814D2A for ; Tue, 16 Nov 1999 12:04:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA00307 for ; Tue, 16 Nov 1999 21:04:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA51834 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 21:04:40 +0100 (MET) Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 5BB7614D2A for ; Tue, 16 Nov 1999 12:04:23 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA12834; Tue, 16 Nov 1999 20:05:44 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 16 Nov 1999 20:05:44 +0000 (GMT) From: Doug Rabson To: Andrew Reilly Cc: Martin Cracauer , Marcel Moolenaar , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: cvs commit: src/sys/i386/include signal.h In-Reply-To: <19991116131131.A40907@gurney.reilly.home> 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, 16 Nov 1999, Andrew Reilly wrote: > On Mon, Nov 15, 1999 at 11:55:52AM +0100, Martin Cracauer wrote: > > In version 3, some other state is added: > > struct sigcontext { > > char bla[100]; > > char fpu[200] > > cht otherstate[12] > > char padding[200]; > > }; > > The P-III SSE registers are already making a claim on > otherstate[], aren't they? > > There's a port (audio/gogo) that would use these registers if > FreeBSD didn't mind. Good point. If we are reserving space for FPU state in sigcontext, we *must* allow for SSE register state. I'm also hoping to use SSE instructions for a project and if noone else does it, I will put the support into -current when I need it. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 13:55:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A0F9014C1D for ; Tue, 16 Nov 1999 13:55:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA01416 for ; Tue, 16 Nov 1999 22:55:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA52434 for freebsd-arch@freebsd.org; Tue, 16 Nov 1999 22:55:09 +0100 (MET) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (Postfix) with SMTP id 31D0F151CA for ; Tue, 16 Nov 1999 13:54:36 -0800 (PST) (envelope-from shimon@simon-shapiro.org) Received: (qmail 71512 invoked from network); 16 Nov 1999 21:54:33 -0000 Received: from localhost.simon-shapiro.org (HELO simon-shapiro.org) (127.0.0.1) by localhost.simon-shapiro.org with SMTP; 16 Nov 1999 21:54:33 -0000 Message-ID: <3831D299.E4BA3755@simon-shapiro.org> Date: Tue, 16 Nov 1999 16:54:33 -0500 From: Simon Shapiro Organization: Simon's Garage X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: en-US MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Strange Behavior (was I/O Performance) Content-Type: multipart/mixed; boundary="------------FFE386F63B1262A719DA6467" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------FFE386F63B1262A719DA6467 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Things have changed; Moved the test environment from a Dell PowerEdge 1300/600 with 1GB RAM to an older ASUS MB with a P-II/300 and 256MB of RAM. * Strange Q corruption is not reproducible anymore. * Running a filesystem against it crashes the system; Processes simply stop, will not respond to kill -9. Attached are fdisk and disklabel for the device, as well as a debugger ps. For the life of me I cannot see the OSM doing anything evil now. It will really be nice to have this level of I/O available. I need help figuring it out. -- Sincerely Yours, Shimon@Simon-Shapiro.ORG 404.664.6401 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth --------------FFE386F63B1262A719DA6467 Content-Type: application/octet-stream; name="fdisk.i2o0" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fdisk.i2o0" KioqKioqKiBXb3JraW5nIG9uIGRldmljZSAvZGV2L3JpMm8wICoqKioqKioKcGFyYW1ldGVy cyBleHRyYWN0ZWQgZnJvbSBpbi1jb3JlIGRpc2tsYWJlbCBhcmU6CmN5bGluZGVycz01MjA2 OSBoZWFkcz02NCBzZWN0b3JzL3RyYWNrPTMyICgyMDQ4IGJsa3MvY3lsKQoKRmlndXJlcyBi ZWxvdyB3b24ndCB3b3JrIHdpdGggQklPUyBmb3IgcGFydGl0aW9ucyBub3QgaW4gY3lsIDEK cGFyYW1ldGVycyB0byBiZSB1c2VkIGZvciBCSU9TIGNhbGN1bGF0aW9ucyBhcmU6CmN5bGlu ZGVycz01MjA2OSBoZWFkcz02NCBzZWN0b3JzL3RyYWNrPTMyICgyMDQ4IGJsa3MvY3lsKQoK TWVkaWEgc2VjdG9yIHNpemUgaXMgNTEyCldhcm5pbmc6IEJJT1Mgc2VjdG9yIG51bWJlcmlu ZyBzdGFydHMgd2l0aCBzZWN0b3IgMQpJbmZvcm1hdGlvbiBmcm9tIERPUyBib290YmxvY2sg aXM6ClRoZSBkYXRhIGZvciBwYXJ0aXRpb24gMSBpczoKc3lzaWQgMTY1LChGcmVlQlNEL05l dEJTRC8zODZCU0QpCiAgICBzdGFydCAyMDQ4LCBzaXplIDEwNjYzMzIxNiAoNTIwNjcgTWVn KSwgZmxhZyA4MCAoYWN0aXZlKQoJYmVnOiBjeWwgMS8gc2VjdG9yIDEvIGhlYWQgMDsKCWVu ZDogY3lsIDg2Ny8gc2VjdG9yIDMyLyBoZWFkIDYzClRoZSBkYXRhIGZvciBwYXJ0aXRpb24g MiBpczoKPFVOVVNFRD4KVGhlIGRhdGEgZm9yIHBhcnRpdGlvbiAzIGlzOgo8VU5VU0VEPgpU aGUgZGF0YSBmb3IgcGFydGl0aW9uIDQgaXM6CjxVTlVTRUQ+Cg== --------------FFE386F63B1262A719DA6467 Content-Type: application/octet-stream; name="disklabel.i2o0" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="disklabel.i2o0" IyAvZGV2L3JpMm8wczFjOgp0eXBlOiB1bmtub3duCmRpc2s6IGkybzZ4REVDCmxhYmVsOiBC aWcgWmVybwpmbGFnczoKYnl0ZXMvc2VjdG9yOiA1MTIKc2VjdG9ycy90cmFjazogMjA0OAp0 cmFja3MvY3lsaW5kZXI6IDEKc2VjdG9ycy9jeWxpbmRlcjogMjA0OApjeWxpbmRlcnM6IDUy MDY3CnNlY3RvcnMvdW5pdDogMTA2NjMzMjE2CnJwbTogMTAwMDAKaW50ZXJsZWF2ZTogMQp0 cmFja3NrZXc6IDAKY3lsaW5kZXJza2V3OiAwCmhlYWRzd2l0Y2g6IDAJCSMgbWlsbGlzZWNv bmRzCnRyYWNrLXRvLXRyYWNrIHNlZWs6IDAJIyBtaWxsaXNlY29uZHMKZHJpdmVkYXRhOiAw IAoKMyBwYXJ0aXRpb25zOgojICAgICAgICBzaXplICAgb2Zmc2V0ICAgIGZzdHlwZSAgIFtm c2l6ZSBic2l6ZSBicHMvY3BnXQogIGE6IDEwNjYzMTE2OCAgICAgMjA0OCAgICA0LjJCU0Qg ICAgIDIwNDggMTYzODQgICAgMTYgCSMgKEN5bC4gICAgMSAtIDUyMDY2KQogIGM6IDEwNjYz MzIxNiAgICAgICAgMCAgICB1bnVzZWQgICAgIDEwMjQgIDgxOTIgICAgICAgCSMgKEN5bC4g ICAgMCAtIDUyMDY2KQo= --------------FFE386F63B1262A719DA6467 Content-Type: application/octet-stream; name="hang.ps" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="hang.ps" ZGI+IHBzCiAgcGlkICAgcHJvYyAgICAgYWRkciAgICB1aWQgIHBwaWQgIHBncnAgIGZsYWcg c3RhdCB3bWVzZyAgIHdjaGFuICAgY21kCjMwNzI5IGZiYzA5YTIwIGZiZDUyMDAwICAgIDAg MzA3MjggMzA3MjkgMDAwMDE0ICAzICAgaW5vZGUgZDRjMGZhMDAgY3JvbgozMDcyOCBmYmQ3 ZWFhMCBmYmUwYjAwMCAgICAwICAgMTkzICAgMTkzIDAwMDAwNCAgMyAgcHB3YWl0IGZiZDdl YWEwIGNyb24KMzA3MjcgZmJkN2VjMDAgZmJlMDgwMDAgICAgMCAgIDE5MCAgIDE5MCAwMDAw MDQgIDMgIG5ld2J1ZiBjMDM1MTcyNCBpbmV0ZAozMDcyNiBmYmQ3ZjE4MCBmYmRmNzAwMCAg ICAwIDMwNzI1IDMwNzI2IDAwMDAxNCAgMyAgbmV3YnVmIGMwMzUxNzI0IGNyb24KMzA3MjUg ZmJkODBhNDAgZmJkOGUwMDAgICAgMCAgIDE5MyAgIDE5MyAwMDAwMDQgIDMgIHBwd2FpdCBm YmQ4MGE0MCBjcm9uCjMwNzI0IGZiZDdkY2UwIGZiZTQ0MDAwICAgIDAgMzA3MTIgICAzNDQg MDA0MDA2ICAzICBuZXdidWYgYzAzNTE3MjQgcmFubGliCjMwNzEyIGZiZDgwYmEwIGZiZDg1 MDAwICAgIDAgMzA1MTMgICAzNDQgMDA0MDg2ICAzICAgIHdhaXQgZmJkODBiYTAgc2gKMzA1 MTMgZmJkN2ZmNDAgZmJkYTcwMDAgICAgMCAyMjQ4OCAgIDM0NCAwMDQwODYgIDMgIHNlbGVj dCBjMDM1MTQ3NCBtYWtlCjIyNDg4IGZiZDdlZWMwIGZiZGY5MDAwICAgIDAgMjI0ODUgICAz NDQgMDA0MDg2ICAzICAgIHdhaXQgZmJkN2VlYzAgc2gKMjI0ODUgZmJjMDljZTAgZmJkNDkw MDAgICAgMCAgIDM1NSAgIDM0NCAwMDQwODYgIDMgIHNlbGVjdCBjMDM1MTQ3NCBtYWtlCiAg NDQyIGZiZDgwNjIwIGZiZDk0MDAwICAgIDAgICAyNjggICA0NDIgMDA0MDA2ICAzICBuZXdi dWYgYzAzNTE3MjQgdGFpbAogIDM1NSBmYmMwOWU0MCBmYmQ0NjAwMCAgICAwICAgMzUyICAg MzQ0IDAwNDA4NiAgMyAgICB3YWl0IGZiYzA5ZTQwIHNoCiAgMzUyIGZiYzA5ZmEwIGZiY2Ey MDAwICAgIDAgICAzNTEgICAzNDQgMDA0MDg2ICAzICBzZWxlY3QgYzAzNTE0NzQgbWFrZQog IDM1MSBmYmMwYTEwMCBmYmM5NTAwMCAgICAwICAgMzQ4ICAgMzQ0IDAwNDA4NiAgMyAgICB3 YWl0IGZiYzBhMTAwIHNoCiAgMzQ4IGZiYzBhM2MwIGZiYzhkMDAwICAgIDAgICAzNDcgICAz NDQgMDA0MDg2ICAzICBzZWxlY3QgYzAzNTE0NzQgbWFrZQogIDM0NyBmYmMwYTUyMCBmYmM4 OTAwMCAgICAwICAgMzQ0ICAgMzQ0IDAwNDA4NiAgMyAgICB3YWl0IGZiYzBhNTIwIHNoCiAg MzQ0IGZiYzBhMjYwIGZiYzkxMDAwICAgIDAgICAyNjggICAzNDQgMDA0MDg2ICAzICBzZWxl Y3QgYzAzNTE0NzQgbWFrZQogIDI2OSBmYmMwYTY4MCBmYmM3YjAwMCAgICAwICAgICAxICAg ICAxIDAwNDA4NCAgMyAgc2lvZGNkIGMwMzRlZTQ0IGdldHR5CiAgMjY4IGZiYzBhN2UwIGZi Yzc3MDAwICAgIDAgICAgIDEgICAyNjggMDA0MDg2ICAzICAgIHdhaXQgZmJjMGE3ZTAgYmFz aAogIDI2NyBmYmMwYTk0MCBmYmM3NDAwMCAgICAwICAgICAxICAgMjY3IDAwNDA4NiAgMyAg IHR0eWluIGMwMzRjN2Q0IGdldHR5CiAgMjY2IGZiYzBhYWEwIGZiYzcxMDAwICAgIDAgICAg IDEgICAyNjYgMDA0MDg2ICAzICAgdHR5aW4gYzAzNGM2ZTAgZ2V0dHkKICAyNjUgZmJjMGFj MDAgZmJjNmUwMDAgICAgMCAgICAgMSAgIDI2NSAwMDQwODYgIDMgICB0dHlpbiBjMDM0YzVl YyBnZXR0eQogIDI2NCBmYmMwYzc4MCBmYmMxZjAwMCAgICAwICAgICAxICAgMjY0IDAwNDA4 NiAgMyAgIHR0eWluIGMwMzRjNGY4IGdldHR5CiAgMjYzIGZiYzBiMDIwIGZiYzYzMDAwICAg IDAgICAgIDEgICAyNjMgMDA0MDg2ICAzICAgdHR5aW4gYzAzNGM0MDQgZ2V0dHkKICAyNjIg ZmJjMGFlYzAgZmJjNjYwMDAgICAgMCAgICAgMSAgIDI2MiAwMDQwODYgIDMgICB0dHlpbiBj MDM0YzMxMCBnZXR0eQogIDI2MSBmYmMwYjE4MCBmYmM1ZjAwMCAgICAwICAgICAxICAgMjYx IDAwNDA4NiAgMyAgIHR0eWluIGMwMzRjMjFjIGdldHR5CiAgMjYwIGZiYzBjOGUwIGZiYzFj MDAwICAgIDAgICAgIDEgICAyNjAgMDA0MDA2ICAzICBuZXdidWYgYzAzNTE3MjQgZ2V0dHkK ICAyMzkgZmJjMGFkNjAgZmJjNjkwMDAgICAgMCAgICAgMSAgIDIzOSAwMDAwODQgIDMgIHNl bGVjdCBjMDM1MTQ3NCBzc2hkMgogIDE5MyBmYmMwYjJlMCBmYmM1YzAwMCAgICAwICAgICAx ICAgMTkzIDAwMDA4NCAgMyAgbmFuc2xwIGMwMzE3Njc4IGNyb24KICAxOTAgZmJjMGI5YzAg ZmJjNGIwMDAgICAgMCAgICAgMSAgIDE5MCAwMDAwODQgIDMgIHNlbGVjdCBjMDM1MTQ3NCBp bmV0ZAogIDE2NiBmYmMwYjQ0MCBmYmM1ODAwMCAgICAwICAgICAxICAgMTYxIDAwMDA4NCAg MyAgbmZzaWRsIGMwMzU0Mzk0IG5mc2lvZAogIDE2NSBmYmMwYjVhMCBmYmM1NDAwMCAgICAw ICAgICAxICAgMTYxIDAwMDA4NCAgMyAgbmZzaWRsIGMwMzU0MzkwIG5mc2lvZAogIDE2NCBm YmMwYjcwMCBmYmM1MTAwMCAgICAwICAgICAxICAgMTYxIDAwMDA4NCAgMyAgbmZzaWRsIGMw MzU0MzhjIG5mc2lvZAogIDE2MyBmYmMwYjg2MCBmYmM0ZTAwMCAgICAwICAgICAxICAgMTYx IDAwMDA4NCAgMyAgbmZzaWRsIGMwMzU0Mzg4IG5mc2lvZAogIDE1OCBmYmMwYmIyMCBmYmM0 NzAwMCAgICAwICAgICAxICAgMTU4IDAwMDA4NCAgMyAgc2VsZWN0IGMwMzUxNDc0IHJwYy5z dGF0ZAogIDE1NSBmYmMwYmM4MCBmYmM0NDAwMCAgICAwICAgMTUwICAgMTUwIDAwMDA4NCAg MyAgICBuZnNkIGQ0YjFhMjAwIG5mc2QKICAxNTQgZmJjMGJkZTAgZmJjNDEwMDAgICAgMCAg IDE1MCAgIDE1MCAwMDAwODQgIDMgICAgbmZzZCBkNGJmZGUwMCBuZnNkCiAgMTUzIGZiYzBi ZjQwIGZiYzNlMDAwICAgIDAgICAxNTAgICAxNTAgMDAwMDg0ICAzICAgIG5mc2QgZDRiMWE0 MDAgbmZzZAogIDE1MiBmYmMwYzBhMCBmYmMzYjAwMCAgICAwICAgMTUwICAgMTUwIDAwMDA4 NCAgMyAgICBuZnNkIGQ0YjFhNjAwIG5mc2QKICAxNTAgZmJjMGMyMDAgZmJjMzgwMDAgICAg MCAgICAgMSAgIDE1MCAwMDAwODQgIDMgIGFjY2VwdCBmNjAwM2FkNiBuZnNkCiAgMTQ3IGZi YzBjMzYwIGZiYzM1MDAwICAgIDAgICAgIDEgICAxNDcgMDAwMDg0ICAzICBzZWxlY3QgYzAz NTE0NzQgbW91bnRkCiAgMTM2IGZiYzBjNGMwIGZiYzMyMDAwICAgIDEgICAgIDEgICAxMzYg MDAwMTg0ICAzICBzZWxlY3QgYzAzNTE0NzQgcG9ydG1hcAogIDEyNyBmYmMwYzYyMCBmYmMy OTAwMCAgICAwICAgICAxICAgMTI3IDAwMDAwNCAgMyAgbmV3YnVmIGMwMzUxNzI0IHN5c2xv Z2QKICAgIDQgZmJjMGNhNDAgZmJjMTcwMDAgICAgMCAgICAgMCAgICAgMCAwMDAyMDQgIDMg ICBpbm9kZSBkNGNhZDYwMCBzeW5jZXIKICAgIDMgZmJjMGNiYTAgZmJjMTUwMDAgICAgMCAg ICAgMCAgICAgMCAwMDAyMDQgIDMgIHBzbGVlcCBjMDMzOTE3NCB2bWRhZW1vbgogICAgMiBm YmMwY2QwMCBmYmMxMzAwMCAgICAwICAgICAwICAgICAwIDAwMDIwNCAgMyAgcHNsZWVwIGMw MzA1N2MwIHBhZ2VkYWVtb24KICAgIDEgZmJjMGNlNjAgZmJjMTEwMDAgICAgMCAgICAgMCAg ICAgMSAwMDQwODQgIDMgICAgd2FpdCBmYmMwY2U2MCBpbml0CiAgICAwIGMwMzUwNzVjIGMw M2JkMDAwICAgIDAgICAgIDAgICAgIDAgMDAwMjA0ICAzICAgc2NoZWQgYzAzNTA3NWMgc3dh cHBlcgpkYj4gIApkYj4gIGNhbGwgYm9vdAoKc3luY2luZyBkaXNrcy4uLiAKCkZhdGFsIHRy YXAgMTI6IHBhZ2UgZmF1bHQgd2hpbGUgaW4ga2VybmVsIG1vZGUKZmF1bHQgdmlydHVhbCBh ZGRyZXNzCT0gMHhiOApmYXVsdCBjb2RlCQk9IHN1cGVydmlzb3IgcmVhZCwgcGFnZSBub3Qg cHJlc2VudAppbnN0cnVjdGlvbiBwb2ludGVyCT0gMHg4OjB4YzAxNmRkYmIKc3RhY2sgcG9p bnRlcgkgICAgICAgID0gMHgxMDoweGMwMmQ0OTEwCmZyYW1lIHBvaW50ZXIJICAgICAgICA9 IDB4MTA6MHhjMDJkNDkyNApjb2RlIHNlZ21lbnQJCT0gYmFzZSAweDAsIGxpbWl0IDB4ZmZm ZmYsIHR5cGUgMHgxYgoJCQk9IERQTCAwLCBwcmVzIDEsIGRlZjMyIDEsIGdyYW4gMQpwcm9j ZXNzb3IgZWZsYWdzCT0gaW50ZXJydXB0IGVuYWJsZWQsIHJlc3VtZSwgSU9QTCA9IDAKY3Vy cmVudCBwcm9jZXNzCQk9IElkbGUKaW50ZXJydXB0IG1hc2sJCT0gdHR5IGJpbyAKa2VybmVs OiB0eXBlIDEyIHRyYXAsIGNvZGU9MApTdG9wcGVkIGF0ICAgICAgRGVidWdnZXIrMHgzNzog IG1vdmwgICAgJDAsaW5fRGVidWdnZXIKZGI+IApkYj4gY2FsbCBib290CmRwdDA6IFNodXR0 aW5nIGRvd24gKG1vZGUgMCkgSEJBLglQbGVhc2Ugd2FpdC4uLgpkcHQwOiBDb250cm9sbGVy IHdhcyB3YXJuZWQgb2Ygc2h1dGRvd24gYW5kIGlzIG5vdyBkaXNhYmxlZApJMk86IFNodXR0 aW5nIGRvd24gKG1vZGUgMCBmb3IgMCkuICBQbGVhc2Ugd2FpdC4uLgppMm8wOiBDb250cm9s bGVyIHNob3VsZCAgYmUgd2FybmVkIG9mIHNodXRkb3duIGFuZCBzaG91bGQgYmUgZGlzYWJs ZWQgaGVyZS4uLgpSZWJvb3RpbmcuLi4KCg== --------------FFE386F63B1262A719DA6467-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Nov 16 19:22:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4C79214A16 for ; Tue, 16 Nov 1999 19:22:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA04699 for ; Wed, 17 Nov 1999 04:22:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA53740 for freebsd-arch@freebsd.org; Wed, 17 Nov 1999 04:22:01 +0100 (MET) Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id B739E14E84 for ; Tue, 16 Nov 1999 19:20:46 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA20961; Tue, 16 Nov 1999 20:20:20 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp05.primenet.com, id smtpdAAA5maW3O; Tue Nov 16 20:20:14 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id UAA07079; Tue, 16 Nov 1999 20:20:25 -0700 (MST) From: Terry Lambert Message-Id: <199911170320.UAA07079@usr08.primenet.com> Subject: Re: cvs commit: src/sys/i386/include signal.h To: cracauer@cons.org (Martin Cracauer) Date: Wed, 17 Nov 1999 03:20:25 +0000 (GMT) Cc: marcel@scc.nl, cracauer@cons.org, bde@zeta.org.au, freebsd-arch@freebsd.org In-Reply-To: <19991115115552.A27870@cons.org> from "Martin Cracauer" at Nov 15, 99 11:55:52 am X-Mailer: ELM [version 2.4 PL25] 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 moved this to -arch, since we have to make some long-term decisions > here: > > 1) Does FreeBSD prefer to pass information like this as unnamed array > of bytes or as structs with proper fields? As an observer... I think any time there is a contract between the kernel and user space about the layout of a field, it's evil. There are a lot of data interfaces that exist which are very, very bad for the stability of software over upgrades (e.g. "ps", "netstat", et. al.). That said, I think "signal" is an exception in this case, so if there is going to be a data interface for signal, and you are going to reorganize it, at least put a version number field in so that you can do backward compatability the right way (or "at all", for that matter). 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 Wed Nov 17 21:59: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 145E714A09 for ; Wed, 17 Nov 1999 21:58:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA25728 for ; Thu, 18 Nov 1999 06:58:55 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA60708 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 06:58:55 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8A29714A09 for ; Wed, 17 Nov 1999 21:58:47 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id WAA09780 for ; Wed, 17 Nov 1999 22:58:46 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA21245 for ; Wed, 17 Nov 1999 22:59:07 -0700 (MST) Message-Id: <199911180559.WAA21245@harmony.village.org> To: arch@freebsd.org Subject: Cross compilation goals. In-reply-to: Your message of "Wed, 17 Nov 1999 18:40:34 PST." <19991117184034.A53402@dragon.nuxi.com> References: <19991117184034.A53402@dragon.nuxi.com> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> Date: Wed, 17 Nov 1999 22:59:07 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In private Mail, David O'Brian asked the musical questions: : Would it be possible ... [to] discuss the issue and come up : with a unified plan? Either privately, or on the freebsd-arch list? Sure. Maybe it might be a good idea to start with goals. Everyone is working from different goals... Goals: 1) The ability to generate code for the target platform. The target platform may be a different architecture, or a different version of FreeBSD than the host system runs. 2) The ability to build tools to generate code for the target platform in a standard way. 3) The ability to install the cross tools. 4) The ability to specify a different set of tools easily so that one can do cross development, rather than just cross compilation. 5) Any methods will be documented 6) No impact on the non-cross compilation cases (eg, we can't break native builds) 7) Be useful for a buildworld replacement which will solve the problem of tools generating binaries to build the rest of the system that cannot run on the system at hand due to new kernel functionalty. Non-goal: 1) Have the cross compilation code necessarily work on other systems. I'd like to keep these goals simple and not let this get out of hand. But rather as a sanity check for those interested enough to have committed code to the efforts along the way. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Nov 17 22:50:32 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 654AB14A1D for ; Wed, 17 Nov 1999 22:50:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA26265 for ; Thu, 18 Nov 1999 07:50:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA60867 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 07:50:27 +0100 (MET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 3ED4914ECF for ; Wed, 17 Nov 1999 22:48:03 -0800 (PST) (envelope-from michael.schuster@germany.sun.com) Received: from emuc05-home.Germany.Sun.COM ([129.157.51.10]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA06265 for ; Wed, 17 Nov 1999 22:47:58 -0800 (PST) Received: from germany.sun.com (hacker [129.157.167.97]) by emuc05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with ESMTP id HAA16965 for ; Thu, 18 Nov 1999 07:47:57 +0100 (MET) Message-ID: <3833A123.E390849A@germany.sun.com> Date: Thu, 18 Nov 1999 07:48:03 +0100 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 Cc: arch@freebsd.org Subject: Re: Cross compilation goals. References: <19991117184034.A53402@dragon.nuxi.com> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> <199911180559.WAA21245@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In private Mail, David O'Brian asked the musical questions: > : Would it be possible ... [to] discuss the issue and come up > : with a unified plan? Either privately, or on the freebsd-arch list? > > Sure. Maybe it might be a good idea to start with goals. Everyone is > working from different goals... > > Goals: > 1) The ability to generate code for the target platform. The > target platform may be a different architecture, or a > different version of FreeBSD than the host system runs. > 2) The ability to build tools to generate code for the target > platform in a standard way. > 3) The ability to install the cross tools. > 4) The ability to specify a different set of tools easily so > that one can do cross development, rather than just cross > compilation. > 5) Any methods will be documented > 6) No impact on the non-cross compilation cases (eg, we can't > break native builds) > 7) Be useful for a buildworld replacement which will solve > the problem of tools generating binaries to build the rest > of the system that cannot run on the system at hand due to > new kernel functionalty. > > Non-goal: > > 1) Have the cross compilation code necessarily work on other > systems. what does that mean? in this context, what does "other system" mean? > I'd like to keep these goals simple and not let this get out of hand. > But rather as a sanity check for those interested enough to have > committed code to the efforts along the way. > > Comments? > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- Michael Schuster / Michael.Schuster@germany.sun.com Technical Solution Center / SunOS Competence Center Sun Microsystem GmbH / Richard-Reitzner Allee 8, D-85540 Haar (+49 89) 46008 974 / x12974 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 1:20:40 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CFEC61531B for ; Thu, 18 Nov 1999 01:20:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA28847 for ; Thu, 18 Nov 1999 10:20:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA61406 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 10:20:29 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id A714C15369 for ; Thu, 18 Nov 1999 01:18:28 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id UAA20893; Thu, 18 Nov 1999 20:20:58 +1100 (EST) (envelope-from jb) Date: Thu, 18 Nov 1999 20:20:58 +1100 From: John Birrell To: Warner Losh Cc: arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991118202058.D13376@freebsd1.cimlogic.com.au> References: <19991117184034.A53402@dragon.nuxi.com> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> <19991117184034.A53402@dragon.nuxi.com> <199911180559.WAA21245@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199911180559.WAA21245@harmony.village.org>; from Warner Losh on Wed, Nov 17, 1999 at 10:59:07PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Nov 17, 1999 at 10:59:07PM -0700, Warner Losh wrote: > I'd like to keep these goals simple and not let this get out of hand. > But rather as a sanity check for those interested enough to have > committed code to the efforts along the way. > > Comments? FWIW, I agree. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 1:22: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 6359D153A6 for ; Thu, 18 Nov 1999 01:22:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA28885 for ; Thu, 18 Nov 1999 10:22:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA61423 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 10:22:00 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 8B97E154BF for ; Thu, 18 Nov 1999 01:17:44 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id UAA20875; Thu, 18 Nov 1999 20:20:15 +1100 (EST) (envelope-from jb) Date: Thu, 18 Nov 1999 20:20:15 +1100 From: John Birrell To: Michael Schuster - TSC SunOS Germany Cc: arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991118202014.C13376@freebsd1.cimlogic.com.au> References: <19991117184034.A53402@dragon.nuxi.com> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> <199911180559.WAA21245@harmony.village.org> <3833A123.E390849A@germany.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <3833A123.E390849A@germany.sun.com>; from Michael Schuster - TSC SunOS Germany on Thu, Nov 18, 1999 at 07:48:03AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 18, 1999 at 07:48:03AM +0100, Michael Schuster - TSC SunOS Germany wrote: > > Non-goal: > > > > 1) Have the cross compilation code necessarily work on other > > systems. > > what does that mean? > > in this context, what does "other system" mean? To me it means that I can build tools that are hosted on FreeBSD but targeted to things like rtems, Lynxos, VxWorks etc. The binutils stuff in the tree already supports this. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 1:29: 3 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9B47C1538F for ; Thu, 18 Nov 1999 01:28:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA29035 for ; Thu, 18 Nov 1999 10:28:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA61477 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 10:28:53 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id D40CE153A6 for ; Thu, 18 Nov 1999 01:26:07 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id KAA02276 for arch@FreeBSD.org; Thu, 18 Nov 1999 10:17:07 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Thu, 18 Nov 1999 10:16:59 +0100 From: Marcel Moolenaar Message-ID: <3833C40B.EC5290CF@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> Subject: Re: Cross compilation goals. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In private Mail, David O'Brian asked the musical questions: > : Would it be possible ... [to] discuss the issue and come up > : with a unified plan? Either privately, or on the freebsd-arch list? > > 7) Be useful for a buildworld replacement which will solve > the problem of tools generating binaries to build the rest > of the system that cannot run on the system at hand due to > new kernel functionalty. My history of thoughts (in no particular order): The sigset_t changes revealed 2 problems: 1) I wasn't able to at least compile any changes I made to the Alpha port, because I didn't have an Alpha during that time, 2) makeworld broke because the newly compiled tools were made against the new sigset_t while the system wasn't using it yet. If we fix 1), then 2) is gone too, right? right! So, the idea of cross-compilation was born. From now on I will call the ability to make an i386 world on a non-i386 host a cross-build. This to avoid confusion with cross-compilation: The ability to translate language A (C/asm) to language B (alpha machine code) whilst the translators are written in language C (i386 machine code). Cross-compilation and cross-building don't share the same problem-space and each have a different set of goals (non necessarily disjunct). The goals Warner gave were mostly those in the cross-building domain, right? I think jb has its goals more in the cross-compilation domain, right? My priorities are in the cross-building domain, because a release is coming soon and we need to restore the upgrade path. After cross-building has been done, everybody is free and encouraged to implement cross-compilation. My personal thoughts on the subject of the ability to make cross-compilers from within our source tree are *at this time* dominated by it's use for cross-building. I don't see a point to bloat our source tree with the ability to make a cross-compilation toolset for NT (for example) while there's this really neat ports collection in which we can add anything that's not directly related/necessary for out base-system. My suggestion is this: Let's talk cross-building first and fix our make world. When release 4.0 is out we have the time and the (inner) peace to discuss how we think we should help developers that eat cross-compilers for breakfast :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 18 2:21:23 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 871E115363 for ; Thu, 18 Nov 1999 02:21:19 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA00141 for ; Thu, 18 Nov 1999 11:21:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA61614 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 11:21:12 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id A57F515363 for ; Thu, 18 Nov 1999 02:20:10 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id VAA21316; Thu, 18 Nov 1999 21:22:34 +1100 (EST) (envelope-from jb) Date: Thu, 18 Nov 1999 21:22:34 +1100 From: John Birrell To: Marcel Moolenaar Cc: arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991118212234.E13376@freebsd1.cimlogic.com.au> References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <3833C40B.EC5290CF@scc.nl>; from Marcel Moolenaar on Thu, Nov 18, 1999 at 10:16:59AM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 18, 1999 at 10:16:59AM +0100, Marcel Moolenaar wrote: > Cross-compilation and cross-building don't share the same problem-space > and each have a different set of goals (non necessarily disjunct). I think that cross-compilation is a superset of cross-building if you want to make a distinction between the too. > My personal thoughts on the subject of the ability to make > cross-compilers from within our source tree are *at this time* dominated > by it's use for cross-building. I don't see a point to bloat our source > tree with the ability to make a cross-compilation toolset for NT (for > example) while there's this really neat ports collection in which we can > add anything that's not directly related/necessary for out base-system. The build I have avoids bloat for those who don't want the cross-compilation tools. I want the build system to be flexible enough to get tools "for all seasons". To me, the build makefiles are the key to it. I rarely get what I want out of Cygnus' configure shit^H^H^Htuff. I can easily cross-build FreeBSD sources targeted to NetBSD/m68k/aout the way I build the compiler. And I can cross-build non-FreeBSD sources targeted at LynxOS/PowerPC or NT/i386. The binutils makefiles in the tree already support that. Extending them to other architectures is trivial. I want the compiler build to be the same way. There is very little bloat (just a few more makefiles) for those who only want to build. I want to see FreeBSD become a serious contender as a development platform (preferably out of the box). > My suggestion is this: > Let's talk cross-building first and fix our make world. When release 4.0 > is out we have the time and the (inner) peace to discuss how we think we > should help developers that eat cross-compilers for breakfast :-) I think we can do both at the same time. We seem to disagree on the mechanics of how we should drive a cross-build. _I_ think we should use MACHINE and MACHINE_ARCH which are set in make(1) as a convenience for host builds, but can be overridden for cross-builds. They are not there for any other make function AFAIK. I agree that the make(1) man page doesn't support this, but I think that is just a few paragraphs of documentation that can be "fixed" (or changed to suit the new world order). What I _don't_ want to see is gcc trying to interpret MACHINE_ARCH or TARGET_ARCH or somehow trying to "discover" that it is cross-compiling. I think we can just do what Cygnus does and build a dedicated version of gcc for each target. I want the makefiles (including .mk) to have control over how things build. I also don't want to see make(1) customized. I would like to ask that we use the version of make from 2.2.5 (or whenever the -m switch was first implemented) as the reference. If we can't do a cross-build with an old version of make like that, then we're doing something wrong. At work I have to live with GNU make because of portability issues across Solaris, NT, Linux and FreeBSD. I'm tempted to suggest that we drop BSD make in favour of gmake. I bet a suggestion like that will wake people up. 8-) I'm only half joking. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 4:17: 7 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id B3632153D1 for ; Thu, 18 Nov 1999 04:17:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA02659 for ; Thu, 18 Nov 1999 13:16:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA62155 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 13:16:58 +0100 (MET) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (Postfix) with SMTP id 73BEE153D1 for ; Thu, 18 Nov 1999 04:16:26 -0800 (PST) (envelope-from shimon@simon-shapiro.org) Received: (qmail 83744 invoked from network); 18 Nov 1999 12:16:25 -0000 Received: from localhost.simon-shapiro.org (HELO simon-shapiro.org) (127.0.0.1) by localhost.simon-shapiro.org with SMTP; 18 Nov 1999 12:16:25 -0000 Message-ID: <3833EE19.A7DC5935@simon-shapiro.org> Date: Thu, 18 Nov 1999 07:16:25 -0500 From: Simon Shapiro Organization: Simon's Garage X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: en-US MIME-Version: 1.0 To: John Birrell Cc: Marcel Moolenaar , arch@freebsd.org Subject: Re: Cross compilation goals. References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> <19991118212234.E13376@freebsd1.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > > On Thu, Nov 18, 1999 at 10:16:59AM +0100, Marcel Moolenaar wrote: > > Cross-compilation and cross-building don't share the same problem-space > > and each have a different set of goals (non necessarily disjunct). > > I think that cross-compilation is a superset of cross-building if you > want to make a distinction between the too. > > > My personal thoughts on the subject of the ability to make > > cross-compilers from within our source tree are *at this time* dominated > > by it's use for cross-building. I don't see a point to bloat our source > > tree with the ability to make a cross-compilation toolset for NT (for > > example) while there's this really neat ports collection in which we can > > add anything that's not directly related/necessary for out base-system. > > The build I have avoids bloat for those who don't want the cross-compilation > tools. I want the build system to be flexible enough to get tools "for > all seasons". To me, the build makefiles are the key to it. I rarely > get what I want out of Cygnus' configure shit^H^H^Htuff. > > I can easily cross-build FreeBSD sources targeted to NetBSD/m68k/aout > the way I build the compiler. And I can cross-build non-FreeBSD sources > targeted at LynxOS/PowerPC or NT/i386. The binutils makefiles in the > tree already support that. Extending them to other architectures is > trivial. I want the compiler build to be the same way. There is very > little bloat (just a few more makefiles) for those who only want to > build. > > I want to see FreeBSD become a serious contender as a development > platform (preferably out of the box). Haleluya! > > My suggestion is this: > > Let's talk cross-building first and fix our make world. When release 4.0 > > is out we have the time and the (inner) peace to discuss how we think we > > should help developers that eat cross-compilers for breakfast :-) > > I think we can do both at the same time. Agree. > We seem to disagree on the mechanics of how we should drive a cross-build. > _I_ think we should use MACHINE and MACHINE_ARCH which are set in make(1) > as a convenience for host builds, but can be overridden for cross-builds. > They are not there for any other make function AFAIK. I agree that the > make(1) man page doesn't support this, but I think that is just a few > paragraphs of documentation that can be "fixed" (or changed to suit the > new world order). Documentation fixes are easier, and more reliable than code fixes. Always. :-) > What I _don't_ want to see is gcc trying to interpret MACHINE_ARCH > or TARGET_ARCH or somehow trying to "discover" that it is cross-compiling. > I think we can just do what Cygnus does and build a dedicated version > of gcc for each target. A 22GB drive is $200. You are right, as this keeps the compiler simpler. > I want the makefiles (including .mk) to have control over how things build. > > I also don't want to see make(1) customized. I would like to ask that > we use the version of make from 2.2.5 (or whenever the -m switch was > first implemented) as the reference. If we can't do a cross-build with > an old version of make like that, then we're doing something wrong. > > At work I have to live with GNU make because of portability issues > across Solaris, NT, Linux and FreeBSD. I'm tempted to suggest that we > drop BSD make in favour of gmake. I bet a suggestion like that will > wake people up. 8-) I'm only half joking. Why not? Does it work? Can it execute our current makefiles correctly? I know ours make cannot run many for-gnu makefiles. > -- > John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ > john.birrell@cai.com john.birrell@opendirectory.com.au > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message -- Sincerely Yours, Shimon@Simon-Shapiro.ORG 404.664.6401 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 4:28: 5 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 939F11507C for ; Thu, 18 Nov 1999 04:28:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id NAA02929 for ; Thu, 18 Nov 1999 13:28:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA62244 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 13:28:00 +0100 (MET) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id EC1A5154C2 for ; Thu, 18 Nov 1999 04:24:09 -0800 (PST) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11oQbw-0002Dc-00; Thu, 18 Nov 1999 12:24:25 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id NAA73202; Thu, 18 Nov 1999 13:24:02 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <3833EFE2.A6D975F2@scc.nl> Date: Thu, 18 Nov 1999 13:24:02 +0100 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Birrell Cc: arch@freebsd.org Subject: Re: Cross compilation goals. References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> <19991118212234.E13376@freebsd1.cimlogic.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Birrell wrote: > > On Thu, Nov 18, 1999 at 10:16:59AM +0100, Marcel Moolenaar wrote: > > Cross-compilation and cross-building don't share the same problem-space > > and each have a different set of goals (non necessarily disjunct). > > I think that cross-compilation is a superset of cross-building if you > want to make a distinction between the too. No. Cross-building has to deal with issues that aren't in the problem domain of cross-compilation. A cross-build has to be able to build itself (by this I mean that the build process has to handle incompatibilities and has to generate its own tools). This is not an issue in cross-compilation, where the problem domain is limited to how a user should make and install cross-compilation tools. > > My personal thoughts on the subject of the ability to make > > cross-compilers from within our source tree are *at this time* dominated > > by it's use for cross-building. I don't see a point to bloat our source > > tree with the ability to make a cross-compilation toolset for NT (for > > example) while there's this really neat ports collection in which we can > > add anything that's not directly related/necessary for out base-system. > > The build I have avoids bloat for those who don't want the cross-compilation > tools. I want the build system to be flexible enough to get tools "for > all seasons". To me, the build makefiles are the key to it. I rarely > get what I want out of Cygnus' configure shit^H^H^Htuff. I don't understand you. You duplicate the entire /usr/src/gnu/usr.bin/cc tree for each architecture you want to be able to build a cross-compiler for and still claim you *avoid* bloat? The build system should first and for all be able to build a FreeBSD system. It should be flexible enough to maintain it, to secure backward compatibility of it and to adapt it the future. By your logic you would include every possible mailer, editor, scripting tool, daemon and what not in the source tree "just to be flexible for all seasons". I think it's clear that we have in our source tree only those tools (and configuration of those tools) that make up a basic FreeBSD system. Additional cross-compilation tools are best be added to the ports collection (IMO of course). > I can easily cross-build FreeBSD sources targeted to NetBSD/m68k/aout > the way I build the compiler. And I can cross-build non-FreeBSD sources > targeted at LynxOS/PowerPC or NT/i386. The binutils makefiles in the > tree already support that. Extending them to other architectures is > trivial. I want the compiler build to be the same way. There is very > little bloat (just a few more makefiles) for those who only want to > build. Your argument applies just as well for the ports collection, with the addition that the ports collection is way more flexible than the source tree! > I want to see FreeBSD become a serious contender as a development > platform (preferably out of the box). It already is. Adding cross-compilation tools in the source tree *prevents* cross-compilation tools to be added at installation time. You always have to install the sources and make your own cross-compiler before you can use it. That's not out of the box! Out of the box is saying at installation time (FreeBSD's that is) that you want compiler this-for-that, gas foo-for-bar and so on and so forth. The installer installs the packages (!!!!) and you're up and running. That's out of the box!!!! Hell, you can even add the includes and libraries for a specific platform to the ports collection and have it installed at the same time. That way you have a fully *useful* cross-compilation toolset that allows you to make NT binaries immediately after installation of FreeBSD. What more do you want? > > My suggestion is this: > > Let's talk cross-building first and fix our make world. When release 4.0 > > is out we have the time and the (inner) peace to discuss how we think we > > should help developers that eat cross-compilers for breakfast :-) > > I think we can do both at the same time. I don't think that's wise. We clearly have conflicting opinions on the matter of how and where to provide cross-compilation toolsets. I want to postpone that discussion until after we have secured our upgrade path. > We seem to disagree on the mechanics of how we should drive a cross-build. > _I_ think we should use MACHINE and MACHINE_ARCH which are set in make(1) > as a convenience for host builds, but can be overridden for cross-builds. I do to (now). I first introduced TARGET_ARCH for fundamental reasons. After implementing it, I found out that I was only changing A for B without solving a problem. I therefore abandoned the use of TARGET_ARCH as a replacement for MACHINE_ARCH in all makefiles. I want to reintroduce TARGET_ARCH with an entirely different function and meaning: What output should our compiler toolset generate. > They are not there for any other make function AFAIK. I agree that the > make(1) man page doesn't support this, but I think that is just a few > paragraphs of documentation that can be "fixed" (or changed to suit the > new world order). The manpage does not describe how the source actually works, therefore it should be updated. You can override MACHINE and MACHINE_ARCH; make allows that. Therefore, I agree. > What I _don't_ want to see is gcc trying to interpret MACHINE_ARCH > or TARGET_ARCH or somehow trying to "discover" that it is cross-compiling. > I think we can just do what Cygnus does and build a dedicated version > of gcc for each target. Instead of duplicating subtrees I will use a single variable to handle that. That variable is going to be TARGET_ARCH. We are telling our compiler toolset what it should generate. Whether that is to be considered cross-compilation, depends on the system the compiler is going to run on eventually. The former will be denoted by TARGET_ARCH, the latter by MACHINE_ARCH. We're building a cross-compiler is TARGET_ARCH != MACHINE_ARCH. This is all it needs. Clean, simple and very intuitive. > I also don't want to see make(1) customized. I would like to ask that > we use the version of make from 2.2.5 (or whenever the -m switch was > first implemented) as the reference. If we can't do a cross-build with > an old version of make like that, then we're doing something wrong. Who said anything about customizing make(1). I get the impression you just don't (want to) know what I'm actually trying say? Do you actually understand me? > At work I have to live with GNU make because of portability issues > across Solaris, NT, Linux and FreeBSD. I'm tempted to suggest that we > drop BSD make in favour of gmake. I bet a suggestion like that will > wake people up. 8-) I'm only half joking. John, I think I understand your situation, at least I hope I do. Your personal situation is just what it is: your personal situation. I must admit, it really sound like a sub-optimal, hard-to-deal-with, bloody-irritating and not-so-pleasant-at-all kind of situation. But (you felt it coming :-), I don't think your situation is important enough to others and FreeBSD at large that we should adopt FreeBSD to it. The best thing we can do (IMO) is make your life easier by making ports of all those tools so that you (and others) can install (and deinstall) them with more ease than ever possible than if they were in the source tree. What I'm saying is this: Don't let your personal situation (frustration?) influence your good judgement. FOOTNOTE: This is all IMO or, IMHO given the last paragraph. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 18 9:22: 0 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0BF0415120 for ; Thu, 18 Nov 1999 09:21:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id SAA07836 for ; Thu, 18 Nov 1999 18:21:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA63741 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 18:21:53 +0100 (MET) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id D416215433 for ; Thu, 18 Nov 1999 09:21:26 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id KAA29564; Thu, 18 Nov 1999 10:20:41 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpdAAAh7aGL5; Thu Nov 18 10:20:32 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id KAA14611; Thu, 18 Nov 1999 10:20:47 -0700 (MST) From: Terry Lambert Message-Id: <199911181720.KAA14611@usr02.primenet.com> Subject: Re: Cross compilation goals. To: marcel@scc.nl (Marcel Moolenaar) Date: Thu, 18 Nov 1999 17:20:47 +0000 (GMT) Cc: arch@freebsd.org In-Reply-To: <3833C40B.EC5290CF@scc.nl> from "Marcel Moolenaar" at Nov 18, 99 10:16:59 am X-Mailer: ELM [version 2.4 PL25] 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 > My history of thoughts (in no particular order): > > The sigset_t changes revealed 2 problems: > 1) I wasn't able to at least compile any changes I made to the Alpha > port, because I didn't have an Alpha during that time, > 2) makeworld broke because the newly compiled tools were made against > the new sigset_t while the system wasn't using it yet. > > If we fix 1), then 2) is gone too, right? right! One non-obvious issue, until you try to compile the system with a different GCC or EGCS compiler than the default, is that the .mk files override the correct compiler defaults with incorrect system defaults for include and compiler library paths when DESTDIR is set. Obviously, you have to set this for a proper cross-compile. Another issue is that the GCC/EGCS code "front ending" is not very well integrated; you end up with huge amounts of installed headers, even if you are cross-compiling the same OS on another platform. 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 Nov 18 10:47:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9E62115569 for ; Thu, 18 Nov 1999 10:47:47 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA08534 for ; Thu, 18 Nov 1999 19:47:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA64139 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 19:47:45 +0100 (MET) Received: from post.mail.nl.demon.net (post-11.mail.nl.demon.net [194.159.73.21]) by hub.freebsd.org (Postfix) with ESMTP id 08B9615197 for ; Thu, 18 Nov 1999 10:33:59 -0800 (PST) (envelope-from marcel@scc.nl) Received: from [212.238.132.94] (helo=scones.sup.scc.nl) by post.mail.nl.demon.net with esmtp (Exim 2.12 #1) id 11oWNp-0008bq-00; Thu, 18 Nov 1999 18:34:13 +0000 Received: from scc.nl (scones.sup.scc.nl [192.168.2.4]) by scones.sup.scc.nl (8.9.3/8.9.3) with ESMTP id TAA91479; Thu, 18 Nov 1999 19:33:53 +0100 (CET) (envelope-from marcel@scc.nl) Message-ID: <38344691.BF54DAD@scc.nl> Date: Thu, 18 Nov 1999 19:33:53 +0100 From: Marcel Moolenaar Organization: SCC vof X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i386) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: arch@freebsd.org Subject: Re: Cross compilation goals. References: <199911181720.KAA14611@usr02.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > My history of thoughts (in no particular order): > > > > The sigset_t changes revealed 2 problems: > > 1) I wasn't able to at least compile any changes I made to the Alpha > > port, because I didn't have an Alpha during that time, > > 2) makeworld broke because the newly compiled tools were made against > > the new sigset_t while the system wasn't using it yet. > > > > If we fix 1), then 2) is gone too, right? right! > > One non-obvious issue, until you try to compile the system with a > different GCC or EGCS compiler than the default, is that the .mk > files override the correct compiler defaults with incorrect > system defaults for include and compiler library paths when > DESTDIR is set. Obviously, you have to set this for a proper > cross-compile. Correct. I don't like the overloading of DESTDIR, but if set properly during the different stages/phases of the cross-build, then there's no problem and "fixing" the oberloading would be too costly for the gain you'll get (been there, done that :-). We basicly have to create different environments for the different stages and keep the stages well divided. > Another issue is that the GCC/EGCS code "front ending" is not > very well integrated; you end up with huge amounts of installed > headers, even if you are cross-compiling the same OS on another > platform. I'm not sure I understand your point. Do you mean that installing the headers in the object-tree should be avoided if they are the same as the ones installed on the host? Or that different architectures can share the same set of headers? The first case probably takes as much time to detect as it takes to installing the headers. And the space saved is probably not worth all the trouble. The second case is not possible, so I assume you don't actually ment that :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 18 11:59:54 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 83F8115079 for ; Thu, 18 Nov 1999 11:59:42 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA09271 for ; Thu, 18 Nov 1999 20:59:39 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA64568 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 20:59:38 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id D7B6515688 for ; Thu, 18 Nov 1999 11:20:55 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id GAA23391; Fri, 19 Nov 1999 06:23:25 +1100 (EST) (envelope-from jb) Date: Fri, 19 Nov 1999 06:23:25 +1100 From: John Birrell To: Marcel Moolenaar Cc: John Birrell , arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991119062325.H13376@freebsd1.cimlogic.com.au> References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> <19991118212234.E13376@freebsd1.cimlogic.com.au> <3833EFE2.A6D975F2@scc.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <3833EFE2.A6D975F2@scc.nl>; from Marcel Moolenaar on Thu, Nov 18, 1999 at 01:24:02PM +0100 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 18, 1999 at 01:24:02PM +0100, Marcel Moolenaar wrote: > I don't understand you. You duplicate the entire /usr/src/gnu/usr.bin/cc > tree for each architecture you want to be able to build a cross-compiler > for and still claim you *avoid* bloat? It's only a very simple set of makefiles that are in separate directories so that an obj dir gets created when the code is built. > I don't think that's wise. We clearly have conflicting opinions on the > matter of how and where to provide cross-compilation toolsets. I want to > postpone that discussion until after we have secured our upgrade path. I'll come back next year then. > John, I think I understand your situation, at least I hope I do. Your > personal situation is just what it is: your personal situation. I must > admit, it really sound like a sub-optimal, hard-to-deal-with, > bloody-irritating and not-so-pleasant-at-all kind of situation. But (you > felt it coming :-), I don't think your situation is important enough to > others and FreeBSD at large that we should adopt FreeBSD to it. The best > thing we can do (IMO) is make your life easier by making ports of all > those tools so that you (and others) can install (and deinstall) them > with more ease than ever possible than if they were in the source tree. > What I'm saying is this: Don't let your personal situation > (frustration?) influence your good judgement. Sigh. Your mail is the first "resistance" I've had about doing this. It's not something that has just appeared over night. I can keep this stuff local, though. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 12: 4:37 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3FACD15487 for ; Thu, 18 Nov 1999 12:04:29 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id VAA09336 for ; Thu, 18 Nov 1999 21:04:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA64649 for freebsd-arch@freebsd.org; Thu, 18 Nov 1999 21:04:23 +0100 (MET) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id A83C115532 for ; Thu, 18 Nov 1999 11:32:53 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id GAA23348; Fri, 19 Nov 1999 06:12:54 +1100 (EST) (envelope-from jb) Date: Fri, 19 Nov 1999 06:12:54 +1100 From: John Birrell To: Simon Shapiro Cc: John Birrell , Marcel Moolenaar , arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991119061254.G13376@freebsd1.cimlogic.com.au> References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> <19991118212234.E13376@freebsd1.cimlogic.com.au> <3833EE19.A7DC5935@simon-shapiro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <3833EE19.A7DC5935@simon-shapiro.org>; from Simon Shapiro on Thu, Nov 18, 1999 at 07:16:25AM -0500 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 18, 1999 at 07:16:25AM -0500, Simon Shapiro wrote: > > At work I have to live with GNU make because of portability issues > > across Solaris, NT, Linux and FreeBSD. I'm tempted to suggest that we > > drop BSD make in favour of gmake. I bet a suggestion like that will > > wake people up. 8-) I'm only half joking. > > Why not? Does it work? Can it execute our current makefiles > correctly? I know ours make cannot run many for-gnu makefiles. All the wizardry in the FreeBSD makefiles is BSD make specific. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ john.birrell@cai.com john.birrell@opendirectory.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 15:34:19 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0E63A1554B for ; Thu, 18 Nov 1999 15:34:16 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11456 for ; Fri, 19 Nov 1999 00:34:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA65716 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 00:34:13 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 44BD215530 for ; Thu, 18 Nov 1999 15:34:05 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA12816; Thu, 18 Nov 1999 16:34:04 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA28822; Thu, 18 Nov 1999 16:34:29 -0700 (MST) Message-Id: <199911182334.QAA28822@harmony.village.org> To: Michael Schuster - TSC SunOS Germany Subject: Re: Cross compilation goals. Cc: arch@freebsd.org In-reply-to: Your message of "Thu, 18 Nov 1999 07:48:03 +0100." <3833A123.E390849A@germany.sun.com> References: <3833A123.E390849A@germany.sun.com> <19991117184034.A53402@dragon.nuxi.com> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> <199911180559.WAA21245@harmony.village.org> Date: Thu, 18 Nov 1999 16:34:29 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3833A123.E390849A@germany.sun.com> Michael Schuster - TSC SunOS Germany writes: : > : > 1) Have the cross compilation code necessarily work on other : > systems. : : what does that mean? : : in this context, what does "other system" mean? VMS, TOPS-20, Solaris, OpenBSD, NetBSD, Linux, DOS, Windows, IRIX, DG/UX, Tru64 or anything else that isn't FreeBSD. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Nov 18 15:48:21 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 80DF61554A for ; Thu, 18 Nov 1999 15:48:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id AAA11561 for ; Fri, 19 Nov 1999 00:48:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id AAA65785 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 00:48:18 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7EBAE1554A for ; Thu, 18 Nov 1999 15:47:52 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA12858 for ; Thu, 18 Nov 1999 16:47:51 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA28898 for ; Thu, 18 Nov 1999 16:48:21 -0700 (MST) Message-Id: <199911182348.QAA28898@harmony.village.org> To: arch@freebsd.org Subject: Re: Cross compilation goals. In-reply-to: Your message of "Thu, 18 Nov 1999 16:34:29 MST." <199911182334.QAA28822@harmony.village.org> References: <199911182334.QAA28822@harmony.village.org> <3833A123.E390849A@germany.sun.com> <19991117184034.A53402@dragon.nuxi.com> <199911151707.JAA03820@freefall.freebsd.org> <199911160533.WAA02391@harmony.village.org> <199911180559.WAA21245@harmony.village.org> Date: Thu, 18 Nov 1999 16:48:21 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199911182334.QAA28822@harmony.village.org> Warner Losh writes: : In message <3833A123.E390849A@germany.sun.com> Michael Schuster - TSC SunOS Germany writes: : : > : : > 1) Have the cross compilation code necessarily work on other : : > systems. : : : : what does that mean? : : : : in this context, what does "other system" mean? : : VMS, TOPS-20, Solaris, OpenBSD, NetBSD, Linux, DOS, Windows, IRIX, : DG/UX, Tru64 or anything else that isn't FreeBSD. I've just read the rest of the thread, and need to amplify the non goal and state it as follows: 1) It will not necessarily be a goal of this effort to produce a FreeBSD source tree that can be compiled on a non-FreeBSD system. You will not necessarily be able to build a FreeBSD system on a Solaris system, for example. I'd like to add the following non-goal for the current effort: 2) It will not necessarily be a goal of this effort to produce binaries for Non-FreeBSD systems on a FreeBSD system. I agree with Marcel that the current set of goals is to make cross-building work rather than the more generic and slightly different cross-compilation problem. Don't get me wrong. In the long term world, I'd love to see the ability to make binaries for other systems (within reason) in FreeBSD, but I'm not sure that is a current goal given our time horizons. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 19 1:45:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2F19D15209 for ; Fri, 19 Nov 1999 01:45:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA18813 for ; Fri, 19 Nov 1999 10:45:13 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA00234 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 10:45:11 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id AAB2F15624 for ; Fri, 19 Nov 1999 01:33:39 -0800 (PST) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (root@d60-025.leach.ucdavis.edu [169.237.60.25]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id BAA12580 for ; Fri, 19 Nov 1999 01:33:39 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id BAA81520 for arch@freebsd.org; Fri, 19 Nov 1999 01:33:39 -0800 (PST) (envelope-from obrien) Date: Fri, 19 Nov 1999 01:33:39 -0800 From: "David O'Brien" To: arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991119013339.F81410@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <19991117184034.A53402@dragon.nuxi.com>, <199911180559.WAA21245@harmony.village.org> <3833C40B.EC5290CF@scc.nl> <19991118212234.E13376@freebsd1.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <19991118212234.E13376@freebsd1.cimlogic.com.au>; from jb@cimlogic.com.au on Thu, Nov 18, 1999 at 09:22:34PM +1100 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Nov 18, 1999 at 09:22:34PM +1100, John Birrell wrote: > What I _don't_ want to see is gcc trying to interpret MACHINE_ARCH > or TARGET_ARCH or somehow trying to "discover" that it is cross-compiling. By `gcc' you mean the compiler, or the driver proper? -- -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Nov 19 1:56:27 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 8B5C2155A0 for ; Fri, 19 Nov 1999 01:56:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id KAA19000 for ; Fri, 19 Nov 1999 10:56:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id KAA00283 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 10:56:22 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id BA5B4155A0 for ; Fri, 19 Nov 1999 01:56:11 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id KAA55556 for arch@FreeBSD.org; Fri, 19 Nov 1999 10:29:30 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Fri, 19 Nov 1999 10:29:26 +0100 From: Marcel Moolenaar Message-ID: <38351876.A80D5EA7@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <199911182334.QAA28822@harmony.village.org>, <199911182348.QAA28898@harmony.village.org> Subject: Re: Cross compilation goals. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > Don't get me wrong. In the long term world, I'd love to see the > ability to make binaries for other systems (within reason) in FreeBSD, > but I'm not sure that is a current goal given our time horizons. yeah Although John and I differ in the hows and wheres, we *do* agree on the ability to do it. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 19 2:26:59 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E4F6214F5A for ; Fri, 19 Nov 1999 02:26:48 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id LAA19531 for ; Fri, 19 Nov 1999 11:26:48 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA00402 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 11:26:47 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id E043A1564F for ; Fri, 19 Nov 1999 02:26:11 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id LAA68492 for arch@FreeBSD.org; Fri, 19 Nov 1999 11:21:15 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Fri, 19 Nov 1999 11:21:10 +0100 From: Marcel Moolenaar Message-ID: <38352496.75EBBAEE@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <19991117184034.A53402@dragon.nuxi.com>, <19991119013339.F81410@dragon.nuxi.com> Subject: Re: Cross compilation goals. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Thu, Nov 18, 1999 at 09:22:34PM +1100, John Birrell wrote: > > What I _don't_ want to see is gcc trying to interpret MACHINE_ARCH > > or TARGET_ARCH or somehow trying to "discover" that it is cross-compiling. > > By `gcc' you mean the compiler, or the driver proper? gcc (both in the sense of compiler and driver proper) doesn't try to figure out if it is a cross-compiler or not. It's a compile-time parameter that determines how the compiler (the one that's being built) should behave when it is executed. In this sense it's only important for the Makefiles to know or figure out whether or not the compiler (the one that's being built) is to be a cross-compiler or not. A running compiler *knows* if it's a cross-compiler or not, because it was told so during compilation (of said compiler). -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 19 13:17:16 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C62C14F3C for ; Fri, 19 Nov 1999 13:17:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id WAA27888 for ; Fri, 19 Nov 1999 22:16:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA02890 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 22:16:57 +0100 (MET) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id C2C9214F3C for ; Fri, 19 Nov 1999 13:15:58 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id NAA15768 for freebsd-arch@freebsd.org; Fri, 19 Nov 1999 13:15:56 -0800 (PST) (envelope-from obrien) Date: Fri, 19 Nov 1999 13:15:56 -0800 From: "David O'Brien" To: freebsd-arch@freebsd.org Subject: Re: Cross compilation goals. Message-ID: <19991119131556.B15131@relay.nuxi.com> Reply-To: obrien@NUXI.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i X-Operating-System: FreeBSD 3.3-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got this off a GCC mailing list. I would prefer that we stick with these definitions. -- David ----- Forwarded message No there are actually three separate terms regarding three separate machines. 1. The "target" system is the platform gcc will generate code for. 2. The "build" system is the platform where you compile gcc. 3. The "host" system is the platform where gcc executes. When you build a regular cross compiler, the target is different but host==build. When you build a cross compiler *using* a cross compiler, (also known as a canadian-cross compile) then all three are different. ----- 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 Sat Nov 20 5: 3:15 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 4F5CB14CD3 for ; Sat, 20 Nov 1999 05:01:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id OAA15869 for ; Sat, 20 Nov 1999 14:00:19 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA08551 for freebsd-arch@freebsd.org; Sat, 20 Nov 1999 14:00:19 +0100 (MET) Received: from mail.scc.nl (node1374.a2000.nl [62.108.19.116]) by hub.freebsd.org (Postfix) with ESMTP id 68F0C14DCB for ; Sat, 20 Nov 1999 01:26:15 -0800 (PST) (envelope-from freebsd-arch@scc.nl) Received: (from daemon@localhost) by mail.scc.nl (8.9.3/8.9.3) id KAA08914 for arch@FreeBSD.org; Sat, 20 Nov 1999 10:15:05 +0100 (CET) (envelope-from freebsd-arch@scc.nl) Received: from GATEWAY by dwarf.hq.scc.nl with netnews for arch@FreeBSD.org (arch@FreeBSD.org) To: arch@freebsd.org Date: Sat, 20 Nov 1999 10:15:00 +0100 From: Marcel Moolenaar Message-ID: <38366694.EDD5568F@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <19991119131556.B15131@relay.nuxi.com> Subject: Re: Cross compilation goals. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > I got this off a GCC mailing list. I would prefer that we stick with > these definitions. > > 1. The "target" system is the platform gcc will generate code for. > 2. The "build" system is the platform where you compile gcc. > 3. The "host" system is the platform where gcc executes. > I already want to use TARGET_ARCH for "target". We have MACHINE_ARCH that describes "host", but don't actually have a variable for "build", other than `sysctl -n hw.machine_arch`. Changing MACHINE_ARCH to HOST_ARCH would be too much of an impact, so I don't think we should do that. We could create a BUILD_ARCH for convenience. I don't think there's a place where we actually need to know the build system, though. In discussions these definitions can come handy... -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@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 Nov 20 18:24:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 03DDE1576E for ; Sat, 20 Nov 1999 18:24:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA22209 for ; Sun, 21 Nov 1999 03:24:01 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA11672 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 03:23:59 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 4A1E91577C; Sat, 20 Nov 1999 18:22:06 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA33286; Sat, 20 Nov 1999 18:21:56 -0800 (PST) Date: Sat, 20 Nov 1999 18:21:56 -0800 (PST) From: Julian Elischer To: Matthew Jacob Cc: "Jordan K. Hubbard" , committers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Core responsibilities [was Re: PHK: "Shut up and go away quietly"] 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 Sat, 20 Nov 1999, Matthew Jacob wrote: > > Actually, to be fair about this, Julian *did* announce to all and sundry > that there would be a discussion about threads. I lurked and followed it > from a distance throughout the week or so it was active. Since it didn't > really touch that much on kernel threads, I didn't have a great amount of > interest in leaping in (the last time I did user level thread work was in > helping Nawaf polish off/disagree with some Posix stuff multi years ago > wrt signal handling). > > It did seem that the discussion was productive, but since it wasn't really > my table, I didn't get involved. Now, if there's some talk about kernel > threads, or more precisely, how a fully threaded kernel will need changes > to the device I/O model, then I'm more interested. That's peculiar because teh first week was just discussing the goals. from there we got to the fact that we need the following kernel support. 1/ KSE's (kernel schedulable Entities that are separate from processes). 2/ SUB-processes. (each with ONE OR MORE KSEs) 3/ Processes (each with one or more Sub processes) 4/ A second call-gate to implement the syscalls that are changed 5/ A different syscall protocol (using #4) to implement the fact that all IO becomes Async in a thread setting, and to return control to the (User level) Thread Scheduler (UTS) when a KSE blocks. 6/ A manner of returnig to the UTS after the subprocess is rescheduled after a process preemption rather than returning to the thread that was pre-empted. 7/ A method for treating a pagefault as a blocking IO and returning to the UTS when a thread get's a pagefault. 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. 8/ A method of delivering a signal to the UTS rathe than to any randomly running thread, and letting it decide which thread should handle it. (7 and 8 are related) The discussion has basically stopped the last 6 days as everyone has been busy but I was getting ready to post some stuff tonight. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 18:35: 8 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E607D14F20 for ; Sat, 20 Nov 1999 18:34:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA22277 for ; Sun, 21 Nov 1999 03:34:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA11720 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 03:34:53 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id ADD2914F20; Sat, 20 Nov 1999 18:34:46 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id SAA23969; Sat, 20 Nov 1999 18:35:23 -0800 Date: Sat, 20 Nov 1999 18:35:23 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Julian Elischer Cc: "Jordan K. Hubbard" , committers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Core responsibilities [was Re: PHK: "Shut up and go away quietly"] 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 > > It did seem that the discussion was productive, but since it wasn't really > > my table, I didn't get involved. Now, if there's some talk about kernel > > threads, or more precisely, how a fully threaded kernel will need changes > > to the device I/O model, then I'm more interested. > > That's peculiar because teh first week was just discussing the goals. > from there we got to the fact that we need the following kernel > support. > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > 2/ SUB-processes. (each with ONE OR MORE KSEs) > 3/ Processes (each with one or more Sub processes) > 4/ A second call-gate to implement the syscalls that are changed > 5/ A different syscall protocol (using #4) to implement the fact that all > IO becomes Async in a thread setting, and to return control to the > (User level) Thread Scheduler (UTS) when a KSE blocks. > 6/ A manner of returnig to the UTS after the subprocess is rescheduled > after a process preemption rather than returning to the thread that was > pre-empted. > 7/ A method for treating a pagefault as a blocking IO and returning to the > UTS when a thread get's a pagefault. > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > 8/ A method of delivering a signal to the UTS rathe than to any randomly > running thread, and letting it decide which thread should handle it. > (7 and 8 are related) Sure- that's kernel stuff, but it doesn't really work much in the area I would be interested, namely making interrupt and other kernel threads (e.g., for CAM device inventory management) for all drivers that could use them (an interrupt thread per interrupt entry point is not unreasonable), replacing all spl type locking with mutex_init (based on device interrupt levels) and mutex_enter/mutex_exit usages, perhaps replacing sleep/wakeup which is a per-process thingie with cv_wait/cv_signal.. you know, that kinda low level kernel I/O stuff- more nuts and bolts and less theoretical. When the discussion gets around to these things and policies about whether SMP safe and SMP-unsafe drivers can coexist, then I'll be more than happy to waste everyone's time with my opinions. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 18:50:33 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 460B615194 for ; Sat, 20 Nov 1999 18:50:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id DAA22368 for ; Sun, 21 Nov 1999 03:50:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA11776 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 03:50:30 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id C6DB81518F for ; Sat, 20 Nov 1999 18:50:24 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id SAA34073 for ; Sat, 20 Nov 1999 18:50:24 -0800 (PST) Date: Sat, 20 Nov 1999 18:50:24 -0800 (PST) From: Julian Elischer To: freebsd-arch@freebsd.org Subject: Thread summary.. needs? 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 I just summarised elsewhere so I'm repeating here.. On Sat, 20 Nov 1999, Matthew Jacob wrote: > > Actually, to be fair about this, Julian *did* announce to all and sundry > that there would be a discussion about threads. I lurked and followed it > from a distance throughout the week or so it was active. Since it didn't > really touch that much on kernel threads, I didn't have a great amount of > interest in leaping in (the last time I did user level thread work was in > helping Nawaf polish off/disagree with some Posix stuff multi years ago > wrt signal handling). > > It did seem that the discussion was productive, but since it wasn't really > my table, I didn't get involved. Now, if there's some talk about kernel > threads, or more precisely, how a fully threaded kernel will need changes > to the device I/O model, then I'm more interested. That's peculiar because teh first week was just discussing the goals. from there we got to the fact that we need the following kernel support. 1/ KSE's (kernel schedulable Entities that are separate from processes). 2/ SUB-processes. (each with ONE OR MORE KSEs) 3/ Processes (each with one or more Sub processes) 4/ A second call-gate to implement the syscalls that are changed 5/ A different syscall protocol (using #4) to implement the fact that all IO becomes Async in a thread setting, and to return control to the (User level) Thread Scheduler (UTS) when a KSE blocks. 6/ A manner of returnig to the UTS after the subprocess is rescheduled after a process preemption rather than returning to the thread that was pre-empted. 7/ A method for treating a pagefault as a blocking IO and returning to the UTS when a thread get's a pagefault. 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. 8/ A method of delivering a signal to the UTS rathe than to any randomly running thread, and letting it decide which thread should handle it. (7 and 8 are related) The discussion has basically stopped the last 6 days as everyone has been busy but I was getting ready to post some stuff tonight. -------------------- more added--------------- Basically I see some basic work being needed so we can start this.. 1/ separation of struct proc into (at least) 2 parts. one ofr the KSE and one for the proc. thoud there be a separation between the prc and hte sub-proc? remember the subproc is the guy that has the priorities and KSE's are scheduled according to which sub-proc they are attached to. (I'm starting to to wonder if we don't need 3 separate structs, thogh maybe all subprocs are also procs). 2/ we need to allocate ourselves a new call gate so that we can start experimenting with the syscall protocol we will need to implement. 3/ A KSE allocator that caches KSEs to speed up allocation would be good. This should fit togehter with whatever the people are doing on real 'kernel internal threads' and SMP. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 19: 3:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7B61514E92 for ; Sat, 20 Nov 1999 19:03:23 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA22489 for ; Sun, 21 Nov 1999 04:03:22 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA11854 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 04:03:22 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 7515014E92 for ; Sat, 20 Nov 1999 19:03:16 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA34414; Sat, 20 Nov 1999 19:03:13 -0800 (PST) Date: Sat, 20 Nov 1999 19:03:13 -0800 (PST) From: Julian Elischer To: Matthew Jacob Cc: freebsd-arch@freebsd.org Subject: Threads stuff 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 Sat, 20 Nov 1999, Matthew Jacob wrote: > > Sure- that's kernel stuff, but it doesn't really work much in the area I > would be interested, namely making interrupt and other kernel threads > (e.g., for CAM device inventory management) for all drivers that could use > them (an interrupt thread per interrupt entry point is not unreasonable), > replacing all spl type locking with mutex_init (based on device interrupt > levels) and mutex_enter/mutex_exit usages, perhaps replacing sleep/wakeup > which is a per-process thingie with cv_wait/cv_signal.. you know, that > kinda low level kernel I/O stuff- more nuts and bolts and less > theoretical. When the discussion gets around to these things and policies > about whether SMP safe and SMP-unsafe drivers can coexist, then I'll be > more than happy to waste everyone's time with my opinions. But it's all inter-related.. The KSE allocator would be the same KSE allocator that would be used to innitially allocate KSEs for interrupt handling. (My secret agenda starts to show). My aim is to get the BSDI "lazily evaluated threads" interrupt scheme. however the threads they would be evaluating to would be the same KSEs that would be allocated to the User thread scheme.. "A thread is a thread is a thread" Believe me my heart is in the "low level more nuts and bolts". I just see a convergence of needs here. We certainly need someone to help with the KSEs and specifically the Mutexy stuff. That should be quite applicable to both ends.. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 19: 5:22 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id DC40214E48 for ; Sat, 20 Nov 1999 19:05:19 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA22520 for ; Sun, 21 Nov 1999 04:05:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA11884 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 04:05:18 +0100 (MET) Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E56EB158A9 for ; Sat, 20 Nov 1999 19:05:09 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id TAA24098; Sat, 20 Nov 1999 19:05:51 -0800 Date: Sat, 20 Nov 1999 19:05:51 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads stuff 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 > > > > Sure- that's kernel stuff, but it doesn't really work much in the area I > > would be interested, namely making interrupt and other kernel threads > > (e.g., for CAM device inventory management) for all drivers that could use > > them (an interrupt thread per interrupt entry point is not unreasonable), > > replacing all spl type locking with mutex_init (based on device interrupt > > levels) and mutex_enter/mutex_exit usages, perhaps replacing sleep/wakeup > > which is a per-process thingie with cv_wait/cv_signal.. you know, that > > kinda low level kernel I/O stuff- more nuts and bolts and less > > theoretical. When the discussion gets around to these things and policies > > about whether SMP safe and SMP-unsafe drivers can coexist, then I'll be > > more than happy to waste everyone's time with my opinions. > > But it's all inter-related.. The KSE allocator would be the same > KSE allocator that would be used to innitially allocate KSEs for > interrupt handling. (My secret agenda starts to show). My aim is to > get the BSDI "lazily evaluated threads" interrupt scheme. however the > threads they would be evaluating to would be the same KSEs that would > be allocated to the User thread scheme.. > > "A thread is a thread is a thread" > > Believe me my heart is in the "low level more nuts and bolts". I just see > a convergence of needs here. > > We certainly need someone to help with the KSEs and specifically the Mutexy > stuff. That should be quite applicable to both ends.. Okay. I'll start to pay more attention. Sorry if I was OTL.... -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 19:24:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 11B5914C19 for ; Sat, 20 Nov 1999 19:24:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA22672 for ; Sun, 21 Nov 1999 04:24:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA11972 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 04:24:54 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id EEA1014C19 for ; Sat, 20 Nov 1999 19:24:41 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA34989; Sat, 20 Nov 1999 19:24:29 -0800 (PST) Date: Sat, 20 Nov 1999 19:24:29 -0800 (PST) From: Julian Elischer To: Jason Evans Cc: David Greenman , Nate Williams , freebsd-arch@freebsd.org Subject: Re: Core responsibilities [was Re: PHK: "Shut up and go away quietly"] In-Reply-To: <19991120190750.D11515@sturm.canonware.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 I wonder if we can try a new development scheme? You have amandate to do almost anythign to make threads work.. there are a lot of people who would like to help you work on this.. Even a full time job doesn't give enough time for doing this all on your own completely in isolation. How about if you coem on as "main threads guy and thread team leader"? Take over the discussion lead, and I know I'd be willing to take on specific tasks.. e.g. "split the proc struct into proc and thread parts" "get us a new call-gate for the threaded syscalls" "make a skelaton in the sources to compile a version of libc-R using the new callgate" "Fix PS to show all threads and not just the main one" "fix /proc for the new world" etc.etc. there are lots of people who know how to do these bits And tehy will hapily do these thongs and feed you back patches if you can use you new 'Thread-czar' position to organise it. Julian On Sat, 20 Nov 1999, Jason Evans wrote: > On Sat, Nov 20, 1999 at 04:11:19PM -0800, Julian Elischer wrote: > > On Sat, 20 Nov 1999, David Greenman wrote: > > > > > >What are we going to do with kernel threads? None of the core members > > > >have yet to respond?. > > > > > > Walnut Creek CDROM just hired Jason Evans to work on it. > > > > Since we've been having a threads "what do we do next" discussion on -arch > > (or trying) doesn't it seem like a good idea that someone would MENTION > > this fact to us? Especially as we have a design partly thrashed out in > > our minds and have started experimenting with ideas! > > I start at Walnut Creek on Monday, and had every intention of making that > known on Monday. As for Jordan's announcement, I somehow missed it too. =) > > > Is there any small chance that Jason Evans will take part in and not just > > over-ride the work that has already been going on? > > As for the threads discussion on -arch, I've been following the discussion > *very* closely. No, I won't over-ride what has happened so far; I am in > total agreement with almost all of the points that have been hashed out > thus far. Walnut Creek CDROM's (and my) motivation is simply to have > someone who can concentrate full time on moving threads forward in > FreeBSD. > > Jason > > Jason Evans > http://www.canonware.com/~jasone > Home phone: (650) 856-8204 > "I once knew a happy medium. Her name was Zohar." - James Foster > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 19:32:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D7E9814C19 for ; Sat, 20 Nov 1999 19:32:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id EAA22729 for ; Sun, 21 Nov 1999 04:32:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA12008 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 04:32:36 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9B73B14EBE for ; Sat, 20 Nov 1999 19:32:30 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id TAA35233; Sat, 20 Nov 1999 19:32:22 -0800 (PST) Date: Sat, 20 Nov 1999 19:32:22 -0800 (PST) From: Julian Elischer To: Jason Evans Cc: David Greenman , Nate Williams , freebsd-arch@freebsd.org Subject: Re: Core responsibilities [was Re: PHK: "Shut up and go away quietly"] 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 I gotta learn to type.. On Sat, 20 Nov 1999, Julian Elischer wrote: > I wonder if we can try a new development scheme? > You have amandate to do almost anythign to make threads work.. a mandate ng > there are a lot of people who would like to help you work on this.. > Even a full time job doesn't give enough time for doing this all on your > own completely in isolation. > > How about if you coem on as "main threads guy and thread team leader"? come > Take over the discussion lead, and I know I'd be willing to take on > specific tasks.. e.g. "split the proc struct into proc and thread parts" > "get us a new call-gate for the threaded syscalls" "make a skelaton in the skeleton > sources to compile a version of libc-R using the new callgate" > > "Fix PS to show all threads and not just the main one" > "fix /proc for the new world" > etc.etc. > > there are lots of people who know how to do these bits > And tehy will hapily do these thongs and feed you back patches they happily things > if you can use you new 'Thread-czar' position to organise it. > > Julian > Of course the first thing we ned to do is get on with the basic design. As we do so somethings will become obviously needed.. e.g I'm thinking of trying to do the proc/thread bit tonight just for fun. (of course ps will barf :-) > > > On Sat, 20 Nov 1999, Jason Evans wrote: > > > On Sat, Nov 20, 1999 at 04:11:19PM -0800, Julian Elischer wrote: > > > On Sat, 20 Nov 1999, David Greenman wrote: > > > > > > > >What are we going to do with kernel threads? None of the core members > > > > >have yet to respond?. > > > > > > > > Walnut Creek CDROM just hired Jason Evans to work on it. > > > > > > Since we've been having a threads "what do we do next" discussion on -arch > > > (or trying) doesn't it seem like a good idea that someone would MENTION > > > this fact to us? Especially as we have a design partly thrashed out in > > > our minds and have started experimenting with ideas! > > > > I start at Walnut Creek on Monday, and had every intention of making that > > known on Monday. As for Jordan's announcement, I somehow missed it too. =) > > > > > Is there any small chance that Jason Evans will take part in and not just > > > over-ride the work that has already been going on? > > > > As for the threads discussion on -arch, I've been following the discussion > > *very* closely. No, I won't over-ride what has happened so far; I am in > > total agreement with almost all of the points that have been hashed out > > thus far. Walnut Creek CDROM's (and my) motivation is simply to have > > someone who can concentrate full time on moving threads forward in > > FreeBSD. > > > > Jason > > > > Jason Evans > > http://www.canonware.com/~jasone > > Home phone: (650) 856-8204 > > "I once knew a happy medium. Her name was Zohar." - James Foster > > > > > > > > > > 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 Sat Nov 20 20:13:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 16B0E14E48 for ; Sat, 20 Nov 1999 20:13:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA22962 for ; Sun, 21 Nov 1999 05:13:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12103 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 05:13:52 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0D9E114E48 for ; Sat, 20 Nov 1999 20:13:39 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt25.pcnet.net [206.105.29.99]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id XAA01952; Sat, 20 Nov 1999 23:13:39 -0500 (EST) Message-ID: <3837715C.A8222F4@vigrid.com> Date: Sat, 20 Nov 1999 23:13:16 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > 2/ SUB-processes. (each with ONE OR MORE KSEs) > 3/ Processes (each with one or more Sub processes) > 4/ A second call-gate to implement the syscalls that are changed > 5/ A different syscall protocol (using #4) to implement the fact that all > IO becomes Async in a thread setting, and to return control to the > (User level) Thread Scheduler (UTS) when a KSE blocks. I'd still like to know why we need another syscall gate in order to do this. From the sounds of it, you are envisioning having two implementations of every syscall, one for non-MT and one for MT. Or is it more because MT enabled system calls (internally) will need different arguments (struct proc p, struct thread t, whatever)? > 6/ A manner of returnig to the UTS after the subprocess is rescheduled > after a process preemption rather than returning to the thread that was > pre-empted. > 7/ A method for treating a pagefault as a blocking IO and returning to the > UTS when a thread get's a pagefault. > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > 8/ A method of delivering a signal to the UTS rathe than to any randomly > running thread, and letting it decide which thread should handle it. > (7 and 8 are related) How about an approach similar to Solaris? Deliver the signal to either a special KSE/thread that acts as a proxy for the other threads? Or even use an activation to notify the UTS of signals. From the UTS point of view, notification through an activation might be simpler since we already have to handle them (activations). Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 20:31:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0B86E15747 for ; Sat, 20 Nov 1999 20:31:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA23092 for ; Sun, 21 Nov 1999 05:31:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12172 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 05:31:06 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 9C0A415747 for ; Sat, 20 Nov 1999 20:30:55 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id UAA36764; Sat, 20 Nov 1999 20:30:52 -0800 (PST) Date: Sat, 20 Nov 1999 20:30:52 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <3837715C.A8222F4@vigrid.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 y On Sat, 20 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > > 2/ SUB-processes. (each with ONE OR MORE KSEs) > > 3/ Processes (each with one or more Sub processes) > > 4/ A second call-gate to implement the syscalls that are changed > > 5/ A different syscall protocol (using #4) to implement the fact that all > > IO becomes Async in a thread setting, and to return control to the > > (User level) Thread Scheduler (UTS) when a KSE blocks. > > I'd still like to know why we need another syscall gate in order > to do this. From the sounds of it, you are envisioning having two > implementations of every syscall, one for non-MT and one for MT. > Or is it more because MT enabled system calls (internally) will > need different arguments (struct proc p, struct thread t, whatever)? THe return value system for MT syscalls is by necessity differnt from non MT ones, and we need to continue to support old binaries. therefore by deduction, either a new syscall gate, or each syscall needs to be somehow aware as to how it was called. teh new call gate is the simplest way, and even allows intermixing of the new and old calls. New calls must be able to return and say "hey it's not me returnuing, but actually a new KSE, " (just one example of how they must be different) If it tuns out we think of somw really sneaky wayt of doing it so that they are compatible with old code, then we can always remove it, but I think I'd rather be absolutly certain that code calling a new version syscall knows what to do with the return values I return, and using a new syscall gate gives me that. > > > 6/ A manner of returnig to the UTS after the subprocess is rescheduled > > after a process preemption rather than returning to the thread that was > > pre-empted. > > 7/ A method for treating a pagefault as a blocking IO and returning to the > > UTS when a thread get's a pagefault. > > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > > 8/ A method of delivering a signal to the UTS rathe than to any randomly > > running thread, and letting it decide which thread should handle it. > > (7 and 8 are related) > > How about an approach similar to Solaris? Deliver the signal to either a > special KSE/thread that acts as a proxy for the other threads? Or even > use an activation to notify the UTS of signals. From the UTS point of > view, notification through an activation might be simpler since we already > have to handle them (activations). > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 20:35:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D7B6A15747 for ; Sat, 20 Nov 1999 20:35:42 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA23123 for ; Sun, 21 Nov 1999 05:35:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12197 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 05:35:42 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 870FD15747 for ; Sat, 20 Nov 1999 20:35:32 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt25.pcnet.net [206.105.29.99]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id XAA04007; Sat, 20 Nov 1999 23:35:29 -0500 (EST) Message-ID: <38377677.7AF35412@vigrid.com> Date: Sat, 20 Nov 1999 23:35:03 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Matthew Jacob , freebsd-arch@freebsd.org Subject: Re: Threads stuff References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sat, 20 Nov 1999, Matthew Jacob wrote: > > > > Sure- that's kernel stuff, but it doesn't really work much in the area I > > would be interested, namely making interrupt and other kernel threads > > (e.g., for CAM device inventory management) for all drivers that could use > > them (an interrupt thread per interrupt entry point is not unreasonable), > > replacing all spl type locking with mutex_init (based on device interrupt > > levels) and mutex_enter/mutex_exit usages, perhaps replacing sleep/wakeup > > which is a per-process thingie with cv_wait/cv_signal.. you know, that > > kinda low level kernel I/O stuff- more nuts and bolts and less > > theoretical. When the discussion gets around to these things and policies > > about whether SMP safe and SMP-unsafe drivers can coexist, then I'll be > > more than happy to waste everyone's time with my opinions. > > But it's all inter-related.. The KSE allocator would be the same > KSE allocator that would be used to innitially allocate KSEs for > interrupt handling. (My secret agenda starts to show). My aim is to > get the BSDI "lazily evaluated threads" interrupt scheme. however the > threads they would be evaluating to would be the same KSEs that would > be allocated to the User thread scheme.. > > "A thread is a thread is a thread" > > Believe me my heart is in the "low level more nuts and bolts". I just see > a convergence of needs here. > > We certainly need someone to help with the KSEs and specifically the Mutexy > stuff. That should be quite applicable to both ends.. There's some good articles on locking too. Perhaps that should be another topic on -arch ;-) I agree with Matt and want to see mutex_enter, mutex_exit, cv_wait, cv_signal, etc, as opposed to sleep/wakeup. Count me in as wanting to help with "mutexy" stuff as well as threads. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 20:38:43 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 661CC15747 for ; Sat, 20 Nov 1999 20:38:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id FAA23142 for ; Sun, 21 Nov 1999 05:38:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12219 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 05:38:35 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BD50515747 for ; Sat, 20 Nov 1999 20:38:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id UAA36928; Sat, 20 Nov 1999 20:38:15 -0800 (PST) Date: Sat, 20 Nov 1999 20:38:15 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <3837715C.A8222F4@vigrid.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 Sat, 20 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > 7/ A method for treating a pagefault as a blocking IO and returning to the > > UTS when a thread get's a pagefault. > > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > > 8/ A method of delivering a signal to the UTS rathe than to any randomly > > running thread, and letting it decide which thread should handle it. > > (7 and 8 are related) > > How about an approach similar to Solaris? Deliver the signal to either a > special KSE/thread that acts as a proxy for the other threads? Or even > use an activation to notify the UTS of signals. From the UTS point of > view, notification through an activation might be simpler since we already > have to handle them (activations). We need to define EXACTLY what an activation means in our context. it's an upcall, but are all upcalls the result of a prior downcall, (or even a downcall that 'forked a new KSE')? how does an upcall know what to do whej it goes up? My suggested idea is that the UTS does a blocking syscall that notifies the kernel that it is now capable of receiving upcalls, and the kermnel duplicates that KSE and stack and returns on a new KSE. The UTS knows when it returns, to immediatly allocate a new stack and thread (probably already allocated and waiting before the downcall actually) and switches to the new stack (or maybe the downcall was already done on the new one in which case it restarts the old thread. In any case the thread that did teh downcall is teh nominated handler of async events. (?) > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21: 3:50 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id CBD8D14D62 for ; Sat, 20 Nov 1999 21:03:46 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23280 for ; Sun, 21 Nov 1999 06:03:45 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12292 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:03:45 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 790B115038 for ; Sat, 20 Nov 1999 21:03:32 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt24.pcnet.net [206.105.29.98]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id AAA07001; Sun, 21 Nov 1999 00:03:28 -0500 (EST) Message-ID: <38377D08.6A9AD714@vigrid.com> Date: Sun, 21 Nov 1999 00:03:04 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > THe return value system for MT syscalls is by necessity differnt from non > MT ones, and we need to continue to support old binaries. The return value isn't any different because it really doesn't return to the same context, but to the UTS in a different context :-) When the blocking system call is finally resumed, it returns in the same manner as it does in the non-MT case. > therefore by deduction, either a new syscall gate, or each syscall needs > to be somehow aware as to how it was called. teh new call gate is the > simplest way, and even allows intermixing of the new and old calls. > > New calls must be able to return and say > "hey it's not me returnuing, but actually a new KSE, " > > (just one example of how they must be different) > If it tuns out we think of somw really sneaky wayt of doing it so that > they are compatible with old code, > then we can always remove it, but I think I'd rather be absolutly certain > that code calling a new version syscall knows what to do with the return > values I return, and using a new syscall gate gives me that. I thought we could just put async notification hooks in sleep/wakeup, mi_switch, etc. I guess you could call this sneaky, but how else are you going to do it without changing most of the kernel source? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21:15:10 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id BA66814F2F for ; Sat, 20 Nov 1999 21:15:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23349 for ; Sun, 21 Nov 1999 06:15:04 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12325 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:15:03 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id CBF141575E for ; Sat, 20 Nov 1999 21:14:36 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id WAA01656; Sat, 20 Nov 1999 22:14:34 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA13707; Sat, 20 Nov 1999 22:14:33 -0700 Date: Sat, 20 Nov 1999 22:14:33 -0700 Message-Id: <199911210514.WAA13707@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: References: <3837715C.A8222F4@vigrid.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > > > 2/ SUB-processes. (each with ONE OR MORE KSEs) > > > 3/ Processes (each with one or more Sub processes) > > > 4/ A second call-gate to implement the syscalls that are changed > > > 5/ A different syscall protocol (using #4) to implement the fact that all > > > IO becomes Async in a thread setting, and to return control to the > > > (User level) Thread Scheduler (UTS) when a KSE blocks. > > > > I'd still like to know why we need another syscall gate in order > > to do this. From the sounds of it, you are envisioning having two > > implementations of every syscall, one for non-MT and one for MT. > > Or is it more because MT enabled system calls (internally) will > > need different arguments (struct proc p, struct thread t, whatever)? > > THe return value system for MT syscalls is by necessity differnt from non > MT ones, and we need to continue to support old binaries. > therefore by deduction, either a new syscall gate, or each syscall needs > to be somehow aware as to how it was called. teh new call gate is the > simplest way, and even allows intermixing of the new and old calls. > > New calls must be able to return and say > "hey it's not me returnuing, but actually a new KSE, " Not only that, but you need a way for it to be 'aborted' out and have it cleanup as it goes. I suspect that this will require re-writing a large number of syscalls with threading in mind, and leaving the 'old' calls in place will allow more flexibility as things change. I could envision the 'old' calls going away at some point as the new calls get completely fleshed out and tested, to be replaced with simple wrappers for the threaded calls. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21:24:56 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 0525D14DC8 for ; Sat, 20 Nov 1999 21:24:52 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23385 for ; Sun, 21 Nov 1999 06:24:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12343 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:24:51 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2AF7614DD3 for ; Sat, 20 Nov 1999 21:24:41 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt12.pcnet.net [206.105.29.86]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id AAA08704; Sun, 21 Nov 1999 00:22:16 -0500 (EST) Message-ID: <38378171.82BE24C3@vigrid.com> Date: Sun, 21 Nov 1999 00:21:53 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sat, 20 Nov 1999, Daniel M. Eischen wrote: > > How about an approach similar to Solaris? Deliver the signal to either a > > special KSE/thread that acts as a proxy for the other threads? Or even > > use an activation to notify the UTS of signals. From the UTS point of > > view, notification through an activation might be simpler since we already > > have to handle them (activations). > > We need to define EXACTLY what an activation means in our context. > it's an upcall, but are all upcalls the result of a prior downcall, (or > even a downcall that 'forked a new KSE')? how does an upcall know what to > do whej it goes up? I'd say that all upcalls are _not_ necessarily the result of a prior downcall. A subprocess that is preempted should force an upcall on the next available subprocess. I assume the UTS will install a set of upcall entry points to handle async notification events. We just need to define what events are passed between the UTS and the kernel. > My suggested idea is that the UTS does a blocking syscall > that notifies the kernel that it is now capable of receiving upcalls, > and the kermnel duplicates that KSE and stack and returns on a new > KSE. The UTS knows when it returns, to immediatly allocate a new stack > and thread (probably already allocated and waiting before the downcall > actually) and switches to the new stack (or maybe the downcall was > already done on the new one in which case it restarts the old thread. In > any case the thread that did teh downcall is teh nominated handler of > async events. That's OK, but why not use a ucontext passed in with a new system call? Make the UTS supply ucontexts (made with makecontext) for event notifications also. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21:24:57 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 081B614DD3 for ; Sat, 20 Nov 1999 21:24:54 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23390 for ; Sun, 21 Nov 1999 06:24:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12357 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:24:53 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3547914DC8 for ; Sat, 20 Nov 1999 21:20:47 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA38103; Sat, 20 Nov 1999 21:20:40 -0800 (PST) Date: Sat, 20 Nov 1999 21:20:40 -0800 (PST) From: Julian Elischer To: Sean Eric Fagan Cc: freebsd-arch@freebsd.org Subject: Re: Threads vs ps In-Reply-To: <199911210450.UAA23210@kithrup.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 Sat, 20 Nov 1999, Sean Eric Fagan wrote: > > Let me rephrase it... what, exactly, _is_ a process? To me, a process > is an individual, kernel-schedulable entity. > > As such, I would expect to have each (current-model) process-id be > analogous to a (future-model) thread-id. So a "process" in the > current model would be called a "thread group" in the new model. > > Something like that. > > >The registers are per thread, not per process, so you need eactly what you > >say below. > >> I could envision seeing /proc/pid/threads/{0,1,2,...,n}/{regs,status,etc}; > > That is, I think, doable. I'll have to think a bit about it -- the hardest > part is identifying via inode. But we have 32 bits, at least, to play with > :). Don't forget that we have already decided that threads (or Usre Level threads (ULT) are invisible from outside that process without incestuous knowledge of the particular UTS (User Threads Scheduler) that is running on that process (there may be many to choose from). The lowest level you can see from outside is the KSE (Kerrnel Schedulabel Entity). ULTs may migrate from one KSE to another (and in fact probably will in an SMP world). KSEs may be bound to a particular subprocess/processor intersection. Subprocesses have prioroties, KSE's do not. They inherrit the priority from their subprocess while they are runnable. i.e. for a particular process, running under 2 way SMP: B = blocked KSE R = Runnable KSE X = Executing KSE | subproc 1 | subproc 2 | subproc 3 | | priority= 1 | prio = 2 | prio = 2 | ------------------------------------------------------------------------ CPU1 | BBX | | BBBBBR | | | | | ------------------------------------------------------------------------ CPU2 | | BBRX | | | | | | ------------------------------------------------------------------------ | | | | Whether a KSE can be considered to belong to any particular subprocess when it is blocked is another question. As blocked processes in UNIX come back to life with a raised process priority, this may indicate that the UTS needs to know about this so that is can schedule threads onto the newly returned high priority subprocess. there are real-time repercussions we need to think about. I drew all this out on a whiteboard the other day with terry We decided that subprocesses were on the run queue, but that KSEs were on the sleep queue. Each CPU has a 'curproc' that points to the currently running subprocess. I think the differnce was that the subprocess could remain on the run queue and be a curpoc.. hmm I can't remember how it all went now.. aarghh, terry wrote it all down hopefully he hasn't lost it :-) Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21:26:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 94D7314DC8 for ; Sat, 20 Nov 1999 21:26:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23410 for ; Sun, 21 Nov 1999 06:26:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12397 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:26:35 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id A245D14E76 for ; Sat, 20 Nov 1999 21:25:57 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id VAA38232; Sat, 20 Nov 1999 21:25:46 -0800 (PST) Date: Sat, 20 Nov 1999 21:25:46 -0800 (PST) From: Julian Elischer To: Nate Williams Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <199911210514.WAA13707@mt.sri.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 Sat, 20 Nov 1999, Nate Williams wrote: > > New calls must be able to return and say > > "hey it's not me returnuing, but actually a new KSE, " > > Not only that, but you need a way for it to be 'aborted' out and have it > cleanup as it goes. I suspect that this will require re-writing a large > number of syscalls with threading in mind, and leaving the 'old' calls > in place will allow more flexibility as things change. > > I could envision the 'old' calls going away at some point as the new > calls get completely fleshed out and tested, to be replaced with simple > wrappers for the threaded calls. > Maybe in the libraries, but we will need to keep the old syscalls in the kernel effectively forever. (for old binaries) It's not much of a cost.. (look at linux emulation). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21:27:49 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 460D314DC8 for ; Sat, 20 Nov 1999 21:27:40 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23422 for ; Sun, 21 Nov 1999 06:27:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12418 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:27:39 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6176614DC8 for ; Sat, 20 Nov 1999 21:27:30 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id WAA01785; Sat, 20 Nov 1999 22:27:28 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA13788; Sat, 20 Nov 1999 22:27:27 -0700 Date: Sat, 20 Nov 1999 22:27:27 -0700 Message-Id: <199911210527.WAA13788@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Nate Williams , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: References: <199911210514.WAA13707@mt.sri.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > New calls must be able to return and say > > > "hey it's not me returnuing, but actually a new KSE, " > > > > Not only that, but you need a way for it to be 'aborted' out and have it > > cleanup as it goes. I suspect that this will require re-writing a large > > number of syscalls with threading in mind, and leaving the 'old' calls > > in place will allow more flexibility as things change. > > > > I could envision the 'old' calls going away at some point as the new > > calls get completely fleshed out and tested, to be replaced with simple > > wrappers for the threaded calls. > > Maybe in the libraries, but we will need to keep the old syscalls in the > kernel effectively forever. (for old binaries) It's not much of a cost.. > (look at linux emulation). Like I said above, the old calls could be simple wrappers for the new 'threaded' syscalls, which gives us the ability to have both. The 'old' implementations would go away, not the old calls. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 21:41:35 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 1884F14E5A for ; Sat, 20 Nov 1999 21:41:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA23510 for ; Sun, 21 Nov 1999 06:41:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12475 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:41:26 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3A4FC14E5A for ; Sat, 20 Nov 1999 21:41:17 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt44.pcnet.net [206.105.29.118]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id AAA10388; Sun, 21 Nov 1999 00:41:16 -0500 (EST) Message-ID: <383785E5.C9193B77@vigrid.com> Date: Sun, 21 Nov 1999 00:40:53 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads References: <3837715C.A8222F4@vigrid.com> <199911210514.WAA13707@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > > > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > > > > 2/ SUB-processes. (each with ONE OR MORE KSEs) > > > > 3/ Processes (each with one or more Sub processes) > > > > 4/ A second call-gate to implement the syscalls that are changed > > > > 5/ A different syscall protocol (using #4) to implement the fact that all > > > > IO becomes Async in a thread setting, and to return control to the > > > > (User level) Thread Scheduler (UTS) when a KSE blocks. > > > > > > I'd still like to know why we need another syscall gate in order > > > to do this. From the sounds of it, you are envisioning having two > > > implementations of every syscall, one for non-MT and one for MT. > > > Or is it more because MT enabled system calls (internally) will > > > need different arguments (struct proc p, struct thread t, whatever)? > > > > THe return value system for MT syscalls is by necessity differnt from non > > MT ones, and we need to continue to support old binaries. > > therefore by deduction, either a new syscall gate, or each syscall needs > > to be somehow aware as to how it was called. teh new call gate is the > > simplest way, and even allows intermixing of the new and old calls. > > > > New calls must be able to return and say > > "hey it's not me returnuing, but actually a new KSE, " Now I think I understand what Julian is talking about. Suppose a read(2) blocks in an MT application. Julian is thinking that read(2) returns with -1 and errno set to EMTBLOCKED or something like that? I don't think a blocking system call should return at all. Control should be returned to the UTS at another entry point and on another stack. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Nov 20 22:59:42 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 310DE1512E for ; Sat, 20 Nov 1999 22:59:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id HAA23908 for ; Sun, 21 Nov 1999 07:59:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id HAA12652 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 07:59:29 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 61B0314C80 for ; Sat, 20 Nov 1999 22:59:20 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id WAA40631; Sat, 20 Nov 1999 22:59:19 -0800 (PST) Date: Sat, 20 Nov 1999 22:59:19 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <38378171.82BE24C3@vigrid.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 Sun, 21 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > On Sat, 20 Nov 1999, Daniel M. Eischen wrote: > > > How about an approach similar to Solaris? Deliver the signal to either a > > > special KSE/thread that acts as a proxy for the other threads? Or even > > > use an activation to notify the UTS of signals. From the UTS point of > > > view, notification through an activation might be simpler since we already > > > have to handle them (activations). > > > > We need to define EXACTLY what an activation means in our context. > > it's an upcall, but are all upcalls the result of a prior downcall, (or > > even a downcall that 'forked a new KSE')? how does an upcall know what to > > do when it goes up? > > I'd say that all upcalls are _not_ necessarily the result of a prior downcall. > A subprocess that is preempted should force an upcall on the next available > subprocess. > > I assume the UTS will install a set of upcall entry points to handle > async notification events. We just need to define what events are passed > between the UTS and the kernel. What better way to install them than to do a syscall down? All the kernel needs to know is that it sets some stuff, pre-empts the present KSE and runs another. > > > My suggested idea is that the UTS does a blocking syscall > > that notifies the kernel that it is now capable of receiving upcalls, > > and the kermnel duplicates that KSE and stack and returns on a new > > KSE. The UTS knows when it returns, to immediatly allocate a new stack > > and thread (probably already allocated and waiting before the downcall > > actually) and switches to the new stack (or maybe the downcall was > > already done on the new one in which case it restarts the old thread. In > > any case the thread that did the downcall is the nominated handler of > > async events. > > That's OK, but why not use a ucontext passed in with a new system > call? Make the UTS supply ucontexts (made with makecontext) for event > notifications also. The UTS requires a KSE to run in, otherwise it has no CPU so there has to be one reserved for the task I think. (maybe not) That reminds me that all the returning of ucontexts around the place is one of the reasons why a new callgate would be a good idea. I'm not that fussed about it but it just seems to me that the information being passed back and forth is DIFFERENT than that being passed back and forth in the non-threaded world. I don't want to get into the trap of deciding that we are doing everything the "scheduler activations way", because we may be doing some things quite different. My philosophy is that things should be precomputed early and when they are required they are just 'used'. Here is a first half-thought out run-threough of how an IO syscall blocks and the UTS gets notified. --------------------- in a syscall, the thread loads some values on the user stack the thread calls the ULT syscall handler The ULT allocates an IO status block the ULT sycall handler calls the new callgate The callgate causes the user stack to be saved and registers to be saved, etc. the kernel stack is activated. a flag (a) is set. a setjmp() is done and saved at (b) and the stack is marked at (c) syscall is processed...... at some point a tsleep() is hit. it notices that flag (a) is set, and grabs a new KSE from the KSE cache. copies the kernel stack up to to (c) to that on the new KSE copies the Async KSE's stack to (c) onto the old KSE hacks the contents of (b) to fit the new KSE does a longjmp().. We are now effectively the thread returning Set 'incomplete' into the IO status block. * some stack munging thing done here I am not sure about * returns to the UTS indicating thread blocked * some user stack munging thing done here I am not sure about * UTS suspends thread UTS schedules new thread ***Time passes**** down in the bowels of the system the original KSE unblocks.. control passes back up to the top of the kernel. It sets the status of the IO as it would have, then returns, and finds itself in the ASYNC entrypoint of the UTS. (or maybe on the original return path.. depends on state of stack) the UTS notices that the IO has completed, and schedules the original thread to continue. The KSE then runs that thread until the UTS says otherwise. ------ notes: maybe only one KSE runnable on each subproc at a time? (maybe need N subprocs to run N processors) > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message