I definitely don't agree with jb_at_ 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 <jhb_at_freebsd.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-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Wed Nov 29 2006 - 17:43:04 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:03 UTC