A proposal to redefine RB trees
I have a change ready to commit at https://reviews.freebsd.org/D25480 that would redefine the tree-balancing criteria for the RB tree macros, changing them from red-black trees to the weak-AVL trees described in the paper "Rank-balanced trees" by Haeupler, Sen and Tarjan. By happy coincidence (or the authors' deliberate scheme), the letters RB can represent "Rank-balanced" as easily as "red-black", so no global renaming is required. This change does not add or remove fields. It does keep a tighter balance constraint than red-black trees, so that in conditions where balancing really matters (for example, when inserting tree nodes in sorted order), weak-avl trees produce a better balanced tree and faster lookups. That same tighter balance constraint means that an insert operation is more likely to lead to restructuring of the tree than before, for which there is a small performance cost. The original paper at http://sidsen.azurewebsites.net/papers/rb-trees-talg.pdf provides more analysis of the relative benefits of weak-avl trees. Are there any objections? Doug Moore (do...@freebsd.org) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 12:14 PM, Allan Jude wrote: > On 2014-03-29 09:21, Joe Nosay wrote: > > On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl < > > s...@troutmask.apl.washington.edu> wrote: > > > >> On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: > >>> On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: > On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > > On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude > >> wrote: > > > >> On 2014-03-29 01:22, Joe Nosay wrote: > >>> I have noticed that options VPS, VIMAGE, and MROUTING are not > >> standard > >> for > >>> the kernel with a base install. Is there any way that these can be > >> made a > >>> part of the normal kernel so that jail(s) would get the full > benefit > >>> without a kernel recompile? > >>> > >> > >> VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > >> that he had a patch that solves the issue. > > > > Really, you say? That's good news. > > So, will those options soon be standard for a first time install? > > Certainly, hope not. I don't use any of options. > >>> > >>> So you use all the other devices and options of the GENERIC kernel? > >> > >> Of course, not. Not sure how you inferred such a thing. > >> > >> IMHO, GENERIC should contain only those devices and options > >> that are required to get FreeBSD booted on new hardware. > >> VIMAGE and MROUTING aren't needed, and can be configured by > >> the user after installation. As for VPS, AFAICT, there isn't > >> an option/device named VPS; at least 'find /sys/ -type f | xargs > >> grep VPS' wasn't too enlightening. > >> > >> > >> -- > >> Steve > >> > > > > > > http://www.7he.at/freebsd/vps/announcements/ > > > > > > Booyah. It exists. > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > VPS only exists in a project branch, and is not nearly in a state to be > included in GENERIC > > And I don't see a compelling reason to have MROUTING in GENERIC either. > > -- > Allan Jude > > VIMAGE? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: A proposal
> -Original Message- > From: Julian Elischer [mailto:jul...@freebsd.org] > Sent: Saturday, March 29, 2014 3:41 PM > To: Steve Kargl; Joe Nosay > Cc: freebsd-current > Subject: Re: A proposal > > On 3/29/14, 4:52 PM, Steve Kargl wrote: > > On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > >> On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude > wrote: > >> > >>> On 2014-03-29 01:22, Joe Nosay wrote: > >>>> I have noticed that options VPS, VIMAGE, and MROUTING are not > >>>> standard > >>> for > >>>> the kernel with a base install. Is there any way that these can be > >>>> made a part of the normal kernel so that jail(s) would get the full > >>>> benefit without a kernel recompile? > >>>> ___ > >>>> freebsd-current@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to " > >>> freebsd-current-unsubscr...@freebsd.org" > >>> VIMAGE has some problems with PF. Martin Matu ska said at > AsiaBSDCon > >>> that he had a patch that solves the issue. > >> Really, you say? That's good news. > >> So, will those options soon be standard for a first time install? > > Certainly, hope not. I don't use any of options. > funnily, the only profiling speed differences we've seen with enabling > netgraph is speedups :-) especially with comparing many sessions on one > vnet with the same number of sessions on several vnets. > > Last time I tested it, putting several services on different vimage jails and > assigning them different interfaces actually ran faster than having the same > services on the same VM (machine). I think we all owe this one gentleman a great show of gratitude for his work on netgraph (initially @ whistle) -- Devin (smiles) _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On 3/29/14, 4:52 PM, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: On 2014-03-29 01:22, Joe Nosay wrote: I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the kernel with a base install. Is there any way that these can be made a part of the normal kernel so that jail(s) would get the full benefit without a kernel recompile? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to " freebsd-current-unsubscr...@freebsd.org" VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon that he had a patch that solves the issue. Really, you say? That's good news. So, will those options soon be standard for a first time install? Certainly, hope not. I don't use any of options. funnily, the only profiling speed differences we've seen with enabling netgraph is speedups :-) especially with comparing many sessions on one vnet with the same number of sessions on several vnets. Last time I tested it, putting several services on different vimage jails and assigning them different interfaces actually ran faster than having the same services on the same VM (machine). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 06:11:10AM -0700, Steve Kargl wrote: > On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: > > On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: > >> On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > >>> On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: > >>> > On 2014-03-29 01:22, Joe Nosay wrote: > > I have noticed that options VPS, VIMAGE, and MROUTING are not standard > for > > the kernel with a base install. Is there any way that these can be made > > a > > part of the normal kernel so that jail(s) would get the full benefit > > without a kernel recompile? > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > that he had a patch that solves the issue. > >>> > >>> Really, you say? That's good news. > >>> So, will those options soon be standard for a first time install? > >> > >> Certainly, hope not. I don't use any of options. > > > > So you use all the other devices and options of the GENERIC kernel? > > Of course, not. Not sure how you inferred such a thing. > > IMHO, GENERIC should contain only those devices and options > that are required to get FreeBSD booted on new hardware. > VIMAGE and MROUTING aren't needed, and can be configured by > the user after installation. As for VPS, AFAICT, there isn't > an option/device named VPS; at least 'find /sys/ -type f | xargs > grep VPS' wasn't too enlightening. Until freebsd-update deals with custom kernel configurations, people will want all the possible non-conflicting flags enabled in GENERIC, or the options made available as runtime loadable kernel modules. It's not an unreasonable request. Regards, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 06:11:10AM -0700, Steve Kargl wrote: > On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: > > On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: > >> On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > >>> On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: > >>> > On 2014-03-29 01:22, Joe Nosay wrote: > > I have noticed that options VPS, VIMAGE, and MROUTING are not standard > for > > the kernel with a base install. Is there any way that these can be made > > a > > part of the normal kernel so that jail(s) would get the full benefit > > without a kernel recompile? > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > that he had a patch that solves the issue. > >>> > >>> Really, you say? That's good news. > >>> So, will those options soon be standard for a first time install? > >> > >> Certainly, hope not. I don't use any of options. > > > > So you use all the other devices and options of the GENERIC kernel? > > Of course, not. Not sure how you inferred such a thing. > > IMHO, GENERIC should contain only those devices and options > that are required to get FreeBSD booted on new hardware. > VIMAGE and MROUTING aren't needed, and can be configured by > the user after installation. As for VPS, AFAICT, there isn't > an option/device named VPS; at least 'find /sys/ -type f | xargs > grep VPS' wasn't too enlightening. IMHO common use scenarios should be included in GENERIC if they're stable and mature. E.g. I don't know why IPSEC still isn't in GENERIC. pgpbdbYRYczJw.pgp Description: PGP signature
Re: A proposal
On 2014-03-29 09:21, Joe Nosay wrote: > On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > >> On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: >>> On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude >> wrote: > >> On 2014-03-29 01:22, Joe Nosay wrote: >>> I have noticed that options VPS, VIMAGE, and MROUTING are not >> standard >> for >>> the kernel with a base install. Is there any way that these can be >> made a >>> part of the normal kernel so that jail(s) would get the full benefit >>> without a kernel recompile? >>> >> >> VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon >> that he had a patch that solves the issue. > > Really, you say? That's good news. > So, will those options soon be standard for a first time install? Certainly, hope not. I don't use any of options. >>> >>> So you use all the other devices and options of the GENERIC kernel? >> >> Of course, not. Not sure how you inferred such a thing. >> >> IMHO, GENERIC should contain only those devices and options >> that are required to get FreeBSD booted on new hardware. >> VIMAGE and MROUTING aren't needed, and can be configured by >> the user after installation. As for VPS, AFAICT, there isn't >> an option/device named VPS; at least 'find /sys/ -type f | xargs >> grep VPS' wasn't too enlightening. >> >> >> -- >> Steve >> > > > http://www.7he.at/freebsd/vps/announcements/ > > > Booyah. It exists. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > VPS only exists in a project branch, and is not nearly in a state to be included in GENERIC And I don't see a compelling reason to have MROUTING in GENERIC either. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: A proposal
On Sat, Mar 29, 2014 at 9:11 AM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: > > On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: > >> On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > >>> On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude > wrote: > >>> > On 2014-03-29 01:22, Joe Nosay wrote: > > I have noticed that options VPS, VIMAGE, and MROUTING are not > standard > for > > the kernel with a base install. Is there any way that these can be > made a > > part of the normal kernel so that jail(s) would get the full benefit > > without a kernel recompile? > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > that he had a patch that solves the issue. > >>> > >>> Really, you say? That's good news. > >>> So, will those options soon be standard for a first time install? > >> > >> Certainly, hope not. I don't use any of options. > > > > So you use all the other devices and options of the GENERIC kernel? > > Of course, not. Not sure how you inferred such a thing. > > IMHO, GENERIC should contain only those devices and options > that are required to get FreeBSD booted on new hardware. > VIMAGE and MROUTING aren't needed, and can be configured by > the user after installation. As for VPS, AFAICT, there isn't > an option/device named VPS; at least 'find /sys/ -type f | xargs > grep VPS' wasn't too enlightening. > > > -- > Steve > http://www.7he.at/freebsd/vps/announcements/ Booyah. It exists. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 10:29:23AM +0100, Lars Engels wrote: > On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: >> On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: >>> On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: >>> On 2014-03-29 01:22, Joe Nosay wrote: > I have noticed that options VPS, VIMAGE, and MROUTING are not standard for > the kernel with a base install. Is there any way that these can be made a > part of the normal kernel so that jail(s) would get the full benefit > without a kernel recompile? > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon that he had a patch that solves the issue. >>> >>> Really, you say? That's good news. >>> So, will those options soon be standard for a first time install? >> >> Certainly, hope not. I don't use any of options. > > So you use all the other devices and options of the GENERIC kernel? Of course, not. Not sure how you inferred such a thing. IMHO, GENERIC should contain only those devices and options that are required to get FreeBSD booted on new hardware. VIMAGE and MROUTING aren't needed, and can be configured by the user after installation. As for VPS, AFAICT, there isn't an option/device named VPS; at least 'find /sys/ -type f | xargs grep VPS' wasn't too enlightening. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 5:29 AM, Lars Engels wrote: > On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: > > On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > > > On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude > wrote: > > > > > > > On 2014-03-29 01:22, Joe Nosay wrote: > > > > > I have noticed that options VPS, VIMAGE, and MROUTING are not > standard > > > > for > > > > > the kernel with a base install. Is there any way that these can be > made a > > > > > part of the normal kernel so that jail(s) would get the full > benefit > > > > > without a kernel recompile? > > > > > ___ > > > > > freebsd-current@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > To unsubscribe, send any mail to " > > > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > > > > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > > > > that he had a patch that solves the issue. > > > > > > Really, you say? That's good news. > > > So, will those options soon be standard for a first time install? > > > > Certainly, hope not. I don't use any of options. > > So you use all the other devices and options of the GENERIC kernel? > I also want to know where this patch is. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Fri, Mar 28, 2014 at 10:52:49PM -0700, Steve Kargl wrote: > On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > > On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: > > > > > On 2014-03-29 01:22, Joe Nosay wrote: > > > > I have noticed that options VPS, VIMAGE, and MROUTING are not standard > > > for > > > > the kernel with a base install. Is there any way that these can be made > > > > a > > > > part of the normal kernel so that jail(s) would get the full benefit > > > > without a kernel recompile? > > > > ___ > > > > freebsd-current@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > To unsubscribe, send any mail to " > > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > > > that he had a patch that solves the issue. > > > > Really, you say? That's good news. > > So, will those options soon be standard for a first time install? > > Certainly, hope not. I don't use any of options. So you use all the other devices and options of the GENERIC kernel? pgpDFWhHRjTdf.pgp Description: PGP signature
Re: A proposal
Hi, Allan At Sat, 29 Mar 2014 01:43:11 -0400, Allan Jude wrote: > > On 2014-03-29 01:22, Joe Nosay wrote: > > I have noticed that options VPS, VIMAGE, and MROUTING are not standard for > > the kernel with a base install. Is there any way that these can be made a > > part of the normal kernel so that jail(s) would get the full benefit > > without a kernel recompile? > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > VIMAGE has some problems with PF. Martin Matuska said at AsiaBSDCon > that he had a patch that solves the issue. Oh really? Is there any site above patch? The patch is not [1] is it? # I'm too plagued with rebooting VIMAGE+pf server every midnight ;-( [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160496 > > -- > Allan Jude > --- Kazuhiko Kiriyama k...@openedu.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 01:46:15AM -0400, Joe Nosay wrote: > On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: > > > On 2014-03-29 01:22, Joe Nosay wrote: > > > I have noticed that options VPS, VIMAGE, and MROUTING are not standard > > for > > > the kernel with a base install. Is there any way that these can be made a > > > part of the normal kernel so that jail(s) would get the full benefit > > > without a kernel recompile? > > > ___ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > > that he had a patch that solves the issue. > > Really, you say? That's good news. > So, will those options soon be standard for a first time install? Certainly, hope not. I don't use any of options. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On Sat, Mar 29, 2014 at 1:43 AM, Allan Jude wrote: > On 2014-03-29 01:22, Joe Nosay wrote: > > I have noticed that options VPS, VIMAGE, and MROUTING are not standard > for > > the kernel with a base install. Is there any way that these can be made a > > part of the normal kernel so that jail(s) would get the full benefit > > without a kernel recompile? > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > VIMAGE has some problems with PF. Martin Matu ska said at AsiaBSDCon > that he had a patch that solves the issue. > > -- > Allan Jude > > Really, you say? That's good news. So, will those options soon be standard for a first time install? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A proposal
On 2014-03-29 01:22, Joe Nosay wrote: > I have noticed that options VPS, VIMAGE, and MROUTING are not standard for > the kernel with a base install. Is there any way that these can be made a > part of the normal kernel so that jail(s) would get the full benefit > without a kernel recompile? > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > VIMAGE has some problems with PF. Martin Matuska said at AsiaBSDCon that he had a patch that solves the issue. -- Allan Jude signature.asc Description: OpenPGP digital signature
A proposal
I have noticed that options VPS, VIMAGE, and MROUTING are not standard for the kernel with a base install. Is there any way that these can be made a part of the normal kernel so that jail(s) would get the full benefit without a kernel recompile? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: new sigset_t and upgrading: a proposal
On Fri, Oct 01, 1999 at 03:36:11PM -0400, Daniel Eischen wrote: > But this still doesn't entirely solve the problem. You still have > to build and install a new kernel before installing the world. Of course! Installing the world _is_ upgrading your operating system. I don't see anyone suggesting that ELF applications should work on kernels that only support a.out binaries. Neither should programs that use 64-bit file offsets work on kernels that predate that change. (Note that this is entirely different from the issue of being able to use such a system to _build_ the new world.) > While this is typically what most -current folks do anyways, it > still prevents backing up to a previous kernel after the install > world. Yes. That's what backup tapes are for. If you're going to nuke your entire operating system, you'd better be ready to recover from tores. > It seems like libc should be built to be compatible with the kernel > that is currently running. After installing world and testing the > new kernel, a subsequent make world (or some other target to get > just the libs) can be done to make the libs use the new syscalls. > I like to keep old known working kernels around just in case there > are some serious bugs with the current one. Once a kernel has > proven itself somewhat stable, you can then upgrade the libs. Or, you could do it the sensible way: upgrade the kernel to support the new syscalls, and test it for a while _before_ building and installing a world that depends on it. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Sun, 03 Oct 1999, you wrote: > Richard Wackerbarth wrote: > > Why isn't the kernel BUILT automatically as a part of "buildworld"? > > Except for the fact that the object directory is in the wrong place, why isn't > > a kernel just like any other module? > > > > This may be difficult. Which kernel do you build? I use > the same source tree for two very different machines. So, > should it build GENERIC, CUSTOM1, or CUSTOM2? I suggest all of the above. If you wish otherwise, you can turn them off by adding the appropriate entries in the subdir control files (See share/mk/bsd.subdir.mk) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Peter Wemm wrote: > > For things like config etc, that particular problem is almost over. It > does very VERY little now and I can't see that we'll have incompatable > changes (apart from shooting it and using a lightweight kernel/module build > organizer/manager/whatever). All config(8) does at present is three things: > 1: build the Makefile and options files > 2: extract fragments of the static configuration and export it in MI format >for the bootstrap. > 3: get in the way. How about stable's config? If upgrading to 4.0-STABLE is going to be kernel-first, we need a compatible config in RELENG_3 as soon as possible, if they are not the same already. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Richard Wackerbarth wrote: > Why isn't the kernel BUILT automatically as a part of "buildworld"? > Except for the fact that the object directory is in the wrong place, why isn't > a kernel just like any other module? > This may be difficult. Which kernel do you build? I use the same source tree for two very different machines. So, should it build GENERIC, CUSTOM1, or CUSTOM2? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Daniel C. Sobral" wrote: > "Rodney W. Grimes" wrote: > > > > These folks are 100% correct, some place some where we made a mistake > > and are telling users to do things in the wrong order. It might have > > even been myself that caused this, I just can't recall when and who > > said to build the world before building the kernel. But now looking > > at it in hindsight, this is plainly the wrong sequence, and we should > > correct that error as soon as possible. > > > > When did we go wrong and start saying that users should build the world > > before building a new kernel?If it was ``I'' that said it, I full > > retract any such statement, I was WRONG!. It may have been said in the > > patchkit days, or very early FreeBSD 1.x. > > It might have something to do with kernel's dependency on the tools > installed by world, such as gas, gcc and config. In the case of gcc/gas/ld etc we should be able to work around that. If the inline asm statements break on older gcc, then we should ifdef them to work the way they used to before egcs required they be changed. For things like config etc, that particular problem is almost over. It does very VERY little now and I can't see that we'll have incompatable changes (apart from shooting it and using a lightweight kernel/module build organizer/manager/whatever). All config(8) does at present is three things: 1: build the Makefile and options files 2: extract fragments of the static configuration and export it in MI format for the bootstrap. 3: get in the way. Thinks like libkvm, w, ps, top etc are usually best left till after a 'trial by fire' of the new kernel IMHO. Maybe a 'make afterkernel' or something to rebuild "the usual culprits" to automate that so it doesn't require a complete world as often. Just some thoughts that might make things easier... Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> On 2 October 1999 at 9:45, "Rodney W. Grimes" <[EMAIL PROTECTED]> wrote: > > > When did we go wrong and start saying that users should build the world > > before building a new kernel?If it was ``I'' that said it, I full > > retract any such statement, I was WRONG!. It may have been said in the > > patchkit days, or very early FreeBSD 1.x. > > We build world first, because we need an up-to-date toolchain and config > to build the kernel. > > Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] Why isn't the kernel BUILT automatically as a part of "buildworld"? Except for the fact that the object directory is in the wrong place, why isn't a kernel just like any other module? If I were to create /usr/src/kernels/i386/GENERIC and move (or link) the configuration in that directory as a source cp /usr/src/sys/i386/conf/GENERIC /usr/src/kernels/i386/GENERIC/configuration with a few minor changes, it would get build very much like (and at the same time as) /usr/src/bin. installworld could then install the kernel early in its sequence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On 2 October 1999 at 9:45, "Rodney W. Grimes" <[EMAIL PROTECTED]> wrote: > When did we go wrong and start saying that users should build the world > before building a new kernel?If it was ``I'' that said it, I full > retract any such statement, I was WRONG!. It may have been said in the > patchkit days, or very early FreeBSD 1.x. We build world first, because we need an up-to-date toolchain and config to build the kernel. Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> When did we go wrong and start saying that users should build the world > before building a new kernel?If it was ``I'' that said it, I full > retract any such statement, I was WRONG!. It may have been said in the > patchkit days, or very early FreeBSD 1.x. It's been "common culture" ever since I can remember (at least three years). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Sat, Oct 02, 1999 at 09:45:30AM -0700, Rodney W. Grimes wrote: > > Read my lips: *NEVER* do a 'make world' until you've got a new bootable > > kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make > > world' because a new kernel doesn't workd is a major drama. > > These folks are 100% correct, some place some where we made a mistake > and are telling users to do things in the wrong order. It might have > even been myself that caused this, I just can't recall when and who > said to build the world before building the kernel. But now looking > at it in hindsight, this is plainly the wrong sequence, and we should > correct that error as soon as possible. > > When did we go wrong and start saying that users should build the world > before building a new kernel?If it was ``I'' that said it, I full > retract any such statement, I was WRONG!. It may have been said in the > patchkit days, or very early FreeBSD 1.x. Unless I'm mistaken, the FreeBSD Tutorial "Upgrading FreeBSD from source" tells you to "make world" before you make and install the kernel. I take it the tutorial is wrong? :) -- Richard Seaman, Jr. email: [EMAIL PROTECTED] 5182 N. Maple Lanephone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Rodney W. Grimes" wrote: > > These folks are 100% correct, some place some where we made a mistake > and are telling users to do things in the wrong order. It might have > even been myself that caused this, I just can't recall when and who > said to build the world before building the kernel. But now looking > at it in hindsight, this is plainly the wrong sequence, and we should > correct that error as soon as possible. > > When did we go wrong and start saying that users should build the world > before building a new kernel?If it was ``I'' that said it, I full > retract any such statement, I was WRONG!. It may have been said in the > patchkit days, or very early FreeBSD 1.x. It might have something to do with kernel's dependency on the tools installed by world, such as gas, gcc and config. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Sat, 2 Oct 1999, Rodney W. Grimes wrote: > > Read my lips: *NEVER* do a 'make world' until you've got a new bootable > > kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make > > world' because a new kernel doesn't workd is a major drama. > > These folks are 100% correct, some place some where we made a mistake > and are telling users to do things in the wrong order. It might have > even been myself that caused this, I just can't recall when and who > said to build the world before building the kernel. But now looking > at it in hindsight, this is plainly the wrong sequence, and we should > correct that error as soon as possible. What happens if we version-bump the kernel conf files so a new version of config is required? You'd have to hand-build and install config first. Or is this what we want? Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
[CC: trimmed to -current] > > > > But this still doesn't entirely solve the problem. You still have > > > > to build and install a new kernel before installing the world. > > > > While this is typically what most -current folks do anyways, it > > > > still prevents backing up to a previous kernel after the install > > > > world. ... > > > If you install a kernel before installing world, you can easily recover > > > when the install world fails: reboot. The new kernel is capable of > > > running those binaries that got installed before the breakage. > > Read my lips: *NEVER* do a 'make world' until you've got a new bootable > kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make > world' because a new kernel doesn't workd is a major drama. These folks are 100% correct, some place some where we made a mistake and are telling users to do things in the wrong order. It might have even been myself that caused this, I just can't recall when and who said to build the world before building the kernel. But now looking at it in hindsight, this is plainly the wrong sequence, and we should correct that error as soon as possible. When did we go wrong and start saying that users should build the world before building a new kernel?If it was ``I'' that said it, I full retract any such statement, I was WRONG!. It may have been said in the patchkit days, or very early FreeBSD 1.x. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Daniel C. Sobral" wrote: > Marcel Moolenaar wrote: > > > > > But this still doesn't entirely solve the problem. You still have > > > to build and install a new kernel before installing the world. > > > While this is typically what most -current folks do anyways, it > > > still prevents backing up to a previous kernel after the install > > > world. > > > > You can easily install a kernel as part of the upgrade process. A > > complete upgrade would be something like: > > > > 1. Verify and/or install cross-compilation tools > > 2. Build world > > 3. Build kernel > > 4. Copy tools that are used by the install process > > 5. install kernel > > 6. install world > > 7. reboot > > > > If you install a kernel before installing world, you can easily recover > > when the install world fails: reboot. The new kernel is capable of > > running those binaries that got installed before the breakage. > > You missed the point. This is -current, right? You do all of the > above, and then reboot and find out that the new kernel doesn't > work. What do you do? The default procedure is to boot kernel.old. Read my lips: *NEVER* do a 'make world' until you've got a new bootable kernel. You can go back to a 'kernel.old' in 5 seconds. Undoing a 'make world' because a new kernel doesn't workd is a major drama. Just Don't Do It, at least not on -current where a kernel isn't expected to work every time. You can run a -current userland *months* behind your kernel, as long as you take care of libkvm and friends. Our kernel development process is done with backwards compatability in mind, not forward compatability. You can't expect last week's kernel to know about the new syscalls that are used after you committed to a buildworld. You can expect an old world to work though. Many people I talk with regularly go *months* between building world but on the other hand build a kernel every few days or so (including me). Don't use modules if you are doing this though, or keep a /modules and / modules.old to go with the kernel. (ie: when you do a 'make install' of the kernel, move /modules to /modules.old, mkdir /modules and then build/ install fresh kld's. Modules are only really useful in -current under certain curcumstances. Mostly this is 1) if you are developing a subsystem (eg: vinum) and need a rapid turnaround without a reboot, and 2) if you are running a fairly stable build, ie: not doing recompiles for months at a time. Especially don't use a vinum module (for example) if you're doing near daily kernel builds, use the static compilation option instead. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Daniel C. Sobral" wrote: > > Marcel Moolenaar wrote: > > > > You can easily install a kernel as part of the upgrade process. A > > complete upgrade would be something like: > > > > 1. Verify and/or install cross-compilation tools > > 2. Build world > > 3. Build kernel > > 4. Copy tools that are used by the install process > > 5. install kernel > > 6. install world > > 7. reboot > > > > If you install a kernel before installing world, you can easily recover > > when the install world fails: reboot. The new kernel is capable of > > running those binaries that got installed before the breakage. > > You missed the point. This is -current, right? You do all of the > above, and then reboot and find out that the new kernel doesn't > work. What do you do? The default procedure is to boot kernel.old. You're right. This isn't the right list to discuss this. We're talking about upgrades, not tracking the bleeding edge. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar wrote: > > > But this still doesn't entirely solve the problem. You still have > > to build and install a new kernel before installing the world. > > While this is typically what most -current folks do anyways, it > > still prevents backing up to a previous kernel after the install > > world. > > You can easily install a kernel as part of the upgrade process. A > complete upgrade would be something like: > > 1. Verify and/or install cross-compilation tools > 2. Build world > 3. Build kernel > 4. Copy tools that are used by the install process > 5. install kernel > 6. install world > 7. reboot > > If you install a kernel before installing world, you can easily recover > when the install world fails: reboot. The new kernel is capable of > running those binaries that got installed before the breakage. You missed the point. This is -current, right? You do all of the above, and then reboot and find out that the new kernel doesn't work. What do you do? The default procedure is to boot kernel.old. > > This is why I kind of like (was it?) Peter Wemms libc hack. > > It's a solution that may work out very well, yes. But it seems to me > that cross-compilation is on everybodies wishlist for as long as FreeBSD > exists (well almost :-) That's why I'm pressing it. This doesn't rule > out interim solutions of course. Real cross-compilation may not be worth > the effort/problems, but you can't really tell if you haven't tried > it... >From where I stand, it doesn't seem that cross-compilation will solve the problem of world needing to be built before kernel (and that includes installworld). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] Rule 69: Do unto other's code as you'd have it done unto yours To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Daniel Eischen wrote: > > Marcel Moolenaar wrote: > > Dag-Erling Smorgrav wrote: > > > > > > How about this: early in make world, we check whether or not the > > > current kernel supports the new syscalls. If it does, good. If it > > > doesn't, we build and load a small module which installs syscalls > > > which translate the sigset_t stuff into something the old syscalls can > > > grok. Does that make sense to any of you guys? > > > > That has been proposed by someone (sorry, I can't remember who exactly). > > We still need a consensus as to what we should do. Personally, I now > > like to fix this at the core of the problem: truly support > > cross-compilations. This implies (IMO) that the source tree is never > > used to build the tools with which a world is built (ideally). Such a > > solution may take too long to be implemented to be used as a solution > > now, though. > > But this still doesn't entirely solve the problem. You still have > to build and install a new kernel before installing the world. > While this is typically what most -current folks do anyways, it > still prevents backing up to a previous kernel after the install > world. You can easily install a kernel as part of the upgrade process. A complete upgrade would be something like: 1. Verify and/or install cross-compilation tools 2. Build world 3. Build kernel 4. Copy tools that are used by the install process 5. install kernel 6. install world 7. reboot If you install a kernel before installing world, you can easily recover when the install world fails: reboot. The new kernel is capable of running those binaries that got installed before the breakage. > It seems like libc should be built to be compatible with the kernel > that is currently running. After installing world and testing the > new kernel, a subsequent make world (or some other target to get > just the libs) can be done to make the libs use the new syscalls. You still want to use the source tree to tools that run on the machine that does the building. Assume for a moment that such can't be done. What you get is real cross-compilation. > This is why I kind of like (was it?) Peter Wemms libc hack. It's a solution that may work out very well, yes. But it seems to me that cross-compilation is on everybodies wishlist for as long as FreeBSD exists (well almost :-) That's why I'm pressing it. This doesn't rule out interim solutions of course. Real cross-compilation may not be worth the effort/problems, but you can't really tell if you haven't tried it... -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar wrote: > Dag-Erling Smorgrav wrote: > > > > How about this: early in make world, we check whether or not the > > current kernel supports the new syscalls. If it does, good. If it > > doesn't, we build and load a small module which installs syscalls > > which translate the sigset_t stuff into something the old syscalls can > > grok. Does that make sense to any of you guys? > > That has been proposed by someone (sorry, I can't remember who exactly). > We still need a consensus as to what we should do. Personally, I now > like to fix this at the core of the problem: truly support > cross-compilations. This implies (IMO) that the source tree is never > used to build the tools with which a world is built (ideally). Such a > solution may take too long to be implemented to be used as a solution > now, though. But this still doesn't entirely solve the problem. You still have to build and install a new kernel before installing the world. While this is typically what most -current folks do anyways, it still prevents backing up to a previous kernel after the install world. It seems like libc should be built to be compatible with the kernel that is currently running. After installing world and testing the new kernel, a subsequent make world (or some other target to get just the libs) can be done to make the libs use the new syscalls. I like to keep old known working kernels around just in case there are some serious bugs with the current one. Once a kernel has proven itself somewhat stable, you can then upgrade the libs. This is why I kind of like (was it?) Peter Wemms libc hack. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Dag-Erling Smorgrav wrote: > > How about this: early in make world, we check whether or not the > current kernel supports the new syscalls. If it does, good. If it > doesn't, we build and load a small module which installs syscalls > which translate the sigset_t stuff into something the old syscalls can > grok. Does that make sense to any of you guys? That has been proposed by someone (sorry, I can't remember who exactly). We still need a consensus as to what we should do. Personally, I now like to fix this at the core of the problem: truly support cross-compilations. This implies (IMO) that the source tree is never used to build the tools with which a world is built (ideally). Such a solution may take too long to be implemented to be used as a solution now, though. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar <[EMAIL PROTECTED]> writes: > The problem > --- > When doing a make world, tools are being built that are used by the > build process. This is to make sure that the tools are appropriate for > doing a make world. The problem we now face is that the sigset_t change > causes this to break. The tools that are being built use new syscalls > not present in a kernel. Not only that, the new tools expect a different > sigframe in general. > So, the problem can be split into: > A) New syscalls using the new sigset_t (sigaction and so on) > B) A new sigframe (new siginfo, no sigcontext but ucontext_t) How about this: early in make world, we check whether or not the current kernel supports the new syscalls. If it does, good. If it doesn't, we build and load a small module which installs syscalls which translate the sigset_t stuff into something the old syscalls can grok. Does that make sense to any of you guys? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
> > > Cons
> > >
> > > o Upgrading from 3.3 and before to -current is only possible after
> > >an upgrade to post 3.3.
> >
> > Not good.
>
> We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
> before trying to jump to 3.x via `make {upgrade,world,aout-to-elf}. So
> we have precidence for this.
And failure to do this became a FAQ, so it's still ``not good''.
I think Marcel is on a good track here, he is getting a real grasp of
the problem and will probably solve some long standing issues if we
let him run with it... giving input when needed and support his efforts
by testing and/or contributing area of expertise information.
--
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Fri, Oct 01, 1999 at 08:48:34AM +1000, David O'Brien wrote:
>On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
>> > Cons
>> >
>> > o Upgrading from 3.3 and before to -current is only possible after
>> >an upgrade to post 3.3.
>>
>> Not good.
>
>We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
>before trying to jump to 3.x via `make {upgrade,world,aout-to-elf}.
I thought it was `2.2.8-RELEASE or later', not `the latest
2.2-STABLE'. (I know this has been stated regularly in various
mailing lists, but I can't find the exact wording in the FAQ or
handbook). AFAIK, this recommendation was more along the lines of
`it's known to work with 2.2.8 and isn't guaranteed to work with
earlier releases'. I'm fairly certain I've upgraded machines from
2.2.6 or 2.2.7 to 3.x without installing 2.2.8. If we implement this
change, it will be `the upgrade is guaranteed not to work unless you
are running 3.x from 1st October 1999 or later'.
I believe that the above also implies that there should be a
3.4-RELEASE before 4.0-RELEASE (I'm not sure what has been planned)
so that there's a -release that is upgradeable to -current.
In any case, I'm not sure that this is a particularly clean solution:
1) It is a specific work-around for this problem and does not solve
the general problem: Buildworld should not use be using tools
built for the new world with the current kernel.
2) It's not a change that can be applied to -current, tested and then
MFC'd. This increases the likelihood that it will break -stable.
Peter
--
Peter Jeremy (VK2PJ)[EMAIL PROTECTED]
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5982
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 06:25:56AM -0700, Rodney W. Grimes wrote:
> > Cons
> >
> > o Upgrading from 3.3 and before to -current is only possible after
> >an upgrade to post 3.3.
>
> Not good.
We recommend that 2.2.x people upgrade to the latest 2.2-STABLE offering
before trying to jump to 3.x via `make {upgrade,world,aout-to-elf}. So
we have precidence for this.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Rodney W. Grimes" wrote: > > > I don't think that's necessary. If I have, say, MIPS assembler code, > > then I should be able to generate MIPS binaries on, say, Intel. MIPS > > assembler code is clearly not compatible with Intel. This is also true > > if I would make FreeBSD/Alpha on FreeBSD/i386. I'm speaking true > > cross-compilation here :-) > > Your confusing yourself by mixing cross tools building with target > building. You would never use the MIPS assembler source to build > an i386 ``tool'' to build the i386 version of gcc that produces alpha > binaires. Exactly. That's why I don't want a -stable make world to build the tools with -current sources to produce -current binaries. I want tools for -stable that can handle the task. If the tools from the source-tree are not appropriate, install newer versions from the ports collection. > It is a two stage process, say that slowly to yourself about 5 times... Spot on! Have make world first verify and install the proper tools without using anything from the source tree that you are using for the make world and after that make world with the toolset you have verified and/or installed in stage 1. > > > > The current build-tools target tries to solve that by creating a > > > > compiler C' by using cross-compilation. The result violates rule 1: > > > > Compiler C' is build for machine 2 and not for machine 1 and therefore > > > > should not be used on machine 1. This is where the discussion is all > > > > about. > > > > > > Then this is an error in the tools target, by design the tools are > > > suppose to be capable of running on machine 1, and producing code for > > > machine 2. > > > > But how do you know that you can build tools with sources for machine 2 > > to run on machine 1? > > Because it is the FreeBSD source tree, and we control that aspect of it, > if the above is a known. If it can't be done the sources are non-portable. I think we should assume non-portability if we really want to make cross-compilation work. > > You can't make i386 binaries with alpha assembler > > sources, for example. To put it differently, isn't this why we need to > > port software in the first place? > > But I can compile the gas assembler which is a portable assembler on anything > to produce anything. The software is already ported. In that case, we don't have to build gas as part of the make world. gas is capable of handling the cross-compilations we need... > > > Only later when you do the ``make all'' over the tree do > > > you produce the compiler that runs on machine 2. Yes, you may end > > > up building gcc/egcs twice. Just like you may end up building make > > > twice. > > > > Yep. Unavoidable. > > > > > > So, as long as rule 2 is not violated, cross-compilation can be used to > > > > to build a -current system on -stable and thus also to handle upgrades. > > > > The problem is in the case where rule 2 is violated. What's needed is > > > > the ability to "port" the proper tools to machine 1. Well, the first > > > > thing that comes to mind is the ports collection... > > > > > > Why should ports have code that is any more portable than what is in > > > the src tree? > > > > It's not that ports have code that is more portable, ports have patches > > that are applied as part of the build to make it work on FreeBSD. Also, > > ports generally still run configure and friends to avoid compatibility > > problems. This have been staticized (sp?) in the source tree. > > You keep going back to this stuff that won't work on FreeBSD. Now I can't > see how you get there, but /usr/src is pretty much a sure win to run on > FreeBSD if it _is_ FreeBSD. I'm not saying that it won't work, I'm just not making the assumption that it works. > > > You should just be able to build egcs from the current > > > sources with the correct options and achive any results you could with > > > a port. > > > > But you'll be using -stable headers and libraries (at least, that should > > be case). > > Exactly, thats what makes it the hosted cross compiler. The only thing > we use it for is building the target binaries. Have you ever worked > in cross platform development?? Not enough. I am a compiler writer, though. > > This means that egcs, configured to build and run on -current > > may be improperly configured to build and run on -stable. > > Then de statisize the configuration. If possible, yes. If the sources don't allow that, use ports. > > You may be right about going mad if you try to handle the > > interdependencies, though :-) > > > > I'm pretty sure that is the cause of the loss of a certain part of my > life but since I can't remeber much about it I am not positive :-) :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the bo
Re: new sigset_t and upgrading: a proposal
> > Mainly historical bugs. Includes are installed too early and they only > > match the new syscalls. Tools are built using the new includes, so they > > need new libraries to be consistent. Therefore the new libraries are > > built before the new tools. These bugs were implemented in FreeBSD-1 by > > someone named rgrimes :-). > > I'll eat the crow, yes, I did implement that. It was the first step > at even being able to ``make world''. Had to start some place. And > technically the bug dates back to the patchkit, infact probably a > 1.x version of the 386BSD PatchKit. Naw, 386BSD was never able to 'build itself' from scratch. That was a FreeBSD/rgrimes addition, bugs and all. :) :) :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> > Why are the tools being built using new syscalls? What causes this? > > Mainly historical bugs. Includes are installed too early and they only > match the new syscalls. Tools are built using the new includes, so they > need new libraries to be consistent. Therefore the new libraries are > built before the new tools. These bugs were implemented in FreeBSD-1 by > someone named rgrimes :-). I'll eat the crow, yes, I did implement that. It was the first step at even being able to ``make world''. Had to start some place. And technically the bug dates back to the patchkit, infact probably a 1.x version of the 386BSD PatchKit. Now, the addition of obj/tmp and the TOOLS thing was suppose to fix that by using the current headers/libraries to build a set of tools that didn't go smashing around on the system. If someone copied the earlier work that had a different purpose, and these nasty bugs, well... they would certainly still be there! -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> "Rodney W. Grimes" wrote: > > > > > 1. A compiler C running on machine 1 and capable of generating code > > >for machine 2 (the compiler includes headers and libraries), > > > 2. Source code compatible with compiler C, but also with machine 2. > > > > And also compatible with machine 1, that is the bugger right now > > it seems. Have the sources been modified such that they are now > > no longer portable :-(. > > I don't think that's necessary. If I have, say, MIPS assembler code, > then I should be able to generate MIPS binaries on, say, Intel. MIPS > assembler code is clearly not compatible with Intel. This is also true > if I would make FreeBSD/Alpha on FreeBSD/i386. I'm speaking true > cross-compilation here :-) Your confusing yourself by mixing cross tools building with target building. You would never use the MIPS assembler source to build an i386 ``tool'' to build the i386 version of gcc that produces alpha binaires. It is a two stage process, say that slowly to yourself about 5 times... > > > The current build-tools target tries to solve that by creating a > > > compiler C' by using cross-compilation. The result violates rule 1: > > > Compiler C' is build for machine 2 and not for machine 1 and therefore > > > should not be used on machine 1. This is where the discussion is all > > > about. > > > > Then this is an error in the tools target, by design the tools are > > suppose to be capable of running on machine 1, and producing code for > > machine 2. > > But how do you know that you can build tools with sources for machine 2 > to run on machine 1? Because it is the FreeBSD source tree, and we control that aspect of it, if the above is a known. If it can't be done the sources are non-portable. > You can't make i386 binaries with alpha assembler > sources, for example. To put it differently, isn't this why we need to > port software in the first place? But I can compile the gas assembler which is a portable assembler on anything to produce anything. The software is already ported. > > Only later when you do the ``make all'' over the tree do > > you produce the compiler that runs on machine 2. Yes, you may end > > up building gcc/egcs twice. Just like you may end up building make > > twice. > > Yep. Unavoidable. > > > > So, as long as rule 2 is not violated, cross-compilation can be used to > > > to build a -current system on -stable and thus also to handle upgrades. > > > The problem is in the case where rule 2 is violated. What's needed is > > > the ability to "port" the proper tools to machine 1. Well, the first > > > thing that comes to mind is the ports collection... > > > > Why should ports have code that is any more portable than what is in > > the src tree? > > It's not that ports have code that is more portable, ports have patches > that are applied as part of the build to make it work on FreeBSD. Also, > ports generally still run configure and friends to avoid compatibility > problems. This have been staticized (sp?) in the source tree. You keep going back to this stuff that won't work on FreeBSD. Now I can't see how you get there, but /usr/src is pretty much a sure win to run on FreeBSD if it _is_ FreeBSD. > > > You should just be able to build egcs from the current > > sources with the correct options and achive any results you could with > > a port. > > But you'll be using -stable headers and libraries (at least, that should > be case). Exactly, thats what makes it the hosted cross compiler. The only thing we use it for is building the target binaries. Have you ever worked in cross platform development?? > This means that egcs, configured to build and run on -current > may be improperly configured to build and run on -stable. Then de statisize the configuration. > > > If you can't, then the src tree has been rendered non-portable. > > That may as well be the case. I can't give a more definite statement > right now. > > > > 2. An easy, yet flexible way must be used to be able to tell whether > > >ports must be installed or not. Simple rules like > > > ".if $source < srcvers .and $target > trgvers .then install egcs" > > >where $source = `sysctl kern.osreldate` and so on, may be sufficient. > > > > Irrelivant, just always build the correct set of tools. Trying to maintain > > a list of the intertwinned dependicies can lead one to madness. > > Hmmm... > > Given the 2 cross-compilation prerequisites I gave, it follows that when > the source machine has the proper tools for a cross-compilation, you > don't need to build any tools as part of the build process itself. It > could be advanteous to split a make world into a tools verification and > installation phase, followed by the actual (cross)build. This can maybe > also be used to handle bootstrapping problems on -current itself > (compiling -current on a -current machine). It certainly minimizes > unnecessary compilation and thus minimizes the time needed to do a make > world.
Re: new sigset_t and upgrading: a proposal
> Why are the tools being built using new syscalls? What causes this? Mainly historical bugs. Includes are installed too early and they only match the new syscalls. Tools are built using the new includes, so they need new libraries to be consistent. Therefore the new libraries are built before the new tools. These bugs were implemented in FreeBSD-1 by someone named rgrimes :-). For cross-compiling to i386's with 64-bit longs, I build all the tools in the host environment (set BMAKEENV to nothing). I guess this is good enough to fix the current problem in some cases. It works if and only if the current sources for the tools are correct for the host machine. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Rodney W. Grimes" wrote: > > > 1. A compiler C running on machine 1 and capable of generating code > >for machine 2 (the compiler includes headers and libraries), > > 2. Source code compatible with compiler C, but also with machine 2. > > And also compatible with machine 1, that is the bugger right now > it seems. Have the sources been modified such that they are now > no longer portable :-(. I don't think that's necessary. If I have, say, MIPS assembler code, then I should be able to generate MIPS binaries on, say, Intel. MIPS assembler code is clearly not compatible with Intel. This is also true if I would make FreeBSD/Alpha on FreeBSD/i386. I'm speaking true cross-compilation here :-) > > The current build-tools target tries to solve that by creating a > > compiler C' by using cross-compilation. The result violates rule 1: > > Compiler C' is build for machine 2 and not for machine 1 and therefore > > should not be used on machine 1. This is where the discussion is all > > about. > > Then this is an error in the tools target, by design the tools are > suppose to be capable of running on machine 1, and producing code for > machine 2. But how do you know that you can build tools with sources for machine 2 to run on machine 1? You can't make i386 binaries with alpha assembler sources, for example. To put it differently, isn't this why we need to port software in the first place? > Only later when you do the ``make all'' over the tree do > you produce the compiler that runs on machine 2. Yes, you may end > up building gcc/egcs twice. Just like you may end up building make > twice. Yep. Unavoidable. > > So, as long as rule 2 is not violated, cross-compilation can be used to > > to build a -current system on -stable and thus also to handle upgrades. > > The problem is in the case where rule 2 is violated. What's needed is > > the ability to "port" the proper tools to machine 1. Well, the first > > thing that comes to mind is the ports collection... > > Why should ports have code that is any more portable than what is in > the src tree? It's not that ports have code that is more portable, ports have patches that are applied as part of the build to make it work on FreeBSD. Also, ports generally still run configure and friends to avoid compatibility problems. This have been staticized (sp?) in the source tree. > You should just be able to build egcs from the current > sources with the correct options and achive any results you could with > a port. But you'll be using -stable headers and libraries (at least, that should be case). This means that egcs, configured to build and run on -current may be improperly configured to build and run on -stable. > If you can't, then the src tree has been rendered non-portable. That may as well be the case. I can't give a more definite statement right now. > > 2. An easy, yet flexible way must be used to be able to tell whether > >ports must be installed or not. Simple rules like > > ".if $source < srcvers .and $target > trgvers .then install egcs" > >where $source = `sysctl kern.osreldate` and so on, may be sufficient. > > Irrelivant, just always build the correct set of tools. Trying to maintain > a list of the intertwinned dependicies can lead one to madness. Hmmm... Given the 2 cross-compilation prerequisites I gave, it follows that when the source machine has the proper tools for a cross-compilation, you don't need to build any tools as part of the build process itself. It could be advanteous to split a make world into a tools verification and installation phase, followed by the actual (cross)build. This can maybe also be used to handle bootstrapping problems on -current itself (compiling -current on a -current machine). It certainly minimizes unnecessary compilation and thus minimizes the time needed to do a make world. You may be right about going mad if you try to handle the interdependencies, though :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> "Rodney W. Grimes" wrote: > > > IMHO, the only ``correct'' fix for the latest incarnation of the > > problem is to finally once and for all fix the cross compilation > > environment instead of using a half cooked tools: target to deal > > with certain problems. > > brainstorm: > > Upgrading cannot be solved if it is approached as being nothing more > than a cross-compilation. This can be easily seen by the following > cross-compilation prerequisites: > > 1. A compiler C running on machine 1 and capable of generating code >for machine 2 (the compiler includes headers and libraries), > 2. Source code compatible with compiler C, but also with machine 2. And also compatible with machine 1, that is the bugger right now it seems. Have the sources been modified such that they are now no longer portable :-(. > The problem is that upgrading can violate the first part of rule 2 > (source code compatible with the compiler), because you have new sources > (say -current) which you want to compile with an old compiler (say > -stable). Think of having ANSI C extensions without the proper support > for it in the compiler. Okay. > The current build-tools target tries to solve that by creating a > compiler C' by using cross-compilation. The result violates rule 1: > Compiler C' is build for machine 2 and not for machine 1 and therefore > should not be used on machine 1. This is where the discussion is all > about. Then this is an error in the tools target, by design the tools are suppose to be capable of running on machine 1, and producing code for machine 2. Only later when you do the ``make all'' over the tree do you produce the compiler that runs on machine 2. Yes, you may end up building gcc/egcs twice. Just like you may end up building make twice. To solve you above problem gcc/egcs would need to be added to the tools target probably right after make was built. > So, as long as rule 2 is not violated, cross-compilation can be used to > to build a -current system on -stable and thus also to handle upgrades. > The problem is in the case where rule 2 is violated. What's needed is > the ability to "port" the proper tools to machine 1. Well, the first > thing that comes to mind is the ports collection... Why should ports have code that is any more portable than what is in the src tree? You should just be able to build egcs from the current sources with the correct options and achive any results you could with a port. If you can't, then the src tree has been rendered non-portable. > Example: If gcc on -stable can not be used to build a -current world, > then egcs must be installed from the ports collection and build as part > of the upgrade/cross-compilation. the egcs port does not violate rule 1 > and since egcs is used on -current, rule 2 is also not violated. The > build process uses egcs to do the cross-compilation. We did this without the ports collection when we jumped from gcc 1.x to 2.x, and that had some major hoops in it. One should probably look closely at the NOTOOLS sections of the Makefile and see how it works when this is undef. > This implies that: > 1. The ports collection must contain ports for all the tools that are >needed for doing cross-compilations and/or upgrades from any > supported >source version to any supported target version. I would amend that to be what has always been true up until now it seems, the SRC tree must contain all the tools that are needed for doing cross-compilation, and those tools should be maintained in a portable enough state that they can be built on box X running OS Y and produce binaries for box Z. This is the purpose of the tools build section of the Makefile. > 2. An easy, yet flexible way must be used to be able to tell whether >ports must be installed or not. Simple rules like > ".if $source < srcvers .and $target > trgvers .then install egcs" >where $source = `sysctl kern.osreldate` and so on, may be sufficient. Irrelivant, just always build the correct set of tools. Trying to maintain a list of the intertwinned dependicies can lead one to madness. > Am I being clear? Yes. > Do I make any sense? :-) Somewhat, you seem to be headed the right way. > Does this in fact cover it? I think it does, as amended by myself. > Can it be done? Most likely. > > BTW: I'm running a make buildworld on -stable with -current sources. I'm > making assumptions I like to see verified... :-). > > > I furthermore think that if you put your mindset in the frame that this > > is just another engineering problem you'll come up with the ``right > > solution'' that will make everyone happy. > > You don't have to be a committer for long to know that you can't make > everyone happy :-) :-) -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
"Rodney W. Grimes" wrote: > IMHO, the only ``correct'' fix for the latest incarnation of the > problem is to finally once and for all fix the cross compilation > environment instead of using a half cooked tools: target to deal > with certain problems. brainstorm: Upgrading cannot be solved if it is approached as being nothing more than a cross-compilation. This can be easily seen by the following cross-compilation prerequisites: 1. A compiler C running on machine 1 and capable of generating code for machine 2 (the compiler includes headers and libraries), 2. Source code compatible with compiler C, but also with machine 2. The problem is that upgrading can violate the first part of rule 2 (source code compatible with the compiler), because you have new sources (say -current) which you want to compile with an old compiler (say -stable). Think of having ANSI C extensions without the proper support for it in the compiler. The current build-tools target tries to solve that by creating a compiler C' by using cross-compilation. The result violates rule 1: Compiler C' is build for machine 2 and not for machine 1 and therefore should not be used on machine 1. This is where the discussion is all about. So, as long as rule 2 is not violated, cross-compilation can be used to to build a -current system on -stable and thus also to handle upgrades. The problem is in the case where rule 2 is violated. What's needed is the ability to "port" the proper tools to machine 1. Well, the first thing that comes to mind is the ports collection... Example: If gcc on -stable can not be used to build a -current world, then egcs must be installed from the ports collection and build as part of the upgrade/cross-compilation. the egcs port does not violate rule 1 and since egcs is used on -current, rule 2 is also not violated. The build process uses egcs to do the cross-compilation. This implies that: 1. The ports collection must contain ports for all the tools that are needed for doing cross-compilations and/or upgrades from any supported source version to any supported target version. 2. An easy, yet flexible way must be used to be able to tell whether ports must be installed or not. Simple rules like ".if $source < srcvers .and $target > trgvers .then install egcs" where $source = `sysctl kern.osreldate` and so on, may be sufficient. Am I being clear? Do I make any sense? :-) Does this in fact cover it? Can it be done? BTW: I'm running a make buildworld on -stable with -current sources. I'm making assumptions I like to see verified... > I furthermore think that if you put your mindset in the frame that this > is just another engineering problem you'll come up with the ``right > solution'' that will make everyone happy. You don't have to be a committer for long to know that you can't make everyone happy :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
> Hi, > > In the recent discussion about the breakage of the upgrade path from > -stable to -current numerous suggestions and other kinds of remarks have > been made. In this light I have the following proposal. Please share > your thoughts... > > NOTE: This proposal only discusses upgrading from -stable to -current. > Users already running -current are expected to be capable of building a > kernel before doing a make world. > > The problem > --- > When doing a make world, tools are being built that are used by the > build process. This is to make sure that the tools are appropriate for > doing a make world. The problem we now face is that the sigset_t change > causes this to break. The tools that are being built use new syscalls > not present in a kernel. Not only that, the new tools expect a different ^^^ Why are the tools being built using new syscalls? What causes this? I can't find it from a quick read of the Makefiles. Should not a proper adjustment to a -I flags on a cc command line some place fix this? Your changes have exposed a very serious short comming of the tools target, and as others have pointed out, if we ever even want to think about getting close to cross compiliation this target must work correctly. Please search mail archives about many various discussions about this over the 6 year history of FreeBSD. IMHO, the only ``correct'' fix for the latest incarnation of the problem is to finally once and for all fix the cross compilation environment instead of using a half cooked tools: target to deal with certain problems. > sigframe in general. > So, the problem can be split into: > A) New syscalls using the new sigset_t (sigaction and so on) > B) A new sigframe (new siginfo, no sigcontext but ucontext_t) > > The solution > > Sub-problem A (syscalls) can be easily handled if the syscalls are added > to a -stable kernel. The new sigset_t and dependencies used by these > syscalls are converted back and are handled by the kernel in the normal > way. The assumption here is that the tools that are needed by the make > world are not depended on the extra signals and/or RT signals. Or even easier to fix, never call them. What in the world is building in the tools target with new syscalls All of that stuff is suppose to be built using the currently installed library/kernel API. If not we are never going to get to cross-compilation. > Sub-problem B (sigframe) doesn't need to be handled, because: > 1. none of the tools required for doing a make world depends > on siginfo_t. The only C sources where SA_SIGINFO can be > found (not counting /sys) are: > ./contrib/sendmail/src/conf.c > ./gnu/usr.bin/rcs/lib/rcsutil.c > 2. The only program that uses sigcontext (and therefore > possibly sigreturn) is doscmd, which is not needed for > anything other than DOS emulation. > This simply means that the sigframe changes are not visible in general > and that the old sigframe should work for the binaries al well. Good. > > Pros > > o It's relatively easy. > o It won't interfere with the normal operation of a -stable machine >and thus won't stretch the meaning of "stable" as a complete >backport would do. > o It increases inoperability between -stable and -current. > o It doesn't require to change the already complex build process. > > Cons > > o Upgrading from 3.3 and before to -current is only possible after >an upgrade to post 3.3. Not good. > o It's still hypothetical. And in IMNSHO, should probably remain that way. I like real solutions, not fragile bandaids. I think your a pretty smart fellow, anyone who was able to do this with the signal code and have it come out working as well as it has (glenned from other posts about people who have made the jump in -current) should be able to solve yet another engineering problem that was not accounted for at the beginning of your change. You probably solved a dozen of them during this work, whats one more :-) I furthermore think that if you put your mindset in the frame that this is just another engineering problem you'll come up with the ``right solution'' that will make everyone happy. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, 30 Sep 1999, Marcel Moolenaar wrote: > Richard Wackerbarth wrote: > > > > > Sub-problem A (syscalls) can be easily handled if the syscalls are added > > > to a -stable kernel. > > > > Wrong. I CANNOT rebuild the kernel that runs my build machine. > > What are you saying? It's not my machine. It's a production machine. My target machines are too small/slow to do their own builds. I need to do their builds on the build server. In other words, build tools need to be capable of being run on "older" kernels. It is permissable to compile special versions for the purpose. But they will be used ONLY to build that particular target. They cannot affect other users. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Richard Wackerbarth wrote: > > > Sub-problem A (syscalls) can be easily handled if the syscalls are added > > to a -stable kernel. > > Wrong. I CANNOT rebuild the kernel that runs my build machine. What are you saying? -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Andrew Reilly wrote: > > On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: > > The problem > > --- > > When doing a make world, tools are being built that are used by the > > build process. This is to make sure that the tools are appropriate for > > doing a make world. The problem we now face is that the sigset_t change > > causes this to break. The tools that are being built use new syscalls > > not present in a kernel. Not only that, the new tools expect a different > > sigframe in general. > > As far as I can see, if this is the case, then this is the only > problem. The tools built for a buildworld are tools that have > to run on the _current_ platform, whatever that might be, with > the new platform as a target. Yep. > Therefore, they should be build > against the existing system include files and libraries, and so > should run on the existing system. This requires porting. If it only was that simple... > (b) You build a new kernel before you do the install-world, > reboot, and then installworld. This is the same as building a new kernel before doing make world. > I can't see any bennefit at all to (a), or any problem with (b). (b) is far too complex. > That said, I don't mind your idea of extending the stable > kernel, but that is still really just a sneaky way of getting > the user to build and install a kernel that supports the new API > before they try to installworld. Isn't it? Yep, only "marketed" a bit better :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, 30 Sep 1999, Marcel Moolenaar wrote: > Sub-problem B (sigframe) doesn't need to be handled, because: > 1. none of the tools require ... Correct, this is a "non-problem". > Sub-problem A (syscalls) can be easily handled if the syscalls are added > to a -stable kernel. Wrong. I CANNOT rebuild the kernel that runs my build machine. What we need is to (effectively) remove these syscalls from the tools in question. This can be done with conditional compilation or a compatability library. Each tool should be evaluated for its functionality. If the host's tool has the required functionality, there is no reason to upgrade it in order to build the "foreign" (4.0) system. For example, "cat". If the host's tool is inappropriate, we MUST build a cross-build version. In many cases, this simply means that we compile the source of the tool with the host's headers. In others, it is more complex, but it can, and should, be done. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: > So, the problem can be split into: > A) New syscalls using the new sigset_t (sigaction and so on) > B) A new sigframe (new siginfo, no sigcontext but ucontext_t) "I'm probably missing something, but..." (TM) The new syscall problem has been delt with before by catching the illegal signal and doing it by hand (getcwd works this way in 3.X anyway). Could the signal calls not do the following: 1) On first call use the osignal stuff to catch the illegal syscall signal, and set a have__newsigt if the signal is presnet and then use the new syscalls. 2) If they're not present settle for translating the calls. Once you know if you have the new sigframe or not you can decide if you have to translate. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
Marcel Moolenaar wrote: > Pros > > o It increases inoperability between -stable and -current. I mean decreases inoperability or increases operability of course :-/ -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new sigset_t and upgrading: a proposal
On Thu, Sep 30, 1999 at 12:13:32PM +0200, Marcel Moolenaar wrote: > The problem > --- > When doing a make world, tools are being built that are used by the > build process. This is to make sure that the tools are appropriate for > doing a make world. The problem we now face is that the sigset_t change > causes this to break. The tools that are being built use new syscalls > not present in a kernel. Not only that, the new tools expect a different > sigframe in general. As far as I can see, if this is the case, then this is the only problem. The tools built for a buildworld are tools that have to run on the _current_ platform, whatever that might be, with the new platform as a target. Therefore, they should be build against the existing system include files and libraries, and so should run on the existing system. With these tools, we build the world. As far as I can tell, the problem is installworld. Either: (a) The tools required to build the corresponding new kernel have to be secreted away in an "upgrade-bin" directory, so that they are still accessible after the install world (none of which will run on the existing kernel). (b) You build a new kernel before you do the install-world, reboot, and then installworld. I can't see any bennefit at all to (a), or any problem with (b). As I mentioned in a previous mail, why on earth should we expect user-land programs built to a new API to run on a kernel that doesn't support that API. The converse has always been true, though. Kernels usually support any new API and the previous one or more, so that old applications will still run. That said, I don't mind your idea of extending the stable kernel, but that is still really just a sneaky way of getting the user to build and install a kernel that supports the new API before they try to installworld. Isn't it? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new sigset_t and upgrading: a proposal
Hi, In the recent discussion about the breakage of the upgrade path from -stable to -current numerous suggestions and other kinds of remarks have been made. In this light I have the following proposal. Please share your thoughts... NOTE: This proposal only discusses upgrading from -stable to -current. Users already running -current are expected to be capable of building a kernel before doing a make world. The problem --- When doing a make world, tools are being built that are used by the build process. This is to make sure that the tools are appropriate for doing a make world. The problem we now face is that the sigset_t change causes this to break. The tools that are being built use new syscalls not present in a kernel. Not only that, the new tools expect a different sigframe in general. So, the problem can be split into: A) New syscalls using the new sigset_t (sigaction and so on) B) A new sigframe (new siginfo, no sigcontext but ucontext_t) The solution Sub-problem A (syscalls) can be easily handled if the syscalls are added to a -stable kernel. The new sigset_t and dependencies used by these syscalls are converted back and are handled by the kernel in the normal way. The assumption here is that the tools that are needed by the make world are not depended on the extra signals and/or RT signals. Sub-problem B (sigframe) doesn't need to be handled, because: 1. none of the tools required for doing a make world depends on siginfo_t. The only C sources where SA_SIGINFO can be found (not counting /sys) are: ./contrib/sendmail/src/conf.c ./gnu/usr.bin/rcs/lib/rcsutil.c 2. The only program that uses sigcontext (and therefore possibly sigreturn) is doscmd, which is not needed for anything other than DOS emulation. This simply means that the sigframe changes are not visible in general and that the old sigframe should work for the binaries al well. Pros o It's relatively easy. o It won't interfere with the normal operation of a -stable machine and thus won't stretch the meaning of "stable" as a complete backport would do. o It increases inoperability between -stable and -current. o It doesn't require to change the already complex build process. Cons o Upgrading from 3.3 and before to -current is only possible after an upgrade to post 3.3. o It's still hypothetical. -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
