x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Andi Kleen]

Hallo,

Some administrativa.

In the last time I've posted all patches I sent to Linus
at discuss@x86-64.org at least once. I did this because this list is relatively 
low volume and I tended to get some useful feedback from the people
subscribed here.

However I heard some rumours that I scared people away 
from the list with the many patches.  

I also planned to post patches more often to get better
turnaround for reviews on changed patches.

We still have a patches@x86-64 mailing list on x86-64.org which
is mostly unused. If I moved the big patch floods over there,
would the people who do reviews subscribe there? Please comment.

Also I'll probably start x86_64-* patchkit releases again. Currently
my working dir on ftp.firstfloor.org is directly going into -mm* and 
that sometimes causes problems because it is not as well tested as it would
be if a larger audience has run it. Also there are often non trivial
interactions with the many patches in -mm* and it's hard to figure
out where a problem comes from. So it looks like some separate 
testing would be better.

I hope people would be still interested in running x86_64-* patchkits.

Also my feeling is that I need to involve linux-kernel more. It seems
the majority of x86-64 users don't even know now this mailing list
exists, so they don't review or test the latest releases. Also
the traffic here seems to be less and less now except for me
(or do I just imagine that?) 

I suppose posting all patches there would be too much though, but
at least the announcements should be going there. I still think
it's valuable to have some kind of separate x86-64 list because
linux-kernel is just too much to keep up with and it would
drown valuable bug reports etc. in the general noise.

Any feedback from x86-64 contributors on how to organize this better welcome.

-Andi
 

Re: [discuss] x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Jan Beulich]

>We still have a patches@x86-64 mailing list on x86-64.org which
>is mostly unused. If I moved the big patch floods over there,
>would the people who do reviews subscribe there? Please comment.

I certainly would subscribe there if you want to split things. Depending
on your intentions, I could also switch to send patches there. But if I'm
asked about my preferences, I'd rather see things stay on the discuss
list (as sending patches is generally meant to trigger discussion if need
be).

Jan

Re: [discuss] x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Chris Schlaeger]

It's probably a good idea to move the bulk of the patches to the patches list. 
This will probably increase the attractiveness of the discuss list.

Regarding the testing, I'm trying to find one or two people who can help you 
with this. We have an interest to keep the -mm submissions in good shape. 
Just give me a few more weeks.

Chris

Re: [discuss] x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Ravikiran G Thirumalai]

On Mon, Jun 12, 2006 at 01:07:54PM +0200, Andi Kleen wrote:
> 
> Hallo,
> 
> Some administrativa.
> 
> In the last time I've posted all patches I sent to Linus
> at discuss@x86-64.org at least once. I did this because this list is relatively 
> low volume and I tended to get some useful feedback from the people
> subscribed here.
> 
> However I heard some rumours that I scared people away 
> from the list with the many patches.  
> 
> I also planned to post patches more often to get better
> turnaround for reviews on changed patches.
> 
> We still have a patches@x86-64 mailing list on x86-64.org which
> is mostly unused. If I moved the big patch floods over there,
> would the people who do reviews subscribe there? Please comment.

Given a choice I prefer one list for patches and discussion.  Patches on a 
separate  list will eventually result in discussions of those patches on that 
list, and might even leave out interested parties out of the ensuing discussion.
My 2c;  If a separate patch list is needed for staging patches to mainline, it 
could be something like mm-commits - a broadcast only list by the
maintainer.

Thanks,
Kiran

Re: x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

Hi Andi et al.

On Monday 12 June 2006 21:07, Andi Kleen wrote:
> Hallo,
>
> Some administrativa.
>
> In the last time I've posted all patches I sent to Linus
> at discuss@x86-64.org at least once. I did this because this list is
> relatively low volume and I tended to get some useful feedback from the
> people subscribed here.
>
> However I heard some rumours that I scared people away
> from the list with the many patches.
>
> I also planned to post patches more often to get better
> turnaround for reviews on changed patches.
>
> We still have a patches@x86-64 mailing list on x86-64.org which
> is mostly unused. If I moved the big patch floods over there,
> would the people who do reviews subscribe there? Please comment.

I'll subscribe. (As in reply to the comment below...) I didn't know this site 
or these lists existed.

Regards,

Nigel

> Also I'll probably start x86_64-* patchkit releases again. Currently
> my working dir on ftp.firstfloor.org is directly going into -mm* and
> that sometimes causes problems because it is not as well tested as it would
> be if a larger audience has run it. Also there are often non trivial
> interactions with the many patches in -mm* and it's hard to figure
> out where a problem comes from. So it looks like some separate
> testing would be better.
>
> I hope people would be still interested in running x86_64-* patchkits.
>
> Also my feeling is that I need to involve linux-kernel more. It seems
> the majority of x86-64 users don't even know now this mailing list
> exists, so they don't review or test the latest releases. Also
> the traffic here seems to be less and less now except for me
> (or do I just imagine that?)
>
> I suppose posting all patches there would be too much though, but
> at least the announcements should be going there. I still think
> it's valuable to have some kind of separate x86-64 list because
> linux-kernel is just too much to keep up with and it would
> drown valuable bug reports etc. in the general noise.
>
> Any feedback from x86-64 contributors on how to organize this better
> welcome.
>
> -Andi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Muli Ben-Yehuda]

On Mon, Jun 12, 2006 at 01:07:54PM +0200, Andi Kleen wrote:

> I also planned to post patches more often to get better
> turnaround for reviews on changed patches.

Yes please :-)

> We still have a patches@x86-64 mailing list on x86-64.org which
> is mostly unused. If I moved the big patch floods over there,
> would the people who do reviews subscribe there? Please comment.

I'll go where the patches are, but in general I prefer less lists to
more.

> I hope people would be still interested in running x86_64-*
> patchkits.

Yep.

> Also my feeling is that I need to involve linux-kernel more.

Yes!

Cheers,
Muli

Re: x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Andrew Morton]

On Mon, 12 Jun 2006 13:07:54 +0200
Andi Kleen <ak@suse.de> wrote:

> Also I'll probably start x86_64-* patchkit releases again. Currently
> my working dir on ftp.firstfloor.org is directly going into -mm* and 
> that sometimes causes problems because it is not as well tested as it would
> be if a larger audience has run it. Also there are often non trivial
> interactions with the many patches in -mm* and it's hard to figure
> out where a problem comes from. So it looks like some separate 
> testing would be better.

It's a bit sad to do this - reducing the amount of external testing can only
reduce the code quality and the development speed.

It would, of course, be better to work out _why_ the x86_64 tree has been
more problematic than others, and fix that up.  One way of doing that would
be to do a bit of a post-mortem on previous problems, see if we can come up
with a process fix which would have prevented them.

<does a bit of data collection>

>From the below, a lot of the problems I'm having to fix are simply x86
build/link/depmod breakage.  So more careful build checking on x86-32 would
improve things quite a lot.

There has been some runtime breakage too in Don and Jan's recent patches. 
No magic solution presents itself there - the only way we'll improve things
here is more review and testing by both the originators and the merger(s).




Subject: x86_64: check_addr() cleanups

- Use DMA_32BIT_MASK

- Use %z for size_t

- 80-cols

Subject: x86_64-mm-add-smp-support-on-i386-to-reservation-framework-fix

arch/i386/kernel/nmi.c: In function `setup_p6_watchdog':
arch/i386/kernel/nmi.c:506: `P6_EVNTSEL_ENABLE' undeclared (first use in this function)
arch/i386/kernel/nmi.c:506: (Each undeclared identifier is reported only once
arch/i386/kernel/nmi.c:506: for each function it appears in.)

Subject: x86_64-mm-alternatives-fix

make[1]: *** No rule to make target `arch/x86_64/kernel/alternative.o', needed by `arch/x86_64/kernel/built-in.o'.  Stop.

Subject: x86_64-mm-compat-printk fix

fs/compat.c: In function `compat_printk':
fs/compat.c:65: warning: `return' with no value, in function returning non-void

Subject: x86_64-mm-i386-numa-summit-check fix

arch/i386/kernel/srat.c: In function `get_memcfg_from_srat':
arch/i386/kernel/srat.c:273: error: parse error before "early_printk"

Subject: x86_64-mm-mce_amd-support-for-family-0x10-processors fix

Small compilation fix needed for x86_64 without SMP.

Subject: x86_64-mm-new-northbridge fix

WARNING: "k8_nb_ids" [drivers/char/agp/amd64-agp.ko] undefined!
WARNING: "k8_northbridges" [drivers/char/agp/amd64-agp.ko] undefined!

Subject: x86_64-mm-reliable-stack-trace-support-fix

init/built-in.o(.init.text+0x94a): In function `start_kernel':
: undefined reference to `unwind_init'

Subject: x86_64-mm-reliable-stack-trace-support-non-x86-fix-fix

hack, make it compile.

Subject: x86_64-mm-reliable-stack-trace-support-non-x86-fix

powerpc:

In file included from init/main.c:41:
include/linux/unwind.h:16:24: asm/unwind.h: No such file or directory

Subject: x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86_64-fix

Subject: x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix-fix

notify_die() can be called for various reasons and we don't seem to have an
NMI-specific call back now.  Handle that.

Subject: x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix

Andi, will you please stop committing patches which break the x86 build?  It's
a fairly popular architecture..

Vivek, I never know who maintains the kdump stuff.  Some MAINTAINERS entries
would be nice.

Don, your patch consistently does

	struct die_args *args = (struct die_args *)data;

which is consistently wrong.  `data' is void* and does not need a cast - in
fact it's harmful.

And this patch may simply be wrong - crash_nmi_callback() wants the `cpu'
argument, but we've lost that, so I resorted to raw_smp_processor_id(). 
Calling that on the crashed CPU sounds like a bad idea.

Subject: x86_64-reliable-stack-trace-support-i386 fix

Re: x86_64: x86-64 mailing lists / posting patchkits / x86-64 releases

[Andi Kleen]

> >From the below, a lot of the problems I'm having to fix are simply x86
> build/link/depmod breakage.

It's unfortunate - my testing is definitely focussed on x86-64, but
often the same problem(s) exist in i386 too and of course it has 
to be changed there too.

> So more careful build checking on x86-32 would 
> improve things quite a lot.

I'm already doing it a bit, but one problem is that i386 has a lot 
more build variants than x86-64. I'll try to do better.

BTW I've been actually considering to reduce the variants a bit - e.g. I think
it doesn't make sense anymore to allow x86 kernels without APIC support
(it can be still disabled at runtime with default set by a config).  

-Andi