KDTRACE is gone?

On Wed, Nov 22, 2006 at 12:18:29PM -0800, Darren Pilgrim
wrote:
> Which restrictions do you see preventing the
distribution of a 
> DTRACE-enabled GENERIC kernel binary?  I would refer
you to sections 
> 3.1, 3.4 and 3.5 of the license[1], which state:
> 
> - the CDDL is mandatory on the source code
distribution;
> - the original copyright notice for the original work
must be displayed;
> - binary distributions of CDDL-licensed software may be
relicensed;
> 
> The requirement for the last is that the new license
not conflict with 
> the CDDL.  The CDDL doesn't otherwise restrict use,
modification or 
> distribution and includes the ability to sublicense the
original code as 
> well as and derived works.
> 
> Someone please point out the conflict.  I don't see
one.

FreeBSD's policy is to ship a GENERIC kernel which is
entirely BSD
licensed. Kernel modules and other kernel options can
include other
licenses, but the options enabled in GENERIC must be BSD
licensed.

--
John Birrell
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Wed, Nov 22, 2006, John Birrell wrote:
>> Which restrictions do you see preventing the
distribution of a 
>> DTRACE-enabled GENERIC kernel binary?  I would
refer you to sections 
>> 3.1, 3.4 and 3.5 of the license[1], which state:

>> - the CDDL is mandatory on the source code
distribution;
>> - the original copyright notice for the original
work must be displayed;
>> - binary distributions of CDDL-licensed software
may be relicensed;

>> The requirement for the last is that the new
license not conflict with 
>> the CDDL.  The CDDL doesn't otherwise restrict use,
modification or 
>> distribution and includes the ability to sublicense
the original code as 
>> well as and derived works.

>> Someone please point out the conflict.  I don't see
one.

> FreeBSD's policy is to ship a GENERIC kernel which is
entirely BSD
> licensed. Kernel modules and other kernel options can
include other
> licenses, but the options enabled in GENERIC must be
BSD licensed.

Why isn't importing it as a non-default option acceptable? I
believe a
lot of users would be happy to include it in their custom
kernels.
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Thu, Nov 23, 2006 at 10:36:59PM +0100, Stanislaw Halik
wrote:
> Why isn't importing it as a non-default option
acceptable? I believe a
> lot of users would be happy to include it in their
custom kernels.

Because in 5 years time when there is a production server
that 
can't be rebooted, I want the admins to be able to run
DTrace.
The only way I can guarantee that is by making the ability
to
load DTrace kernel modules available to everyone.

DTrace isn't intended as a toy.

--
John Birrell
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Thursday 23 November 2006 16:58, John Birrell wrote:
> On Thu, Nov 23, 2006 at 10:36:59PM +0100, Stanislaw
Halik wrote:
> > Why isn't importing it as a non-default option
acceptable? I believe a
> > lot of users would be happy to include it in their
custom kernels.
> 
> Because in 5 years time when there is a production
server that 
> can't be rebooted, I want the admins to be able to run
DTrace.
> The only way I can guarantee that is by making the
ability to
> load DTrace kernel modules available to everyone.
> 
> DTrace isn't intended as a toy.

Not having it in GENERIC doesn't mean that.   We have a
lot of machines at 
work and none of them run GENERIC, but a custom kernel
config.  We would just 
add the option to the kernel (just like now we statically
compile in things 
like COMPAT_LINUX which aren't in GENERIC).  I think this
fear is perhaps a 
little inflated relative to reality.

-- 
John Baldwin
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

I definitely don't agree with jb that this is grounds for
not committing
dtrace support. However, his point that the value of dtrace
is greatly
diminished if the user has to actively anticipate a need for
it and then
compile a custom kernel is valid. Developers are just a
little too
comfortable with the notion of "oh, just tell the user
to add FOO to his
config and compile a new kernel!".

            -Kip




On 11/29/06, John Baldwin <jhbfreebsd.org> wrote:
>
> On Thursday 23 November 2006 16:58, John Birrell wrote:
> > On Thu, Nov 23, 2006 at 10:36:59PM +0100,
Stanislaw Halik wrote:
> > > Why isn't importing it as a non-default
option acceptable? I believe a
> > > lot of users would be happy to include it in
their custom kernels.
> >
> > Because in 5 years time when there is a production
server that
> > can't be rebooted, I want the admins to be able to
run DTrace.
> > The only way I can guarantee that is by making the
ability to
> > load DTrace kernel modules available to everyone.
> >
> > DTrace isn't intended as a toy.
>
> Not having it in GENERIC doesn't mean that.   We have a
lot of machines
> at
> work and none of them run GENERIC, but a custom kernel
config.  We would
> just
> add the option to the kernel (just like now we
statically compile in
> things
> like COMPAT_LINUX which aren't in GENERIC).  I think
this fear is perhaps
> a
> little inflated relative to reality.
>
> --
> John Baldwin
> _______________________________________________
> freebsd-currentfreebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
> To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"
>
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

Kip Macy wrote:
> I definitely don't agree with jb that this is grounds for
not committing
> dtrace support.

Numerous people have now explained the issue to you. It's ok
if you
don't agree with them. It's not ok to keep flogging this
horse.

Doug

-- 

    This .signature sanitized for your protection

_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

Thanks Doug for holding me accountable for the duration of
the thread.
Quite the non-sequitur.

        -Kip

On 11/29/06, Doug Barton <dougbfreebsd.org> wrote:
> Kip Macy wrote:
> > I definitely don't agree with jb that
this is grounds for not committing
> > dtrace support.
>
> Numerous people have now explained the issue to you.
It's ok if you
> don't agree with them. It's not ok to keep flogging
this horse.
>
> Doug
>
> --
>
>     This .signature sanitized for your protection
>
>
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"