On Tue, 21 Aug 2012 10:43:59 -0700, Randy Dunlap wrote:
> On 08/19/2012 07:51 PM, Rusty Russell wrote:
>
> > On Tue, 14 Aug 2012 10:41:42 -0700, Randy Dunlap
> > wrote:
> >> On 08/14/2012 08:17 AM, Richard Weinberger wrote:
> >>
> >>> Am 14.08.2012 17:15, schrieb David Howells:
> How about
On 08/19/2012 07:51 PM, Rusty Russell wrote:
> On Tue, 14 Aug 2012 10:41:42 -0700, Randy Dunlap wrote:
>> On 08/14/2012 08:17 AM, Richard Weinberger wrote:
>>
>>> Am 14.08.2012 17:15, schrieb David Howells:
How about this then?
David
---
diff --git a/arch/x86/um/Kconfig b
On Tue, 14 Aug 2012 10:41:42 -0700, Randy Dunlap wrote:
> On 08/14/2012 08:17 AM, Richard Weinberger wrote:
>
> > Am 14.08.2012 17:15, schrieb David Howells:
> >> How about this then?
> >>
> >> David
> >> ---
> >> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
> >> index 9926e11..a4b0c10
On 08/14/2012 08:17 AM, Richard Weinberger wrote:
> Am 14.08.2012 17:15, schrieb David Howells:
>> How about this then?
>>
>> David
>> ---
>> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
>> index 9926e11..a4b0c10 100644
>> --- a/arch/x86/um/Kconfig
>> +++ b/arch/x86/um/Kconfig
>> @@ -21,
Am 14.08.2012 17:15, schrieb David Howells:
> How about this then?
>
> David
> ---
> diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
> index 9926e11..a4b0c10 100644
> --- a/arch/x86/um/Kconfig
> +++ b/arch/x86/um/Kconfig
> @@ -21,9 +21,11 @@ config 64BIT
> config X86_32
> def_bool !6
How about this then?
David
---
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index 9926e11..a4b0c10 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -21,9 +21,11 @@ config 64BIT
config X86_32
def_bool !64BIT
select HAVE_AOUT
+ select MODULES_USE_ELF_RE
David Howells wrote:
> > I think arch/x86/um/Kconfig makes more sense.
> ...
> It doesn't exist. Should I create it?
Bah. Helps if I read your message more closely.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
Am 14.08.2012 17:06, schrieb David Howells:
> Richard Weinberger wrote:
>
>> I think arch/x86/um/Kconfig makes more sense.
>
> warthog>ls arch/um
> defconfig Kconfig.common Kconfig.um Makefile-os-Linux scripts/
> drivers/ Kconfig.debug kernel/Makefile-ppc sys-ia64/
Richard Weinberger wrote:
> I think arch/x86/um/Kconfig makes more sense.
warthog>ls arch/um
defconfig Kconfig.common Kconfig.um Makefile-os-Linux scripts/
drivers/ Kconfig.debug kernel/Makefile-ppc sys-ia64/
include/ Kconfig.net Makefile Makefile-sk
Am 14.08.2012 16:54, schrieb David Howells:
> David Howells wrote:
>
>> I can certainly try pasting the lines from x86/Kconfig to uml/Kconfig.common
>> to switch the REL/RELA bits, but it would be nice to get this from the actual
>> arch if possible to reduce redundancy.
>
> The attached patch w
Am 14.08.2012 16:51, schrieb David Howells:
> Richard Weinberger wrote:
>
>> Is there no way to get this information from the UML subarch?
>> Which is currently X86_32 or X86_64.
>
> Or ppc or ia64? Or are those defunct?
Those are defunct.
AFAIK viro is working on UML/ppc64.
> I can certainly
David Howells wrote:
> I can certainly try pasting the lines from x86/Kconfig to uml/Kconfig.common
> to switch the REL/RELA bits, but it would be nice to get this from the actual
> arch if possible to reduce redundancy.
The attached patch works.
David
---
diff --git a/arch/um/Kconfig.common b/
Richard Weinberger wrote:
> Is there no way to get this information from the UML subarch?
> Which is currently X86_32 or X86_64.
Or ppc or ia64? Or are those defunct?
I can certainly try pasting the lines from x86/Kconfig to uml/Kconfig.common
to switch the REL/RELA bits, but it would be nice
Am 14.08.2012 16:26, schrieb David Howells:
> Rusty Russell wrote:
>
CC arch/x86/um/../kernel/module.o
arch/x86/um/../kernel/module.c:96:5: error: redefinition of
'apply_relocate_add'
include/linux/moduleloader.h:64:19: note: previous definition of
'apply_relocat
Rusty Russell wrote:
> > > CC arch/x86/um/../kernel/module.o
> > > arch/x86/um/../kernel/module.c:96:5: error: redefinition of
> > > 'apply_relocate_add'
> > > include/linux/moduleloader.h:64:19: note: previous definition of
> > > 'apply_relocate_add' was here
> > > make[2]: *** [arch/x
On Mon, 13 Aug 2012 10:00:16 -0700, Randy Dunlap wrote:
> On 07/26/2012 08:18 AM, Randy Dunlap wrote:
>
> > On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
> >
> >> Hi all,
> >>
> >> Please do not add anything to linux-next included branches/series that is
> >> destined for v3.7 until after v3.6
On 07/26/2012 08:18 AM, Randy Dunlap wrote:
> On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Please do not add anything to linux-next included branches/series that is
>> destined for v3.7 until after v3.6-rc1 is released.
>>
>> Reminder: do not rebase your branches before aski
On Thu, 2012-07-26 at 08:43 -0700, Randy Dunlap wrote:
> On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
>
> > Hi all,
> >
> >
> > Changes since 20120725:
> >
> >
>
>
> on x86_64:
>
> CC [M] drivers/vfio/pci/vfio_pci_intrs.o
> drivers/vfio/pci/vfio_pci_intrs.c: In function 'virqfd_enable
On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
> Hi all,
>
>
> Changes since 20120725:
>
>
on x86_64:
CC [M] drivers/vfio/pci/vfio_pci_intrs.o
drivers/vfio/pci/vfio_pci_intrs.c: In function 'virqfd_enable':
drivers/vfio/pci/vfio_pci_intrs.c:142:2: error: implicit declaration of
functio
On 07/25/2012 10:04 PM, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add anything to linux-next included branches/series that is
> destined for v3.7 until after v3.6-rc1 is released.
>
> Reminder: do not rebase your branches before asking Linus to pull them ...
>
> Changes since 20120725
Hi all,
Please do not add anything to linux-next included branches/series that is
destined for v3.7 until after v3.6-rc1 is released.
Reminder: do not rebase your branches before asking Linus to pull them ...
Changes since 20120725:
The libata tree lost its merge fix patch.
The scsi tree lost
21 matches
Mail list logo
