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
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:49
> -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,
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 inst
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 J
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 J
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:1
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
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 h
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:
> > > >
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 st
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 t
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 t
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) w
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?
> _
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?
___
freeb
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 suggesti
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 k
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 a
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 tre
"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 t
> 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 i
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
> pa
> 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 s
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
"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.
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
[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 kerne
"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
"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
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 inst
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 sysc
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_
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 sysca
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
> 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
> be
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
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
"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/i38
> > 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
> > 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
>
> "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, th
> 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 befor
"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 bugg
> "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 c
"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 i
> 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 fro
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 ma
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 In
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
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 CANN
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 pro
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
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 sig
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 -cu
55 matches
Mail list logo
