On 07/01/2013 11:29 PM, Richard Yao wrote:
> On 07/01/2013 09:56 PM, Greg KH wrote:> On Mon, Jul 01, 2013 at
> 09:36:21PM -0400, Richard Yao wrote:
>>> That is because fixes for other filesystems are either held back by a
>>> lack of system kernel updates or held hostage by regressions in newer
>>>
>> Furthermore, should the kernel kernel choose to engage that out-of-tree
>> code, my expectation is that its quality will improve as they do testing
>> and write patches.
>
> What do you mean by this?
I probably should have clarified that there was a typo in that. I meant
"the kernel team", not
On 07/01/2013 09:56 PM, Greg KH wrote:> On Mon, Jul 01, 2013 at
09:36:21PM -0400, Richard Yao wrote:
>> On 07/01/2013 03:23 PM, Greg KH wrote:
>>> On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
>> Q: What about my stable server? I really don't want to run this
>> stuff!
>>
On Mon, Jul 01, 2013 at 09:36:21PM -0400, Richard Yao wrote:
> On 07/01/2013 03:23 PM, Greg KH wrote:
> > On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
> Q: What about my stable server? I really don't want to run this
> stuff!
>
> A: These options would depend on
On 07/01/2013 09:36 PM, Richard Yao wrote:
> On 07/01/2013 03:23 PM, Greg KH wrote:
>> On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
> Q: What about my stable server? I really don't want to run this
> stuff!
>
> A: These options would depend on !CONFIG_VANILLA or
On 07/01/2013 03:23 PM, Greg KH wrote:
> On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
CONFIG_EXPERIMENTAL
>>>
>>> What is CONFIG_VANILL
On Mon, 1 Jul 2013 14:24:54 -0700
Greg KH wrote:
> > but suppose people
> > want BFQ? Why can't we have it in gentoo-sources. It is totally
> > disabled by not selecting CONFIG_BFQ. Selecting it is no different
> > than emerging pf-sources with the same other options ported over.
>
> Until you
On 07/01/2013 05:30 PM, Fabio Erculiani wrote:
On Mon, Jul 1, 2013 at 11:26 PM, Anthony G. Basile wrote:
I'm pretty sure I hit a genuine deadlock with it. I've been trying to
reproduce with debugging on but nothing yet.
But, having said that:
BFQ [Experimtental]
This introduced an experime
On 07/01/2013 05:24 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 05:17:07PM -0400, Anthony G. Basile wrote:
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options
On Mon, Jul 1, 2013 at 11:26 PM, Anthony G. Basile wrote:
>
>
> I'm pretty sure I hit a genuine deadlock with it. I've been trying to
> reproduce with debugging on but nothing yet.
>
> But, having said that:
>
> BFQ [Experimtental]
>
> This introduced an experimental io scheduler. Have fun with
On Mon, Jul 01, 2013 at 05:17:07PM -0400, Anthony G. Basile wrote:
> On 07/01/2013 03:23 PM, Greg KH wrote:
> >On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
> Q: What about my stable server? I really don't want to run this
> stuff!
>
> A: These options would depend o
On 07/01/2013 04:25 PM, Fabio Erculiani wrote:
On Mon, Jul 1, 2013 at 10:14 PM, Markos Chandras wrote:
[...]
It's really scary to have the BFQ in a stable gentoo-sources ebuild.
BFQ is not that scary, it's "just" an iosched (and it's quite easy to
write an iosched), what could possibly go wro
On 07/01/2013 03:24 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
Tom, you already know my opinion because we discussed it. I'm all
for it. Just a reminder: there's always problems somewhere in the
kernel which can be triggered by various options. The k
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
CONFIG_EXPERIMENTAL
What is CONFIG_VANILLA? I don't see that in the up
On Mon, 1 Jul 2013 21:14:45 +0100
Markos Chandras wrote:
> And besides that, I am sure that 98% of our users out there do not
> know they run a (heavily?) modified upstream kernel when they emerge
> the official/supported gentoo-sources.
This point I do understand.
> The transition between the
On Mon, Jul 1, 2013 at 10:24 PM, Christoph Junghans wrote:
> 2013/7/1 Fabio Erculiani :
>> I believe that end users would benefit more from kernel binary ebuilds
>> (ebuilds building an actual kernel with an official config), rather
>> than all this.
> +1
>
> The "binary" use flag for sys-kernel/*
On Mon, Jul 1, 2013 at 10:14 PM, Markos Chandras wrote:
>
[...]
> It's really scary to have the BFQ in a stable gentoo-sources ebuild.
BFQ is not that scary, it's "just" an iosched (and it's quite easy to
write an iosched), what could possibly go wrong?
Jokes apart, I've been using it in produc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 03:55 PM, Fabio Erculiani wrote:
> I believe that end users would benefit more from kernel binary ebuilds
> (ebuilds building an actual kernel with an official config), rather
> than all this.
>
++
- -ZC
-BEGIN PGP SIGNATURE-
Ve
2013/7/1 Fabio Erculiani :
> I believe that end users would benefit more from kernel binary ebuilds
> (ebuilds building an actual kernel with an official config), rather
> than all this.
+1
The "binary" use flag for sys-kernel/*-sources in Funtoo implements
exactly that.
>
> --
> Fabio Erculiani
On 1 July 2013 20:09, Matthew Summers wrote:
> On Mon, Jul 1, 2013 at 1:56 PM, Tom Wijsman wrote:
>> On Mon, 1 Jul 2013 19:38:48 +0100
>> Markos Chandras wrote:
>>
>>> I certainly don't feel safe anymore running non-upstream code in
>>> production boxes.
>>
>> You don't run it unless you explici
On Mon, 1 Jul 2013 21:55:23 +0200
Fabio Erculiani wrote:
> I believe that end users would benefit more from kernel binary ebuilds
> (ebuilds building an actual kernel with an official config), rather
> than all this.
>
There's been a start on this, but we're looking at you now; feel free
to com
On Mon, Jul 1, 2013 at 9:59 PM, Pacho Ramos wrote:
> El lun, 01-07-2013 a las 21:55 +0200, Fabio Erculiani escribió:
>> I believe that end users would benefit more from kernel binary ebuilds
>> (ebuilds building an actual kernel with an official config), rather
>> than all this.
>>
>
> I don't see
El lun, 01-07-2013 a las 21:55 +0200, Fabio Erculiani escribió:
> I believe that end users would benefit more from kernel binary ebuilds
> (ebuilds building an actual kernel with an official config), rather
> than all this.
>
I don't see them exclusionary, look different issues to me :/ (with
com
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
--
Fabio Erculiani
On Mon, 1 Jul 2013 12:33:30 -0700
Greg KH wrote:
> On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote:
> > On Mon, 1 Jul 2013 14:09:57 -0500
> > Matthew Summers wrote:
> > > If the patchset patches the kernel's core, it doesn't matter what
> > > CONFIG_* option is set the core kernel co
On Mon, 1 Jul 2013 12:24:36 -0700
Greg KH wrote:
> On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
> > Tom, you already know my opinion because we discussed it. I'm all
> > for it. Just a reminder: there's always problems somewhere in the
> > kernel which can be triggered by
On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote:
> On Mon, 1 Jul 2013 14:09:57 -0500
> Matthew Summers wrote:
> > If the patchset patches the kernel's core, it doesn't matter what
> > CONFIG_* option is set the core kernel code _has_now_been_changed_.
> > This is the crux of the argume
On Mon, 1 Jul 2013 12:23:24 -0700
Greg KH wrote:
> > Earlier I mentioned "3) The patch should not affect the build by
> > default."; if it does, we have to adjust it to not do that, this is
> > something that can be easily scripted. It's just a matter of
> > embedding each + block in the diff wit
On Mon, 1 Jul 2013 14:09:57 -0500
Matthew Summers wrote:
> I think the point was well-made by grehkh.
You missed my response to that point.
> If the patchset patches the kernel's core, it doesn't matter what
> CONFIG_* option is set the core kernel code _has_now_been_changed_.
> This is the cru
On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
> Tom, you already know my opinion because we discussed it. I'm all
> for it. Just a reminder: there's always problems somewhere in the
> kernel which can be triggered by various options. The kernel is not
> one big take it or le
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
> > > Q: What about my stable server? I really don't want to run this
> > > stuff!
> > >
> > > A: These options would depend on !CONFIG_VANILLA or
> > > CONFIG_EXPERIMENTAL
> >
> > What is CONFIG_VANILLA? I don't see that in the upstre
On Mon, Jul 1, 2013 at 1:56 PM, Tom Wijsman wrote:
> On Mon, 1 Jul 2013 19:38:48 +0100
> Markos Chandras wrote:
>
>> I certainly don't feel safe anymore running non-upstream code in
>> production boxes.
>
> You don't run it unless you explicitly tick on that you want
> experimental functionality
On Mon, 01 Jul 2013 14:30:51 -0400
"Anthony G. Basile" wrote:
> I was going to say depend on CONFIG_EXPERIMENTAL in
> Kconfig, but this is deprecated. See scripts/checkpatch.pl
Yes, I think it wasn't clear from my first post; but the intention was
to introduce such option under the Gentoo distr
On Mon, 1 Jul 2013 19:38:48 +0100
Markos Chandras wrote:
> I certainly don't feel safe anymore running non-upstream code in
> production boxes.
You don't run it unless you explicitly tick on that you want
experimental functionality _as well as_ the optional features in
question; as I said earlie
On Mon, 1 Jul 2013 11:17:49 -0700
Greg KH wrote:
> > Meet CONFIG_DEVTMPFS; ...
>
> This is not the only build option that users must enable to get a
> booting system by far. So why single this one out?
Because it is an example. Later on I explicitly mention "There are a
small set of other vari
On 1 July 2013 19:17, Greg KH wrote:
>
> greg "stick to the vanilla-sources" k-h
>
Before these changes were introduced, the gentoo-sources and
vanilla-sources were quite similar in the sense that genpatches used
to contain
patches already in Linus' tree. However, given that gentoo-sources
will b
On 07/01/2013 11:20 AM, Jeff Horelick wrote:
On 1 July 2013 10:41, Tom Wijsman wrote:
Hello
Please reply to gentoo-dev in case ML daemon changes Reply-To.
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can deduplicate *-sources ma
On Mon, Jul 01, 2013 at 04:41:49PM +0200, Tom Wijsman wrote:
> This problem is not only visible for patches, but also in the config.
>
> Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're
> telling users to enable it in some places, in the handbook it's a single
> line you must
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 01:35 PM, Tom Wijsman wrote:
> On Mon, 01 Jul 2013 12:20:09 -0400
> "Rick \"Zero_Chaos\" Farina" wrote:
>
>> Some patches are reasonably easy to combine, such as genpatches and
>> aufs. Some patches are difficult to combine, such as ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 01 Jul 2013 12:20:09 -0400
"Rick \"Zero_Chaos\" Farina" wrote:
> Some patches are reasonably easy to combine, such as genpatches and
> aufs. Some patches are difficult to combine, such as hardened and *.
> When you combine hardened patches a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 06:20 PM, Rick "Zero_Chaos" Farina wrote:
> On 07/01/2013 10:41 AM, Tom Wijsman wrote:
>
>> What does a patch introducing new features really do? Or rather,
>> what should it do when we add it? Let me summarize:
>
>> 1) The features sho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 10:41 AM, Tom Wijsman wrote:
> Hello
>
>
> Please reply to gentoo-dev in case ML daemon changes Reply-To.
>
>
> ### TL; DR ###
>
> By introducing feature patches which menu options are disabled by
> default to genpatches, we can dedu
On 1 July 2013 10:41, Tom Wijsman wrote:
> Hello
>
>
> Please reply to gentoo-dev in case ML daemon changes Reply-To.
>
>
> ### TL; DR ###
>
> By introducing feature patches which menu options are disabled by
> default to genpatches, we can deduplicate *-sources maintainers as well
> as large grou
On 1 July 2013 22:41, Tom Wijsman wrote:
>
> ### TL; DR ###
>
> By introducing feature patches which menu options are disabled by
> default to genpatches, we can deduplicate *-sources maintainers as well
> as large groups of users work. By introducing a distribution section
> in the menuconfig, we
Hello
Please reply to gentoo-dev in case ML daemon changes Reply-To.
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can deduplicate *-sources maintainers as well
as large groups of users work. By introducing a distribution section
in
45 matches
Mail list logo
