On Wed, Nov 28, 2007 at 03:57:47PM -0800, Jeremy Fitzhardinge wrote:
> Adrian Bunk wrote:
> > This does not apply since we do not have a stable in-kernel API, and
> > therefore changes to the in-kernel API can by definition not be
> > regressions.
> >
> > 2.6.24 most likely contains hundreds of
On Wed, Nov 28, 2007 at 03:57:47PM -0800, Jeremy Fitzhardinge wrote:
Adrian Bunk wrote:
This does not apply since we do not have a stable in-kernel API, and
therefore changes to the in-kernel API can by definition not be
regressions.
2.6.24 most likely contains hundreds of changes and
Adrian Bunk wrote:
> This does not apply since we do not have a stable in-kernel API, and
> therefore changes to the in-kernel API can by definition not be
> regressions.
>
> 2.6.24 most likely contains hundreds of changes and removals of
> in-kernel APIs that existed in 2.6.23.
>
> Are you
On Wed, Nov 28, 2007 at 01:15:39PM -0800, Jeremy Fitzhardinge wrote:
> Adrian Bunk wrote:
> > On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
>...
> >> 2. It's a regression from previous kernels, which would work these
> >>modules even with CONFIG_PARAVIRT enabled.
> >>
Adrian Bunk wrote:
> On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
>
>> ...
>> Christoph Hellwig objects to this patch on the grounds that modules
>> shouldn't be using these operations anyway. I don't think this is a
>> particularly good reason to reject the patch, for
On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
>...
> Christoph Hellwig objects to this patch on the grounds that modules
> shouldn't be using these operations anyway. I don't think this is a
> particularly good reason to reject the patch, for several reasons:
>
> 1. These
On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
...
Christoph Hellwig objects to this patch on the grounds that modules
shouldn't be using these operations anyway. I don't think this is a
particularly good reason to reject the patch, for several reasons:
1. These
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
...
Christoph Hellwig objects to this patch on the grounds that modules
shouldn't be using these operations anyway. I don't think this is a
particularly good reason to reject the patch, for several
On Wed, Nov 28, 2007 at 01:15:39PM -0800, Jeremy Fitzhardinge wrote:
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 02:57:30PM -0800, Jeremy Fitzhardinge wrote:
...
2. It's a regression from previous kernels, which would work these
modules even with CONFIG_PARAVIRT enabled.
...
Adrian Bunk wrote:
This does not apply since we do not have a stable in-kernel API, and
therefore changes to the in-kernel API can by definition not be
regressions.
2.6.24 most likely contains hundreds of changes and removals of
in-kernel APIs that existed in 2.6.23.
Are you seriously
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try to use mmu_ops and cpu_ops. This restores
the old behaviour, and makes it consistent with the
non-CONFIG_PARAVIRT case.
Tobias Powalowski <[EMAIL PROTECTED]> reports:
> commit to .24 tree:
>
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try to use mmu_ops and cpu_ops. This restores
the old behaviour, and makes it consistent with the
non-CONFIG_PARAVIRT case.
Tobias Powalowski [EMAIL PROTECTED] reports:
commit to .24 tree:
At Mon, 19 Nov 2007 17:14:15 -0800,
Jeremy Fitzhardinge wrote:
>
> Takashi Iwai wrote:
> > I took at this problem (as I have an nvidia card on one of my
> > workstations), and found out that the following suffer from
> > EXPORT_SYMBOL_GPL changes:
> >
>
> Which kernel version are you using?
Takashi Iwai wrote:
> I took at this problem (as I have an nvidia card on one of my
> workstations), and found out that the following suffer from
> EXPORT_SYMBOL_GPL changes:
>
Which kernel version are you using? This is different in .24-rc
compared to .23.
> * local_disable_irq(),
At Tue, 13 Nov 2007 16:51:04 -0800,
Zachary Amsden wrote:
>
> On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote:
> > On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
> > > Subject: x86/paravirt: revert exports to restore old behaviour
> > >
> > > Subdividing the
At Tue, 13 Nov 2007 16:51:04 -0800,
Zachary Amsden wrote:
On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote:
On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
Subject: x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops
Takashi Iwai wrote:
I took at this problem (as I have an nvidia card on one of my
workstations), and found out that the following suffer from
EXPORT_SYMBOL_GPL changes:
Which kernel version are you using? This is different in .24-rc
compared to .23.
* local_disable_irq(),
At Mon, 19 Nov 2007 17:14:15 -0800,
Jeremy Fitzhardinge wrote:
Takashi Iwai wrote:
I took at this problem (as I have an nvidia card on one of my
workstations), and found out that the following suffer from
EXPORT_SYMBOL_GPL changes:
Which kernel version are you using? This is
Christoph Hellwig wrote:
> NACK, both of these are internal and graphics drivers should not be
> using them.
>
I don't feel very strongly about it either way. I think the two
arguments for it are:
1. it's a regression compared to previous kernels
2. it's a visible difference between
On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote:
> On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
> > Subject: x86/paravirt: revert exports to restore old behaviour
> >
> > Subdividing the paravirt_ops structure caused a regression in certain
> > non-GPL modules
On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
> Subject: x86/paravirt: revert exports to restore old behaviour
>
> Subdividing the paravirt_ops structure caused a regression in certain
> non-GPL modules which try to use mmu_ops and cpu_ops. This restores
> the old
Subject: x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try to use mmu_ops and cpu_ops. This restores
the old behaviour, and makes it consistent with the
non-CONFIG_PARAVIRT case.
Tobias's mail:
>
Subject: x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try to use mmu_ops and cpu_ops. This restores
the old behaviour, and makes it consistent with the
non-CONFIG_PARAVIRT case.
Tobias's mail:
On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
Subject: x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try to use mmu_ops and cpu_ops. This restores
the old behaviour,
On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote:
On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote:
Subject: x86/paravirt: revert exports to restore old behaviour
Subdividing the paravirt_ops structure caused a regression in certain
non-GPL modules which try
Christoph Hellwig wrote:
NACK, both of these are internal and graphics drivers should not be
using them.
I don't feel very strongly about it either way. I think the two
arguments for it are:
1. it's a regression compared to previous kernels
2. it's a visible difference between
26 matches
Mail list logo
