Re: Backporting DFly patches to FreeBSD?

["Devon H. O'Dell" <dodell@xxxxxxxxxxxxxxx>]

In reply to two posts, since I don't have David's email.

On Sat, 2005-02-19 at 10:55 -0800, Matthew Dillon wrote:
> :There have been so many major and minor developments in DFly that
> :looking at any one item, such as the boot code, for back port into
> :fbsd has become a moot point.
> :
> :One taking note from reading previous posts to the fbsd lists by
> :various users talking about misc. advancements in DFly, and questions
> :are asked about back porting the changes into fbsd has never ended
> :well.  Always due to hostility from the fbsd developers to the
> :person(s) asking the question.

Sorry, but this is really getting out of hand, David. Your continuous
bashing of both FreeBSD developers, the model and the project is really
getting annoying. Your journal on GoBSD is a FreeBSD bashing playground,
and your additions to the Wiki have generally been unfounded claims
which state the DragonFly outperforms FreeBSD.

The fact is this isn't the case. DragonFly still runs for the most part
under the BGL and, while we're on a road to get things implemented
properly before we start optimizing (which is what FreeBSD has been
doing for the past 5 years, with a different idea of what's proper),
there is no proof that we scale any better than anybody else. It is
mentioned in passing, in feel, but I have not seen any benchmarks which
attempt to prove that DragonFly is any better. Please, prove me wrong,
but stop with the claims.

Additionally, I would like to point out that _you_ are a pretty constant
source of hostility towards the FreeBSD project and its developers. Any
chance you get to post something demeaning about the project, you gladly
take. Because you differ in opinion between how certain computing models
should be implemented does not give you the right to state that the
FreeBSD developers are constantly hostile towards anybody who is
interested in backporting anything.

Again, I know for a fact that this isn't the case. From conversations
with several FreeBSD developers, they are quite interested in some of
the work going on in the tree. I know that some of them are looking at
things like IPI messaging. They would like to see how things work when
they are fully implemented before pulling them in.

I think that if we want to have a successful project, we need to be
diplomatic. We especially need to be diplomatic towards FreeBSD, which
is the source of approximately 10 years of code from which our project
is based. I must seriously say that some of these harsh comments from
some of our project's developers make me think twice about wanting to be
a part of the project.

> :The changes have also been brought up to their attention and have been
> :available in cvs for anyone to use for what ever cause.
> :
> :I'm sure this has to be the reason for asking the question in the
> :first place.  Our boot code is still compatible for any current
> :FreeBSD users that would like to switch over to DragonFly, hence no
> :need to back port the changes.

Our boot code also has a strange bug in GCC 3, for some reason.
Considering that's the compiler used in 6-CURRENT and 5-STABLE, I don't
think it's a very wise idea to backport it at the moment.

> :-- 
> :                                            -David
> :                                            Steven David Rhodus
> 
>     Yes, its unfortunate but that's the way the cookie crumbles.  DragonFly
>     was started because of major disagreements in the direction that FreeBSD 
>     development was taking.  I had hoped that our successes would move
>     FreeBSD into reconsidering portions of their model, but that hasn't
>     happened and, frankly, at this point the work done in DragonFly is so
>     extensive that I doubt FreeBSD could port the more interesting things
>     (such as the namecache layer) even if they wanted to.  There are still
>     some things which are simple enough that they could port, and 
>     so obviously advantageous that they *should* port them, such as the
>     IPI messaging, but the fact is that while some FreeBSD developers
>     have an interest in the work, nobody seems interested enough to actually
>     do the work and run the gauntlet to actually get it into FreeBSD.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

I really don't think that's the way the cookie crumbles, as you state
it. FreeBSD has very different design goals and I believe the project
will stick to them. Again, as some developers have said, they would like
to see some of these changes stabilize before importing them into
FreeBSD.

Plenty of people are interested to get some of the DragonFly BSD work
into FreeBSD. Sascha's syscons changes are especially interesting for
the FreeBSD project as they would be quite simple to import compared to
some of our other advancements. I don't think that interest is a lacked
factor in this equation; I think that developer time is. While the
project has a relatively large number of developers, the number of these
who actively contribute and understand the parts of the kernel that are
affected is limited to the few who are already busy with several other
projects.

I would personally like to see some well-defined scalability tests
(perhaps in-kernel hooks would be interesting to examine performance of
some of our more obscure modifications) before I see any more stuff
stating that we perform better than FreeBSD on the same hardware.

I'd also like to see some people work on backporting changes to FreeBSD
and less fingers pointed towards the developers who are actively working
on the FreeBSD project. These are people who have families, jobs and do
already actively contribute. It's unfair to ask these people to drop
what they're doing and import DragonFly's changes. It's also
impractical: one reason that DragonFly exists is to explore how these
changes actually work in practice.

I could generate pages of comparisons that would make it quite clear
that these aren't always good ideas nor reasonable expectations, but I
think that's clear by now.

Kind regards,

Devon H. O'Dell