* [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070210214309.GP12958@stusta.de> @ 2007-02-11 1:47 ` James Bottomley [not found] ` <1171158436.3373.51.camel@mulgrave.il.steeleye.com> 1 sibling, 0 replies; 9+ messages in thread From: James Bottomley @ 2007-02-11 1:47 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, Linus Torvalds, Parisc List On Sat, 2007-02-10 at 22:43 +0100, Adrian Bunk wrote: > First of all thanks to Andrew for forwarding this email to me - it's > otherwise a bit hard to defend against an email that doesn't reach me. I think if you read the email you'll find it didn't actually attack you at all ... I was careful only to ask for a change of policy before accepting a patch that does nothing but make a function static. > >... > > > > We're going to need this one reverting for parisc. If you remember > > we've been trying to push a compat_sys_rt_sigqueueinfo but Andi keeps > > objecting, so it's remained local to our tree (an hence so has the > > symbol usage). > > > > However, can we *please* stop this indiscriminate rampage through all > > the sybsystems making things static just because we can. The true test > > of whether a symbol should be static or not is whether it forms part of > > a sensible API or not. For subsystems with a well defined API, this is > > quite easy (although it hasn't prevented attempts to make even those > > symbols static). For some of our core subsystems (like the kernel API > > in this case) it's much less well defined ... although we have a good > > solid white area of things that must be part of the API and a good solid > > black area of things that mustn't, we still have a large grey area which > > things like kill_proc_info() fall into. > > > > For any person who wants to make a static symbol exported, we force an > > explanation out of them about what they're trying to do and why. Might > > I suggest we apply the same standard to anyone trying to make something > > static? i.e. they need to explain clearly why the symbol shouldn't be > > part of any rational API. > > And by how many percent will this bloat the kernel more in the long > term? That's something I'm more than willing to live with if the tradeoff is we think before making things static. > > Thanks, > > > > James > > Date: Thu, 8 Feb 2007 22:33:21 -0500 > > From: Kyle McMartin <kyle@mcmartin.ca> > > To: Matthew Wilcox <matthew@wil.cx> > > Cc: Kyle McMartin <kyle@mcmartin.ca>, > > parisc-linux <parisc-linux@lists.parisc-linux.org> > > Subject: Re: [parisc-linux] 64-bit kernel broken. > > > > On Thu, Feb 08, 2007 at 08:24:54PM -0700, Matthew Wilcox wrote: > > > On Thu, Feb 08, 2007 at 07:43:14PM -0500, Kyle McMartin wrote: > > > > > Right. This got inadvertantly reverted with some other stuff. Fixed in a > > > > > second. > > > > > > > > Fixed in 1736b4bbf2bbfebaad06114d569f3617517524d1. > > > > > > make.err:/home/willy/nicol-2.6/arch/parisc/kernel/signal32.c:519: > > > warning: implicit declaration of function 'kill_proc_info' > > > make.err:(.text.compat_sys_rt_sigqueueinfo+0x80): undefined reference to > > > `kill_proc_info' > > > > > > > Guess who came home for Christmas > > > > commit d3228a887cae75ef2b8b1211c31c539bef5a5698 > > Author: Adrian Bunk <bunk@stusta.de> > > Date: Wed Dec 6 20:38:22 2006 -0800 > > > > [PATCH] make kernel/signal.c:kill_proc_info() static > > > > Signed-off-by: Adrian Bunk <bunk@stusta.de> > > Signed-off-by: Andrew Morton <akpm@osdl.org> > > Signed-off-by: Linus Torvalds <torvalds@osdl.org> > > There are hundreds of such patches of mine that got included in Linus' > tree and that didn't cause problems. Besides making the kernel smaller, > they regularly find "it should have been used" bugs. > In this one case, a patch that made something static that wasn't used > from other files during the over 9 years of it's existence clashes with > another patch that adds a user. I'm really not that interested in the number of users ... that's only one part of the measure of the relevance of an API. However, if we're actually going to revoke an API I'd like it to be done on the API's merits (or lack of them) rather than simply whether there are any current in-kernel users. > Can we agree that it's not a usual case that the first user gets added > after more than 9 years? Actually, the compat_rtsiginfo patch has been argued over and honed for at least 3 years, so I'd say your statement isn't necessarily correct. For some of its life, it was even in -mm. > And making it global again when a user gets included isn't really that > hard. The life of a non-x86 architecture maintainer is hard ... it involves having lots of volunteers tirelessly chasing down things that broke during the big two week merge frenzy. It would be really helpful if things like this didn't add to that burden. James _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <1171158436.3373.51.camel@mulgrave.il.steeleye.com>]
* [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <1171158436.3373.51.camel@mulgrave.il.steeleye.com> @ 2007-02-11 4:19 ` Andrew Morton [not found] ` <20070210201911.7a16b5f3.akpm@linux-foundation.org> ` (2 subsequent siblings) 3 siblings, 0 replies; 9+ messages in thread From: Andrew Morton @ 2007-02-11 4:19 UTC (permalink / raw) To: James Bottomley; +Cc: Linus Torvalds, Parisc List, Adrian Bunk On Sat, 10 Feb 2007 19:47:16 -0600 James Bottomley <James.Bottomley@SteelEye.com> wrote: > The life of a non-x86 architecture maintainer is hard ... it involves > having lots of volunteers tirelessly chasing down things that broke > during the big two week merge frenzy. They should test -mm kernels and report any problems so those problems don't get into mainline. My attempt to build a working parisc cross-compiler failed, which doesn't help. _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20070210201911.7a16b5f3.akpm@linux-foundation.org>]
* Re: [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070210201911.7a16b5f3.akpm@linux-foundation.org> @ 2007-02-11 7:25 ` Grant Grundler [not found] ` <20070211072552.GC22248@colo.lackof.org> 1 sibling, 0 replies; 9+ messages in thread From: Grant Grundler @ 2007-02-11 7:25 UTC (permalink / raw) To: Andrew Morton; +Cc: James Bottomley, Linus Torvalds, Parisc List On Sat, Feb 10, 2007 at 08:19:11PM -0800, Andrew Morton wrote: > On Sat, 10 Feb 2007 19:47:16 -0600 James Bottomley <James.Bottomley@SteelEye.com> wrote: > > > The life of a non-x86 architecture maintainer is hard ... it involves > > having lots of volunteers tirelessly chasing down things that broke > > during the big two week merge frenzy. > > They should test -mm kernels and report any problems so those problems > don't get into mainline. We probably could start doing that for some of the build flavors (32 bit). Kyle/Willy have done a great job of reducing the diff between kernel.org and parisc-linux.org trees. > My attempt to build a working parisc cross-compiler failed, which doesn't help. I appreciate your attempt to build parisc-linux. Could you post which source tree and which build command line you used? I'm pretty sure this can be fixed. We've used cross compilers in the past so I know it's worked before. thanks, grant > _______________________________________________ > parisc-linux mailing list > parisc-linux@lists.parisc-linux.org > http://lists.parisc-linux.org/mailman/listinfo/parisc-linux _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20070211072552.GC22248@colo.lackof.org>]
* Re: [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070211072552.GC22248@colo.lackof.org> @ 2007-02-11 7:44 ` Andrew Morton [not found] ` <20070210234424.500ed1c9.akpm@linux-foundation.org> 1 sibling, 0 replies; 9+ messages in thread From: Andrew Morton @ 2007-02-11 7:44 UTC (permalink / raw) To: Grant Grundler; +Cc: James Bottomley, Linus Torvalds, Parisc List On Sun, 11 Feb 2007 00:25:52 -0700 Grant Grundler <grundler@parisc-linux.org> wrote: > > My attempt to build a working parisc cross-compiler failed, which doesn't help. > > I appreciate your attempt to build parisc-linux. > Could you post which source tree and which build command line you used? It was maybe a year back - I spent a couple of days wrestling with crosstool, ended up with _some_ useful crosscompilers (alpha, arm, i386, ia64, m68k, mips, s390, sparc, sparc64 and x86_64). parisc was one of the ones which I gave up on but I do not have a record of what the problem was, sorry. It would have been a toolchain problem, not a kernel problem. The most usual failure mode was simply inability to find any combination of gcc/binutils/glibc which could be compiled. > I'm pretty sure this can be fixed. > We've used cross compilers in the past so I know it's worked before. I say this a lot, but... It is in the interests of arch maintainers to help others to build cross-compilers. If someone were to prepare a web page (or even a script) which could be used to generate a kernel cross-compilation environment for parisc then the parisc maintainers would see a lot less breakage. For one, I do allmodconfig on all architectures on all patches I get (and that includes all the git trees). If stuff breaks, the breaker gets to hear about it, before it gets merged. _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20070210234424.500ed1c9.akpm@linux-foundation.org>]
* Re: [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070210234424.500ed1c9.akpm@linux-foundation.org> @ 2007-02-11 16:54 ` Kyle McMartin [not found] ` <20070211075738.GD22248@colo.lackof.org> [not found] ` <20070211165405.GA4050@athena.road.mcmartin.ca> 2 siblings, 0 replies; 9+ messages in thread From: Kyle McMartin @ 2007-02-11 16:54 UTC (permalink / raw) To: Andrew Morton; +Cc: James Bottomley, Linus Torvalds, Parisc List On Sat, Feb 10, 2007 at 11:44:24PM -0800, Andrew Morton wrote: > I say this a lot, but... It is in the interests of arch maintainers to > help others to build cross-compilers. If someone were to prepare a web > page (or even a script) which could be used to generate a kernel > cross-compilation environment for parisc then the parisc maintainers would > see a lot less breakage. > Heh, I put this up last time you asked. :) http://kyle.mcmartin.ca/hppa64-hp-linux-gcc-3.4.tar Cheers, Kyle _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20070211075738.GD22248@colo.lackof.org>]
* Re: [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070211075738.GD22248@colo.lackof.org> @ 2007-02-12 11:42 ` Thibaut VARENE 0 siblings, 0 replies; 9+ messages in thread From: Thibaut VARENE @ 2007-02-12 11:42 UTC (permalink / raw) To: Grant Grundler Cc: James Bottomley, Andrew Morton, Linus Torvalds, Parisc List On 2/11/07, Grant Grundler <grundler@parisc-linux.org> wrote: > On Sat, Feb 10, 2007 at 11:44:24PM -0800, Andrew Morton wrote: > > I say this a lot, but... It is in the interests of arch maintainers to > > help others to build cross-compilers. If someone were to prepare a web > > page (or even a script) which could be used to generate a kernel > > cross-compilation environment for parisc then the parisc maintainers would > > see a lot less breakage. > > Agreed. > We have such a page: > http://www.parisc-linux.org/toolchain/PARISC-Linux-XC-HOWTO.html > > (link "Build XC" from www.p-l.o homepage) This is unfortunately rather outdated... I wonder if it'd still work. I've built a parisc xcompiler a while ago using toolchain-source/tpkg-make, I'll try to do that again and make a receipe available online. HTH -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20070211165405.GA4050@athena.road.mcmartin.ca>]
* Re: [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070211165405.GA4050@athena.road.mcmartin.ca> @ 2007-02-12 17:15 ` Andrew Morton 0 siblings, 0 replies; 9+ messages in thread From: Andrew Morton @ 2007-02-12 17:15 UTC (permalink / raw) To: Kyle McMartin; +Cc: James.Bottomley, torvalds, parisc-linux > On Sun, 11 Feb 2007 11:54:05 -0500 Kyle McMartin <kyle@mcmartin.ca> wrote: > On Sat, Feb 10, 2007 at 11:44:24PM -0800, Andrew Morton wrote: > > I say this a lot, but... It is in the interests of arch maintainers to > > help others to build cross-compilers. If someone were to prepare a web > > page (or even a script) which could be used to generate a kernel > > cross-compilation environment for parisc then the parisc maintainers would > > see a lot less breakage. > > > > Heh, I put this up last time you asked. :) > > http://kyle.mcmartin.ca/hppa64-hp-linux-gcc-3.4.tar > Drat, I have no memory of that. Thanks.. _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
* [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <1171158436.3373.51.camel@mulgrave.il.steeleye.com> 2007-02-11 4:19 ` Andrew Morton [not found] ` <20070210201911.7a16b5f3.akpm@linux-foundation.org> @ 2007-02-11 7:35 ` Adrian Bunk [not found] ` <20070211073520.GR12958@stusta.de> 3 siblings, 0 replies; 9+ messages in thread From: Adrian Bunk @ 2007-02-11 7:35 UTC (permalink / raw) To: James Bottomley; +Cc: Andrew Morton, Linus Torvalds, Parisc List On Sat, Feb 10, 2007 at 07:47:16PM -0600, James Bottomley wrote: > On Sat, 2007-02-10 at 22:43 +0100, Adrian Bunk wrote: > > First of all thanks to Andrew for forwarding this email to me - it's > > otherwise a bit hard to defend against an email that doesn't reach me. > > I think if you read the email you'll find it didn't actually attack you > at all ... I was careful only to ask for a change of policy before > accepting a patch that does nothing but make a function static. Then let's call it "trying to establish rule forbidding something established without even informing the people whose actions you want to become forbidden". > > >... > > > > > > We're going to need this one reverting for parisc. If you remember > > > we've been trying to push a compat_sys_rt_sigqueueinfo but Andi keeps > > > objecting, so it's remained local to our tree (an hence so has the > > > symbol usage). > > > > > > However, can we *please* stop this indiscriminate rampage through all > > > the sybsystems making things static just because we can. The true test > > > of whether a symbol should be static or not is whether it forms part of > > > a sensible API or not. For subsystems with a well defined API, this is > > > quite easy (although it hasn't prevented attempts to make even those > > > symbols static). For some of our core subsystems (like the kernel API > > > in this case) it's much less well defined ... although we have a good > > > solid white area of things that must be part of the API and a good solid > > > black area of things that mustn't, we still have a large grey area which > > > things like kill_proc_info() fall into. > > > > > > For any person who wants to make a static symbol exported, we force an > > > explanation out of them about what they're trying to do and why. Might > > > I suggest we apply the same standard to anyone trying to make something > > > static? i.e. they need to explain clearly why the symbol shouldn't be > > > part of any rational API. > > > > And by how many percent will this bloat the kernel more in the long > > term? > > That's something I'm more than willing to live with if the tradeoff is > we think before making things static. The big kernel size increase is a reason why many people in the embedded world stay at kernel 2.4. The fact that you can't get a 2.6 kernel as small as a 2.4 kernel is a serious regression. And the last time I checked it wasn't that there's some well-defined area where the size increase comes from - it's more or less evenly distributed between all not unmaintained parts of the kernel. > > > Thanks, > > > > > > James > > > Date: Thu, 8 Feb 2007 22:33:21 -0500 > > > From: Kyle McMartin <kyle@mcmartin.ca> > > > To: Matthew Wilcox <matthew@wil.cx> > > > Cc: Kyle McMartin <kyle@mcmartin.ca>, > > > parisc-linux <parisc-linux@lists.parisc-linux.org> > > > Subject: Re: [parisc-linux] 64-bit kernel broken. > > > > > > On Thu, Feb 08, 2007 at 08:24:54PM -0700, Matthew Wilcox wrote: > > > > On Thu, Feb 08, 2007 at 07:43:14PM -0500, Kyle McMartin wrote: > > > > > > Right. This got inadvertantly reverted with some other stuff. Fixed in a > > > > > > second. > > > > > > > > > > Fixed in 1736b4bbf2bbfebaad06114d569f3617517524d1. > > > > > > > > make.err:/home/willy/nicol-2.6/arch/parisc/kernel/signal32.c:519: > > > > warning: implicit declaration of function 'kill_proc_info' > > > > make.err:(.text.compat_sys_rt_sigqueueinfo+0x80): undefined reference to > > > > `kill_proc_info' > > > > > > > > > > Guess who came home for Christmas > > > > > > commit d3228a887cae75ef2b8b1211c31c539bef5a5698 > > > Author: Adrian Bunk <bunk@stusta.de> > > > Date: Wed Dec 6 20:38:22 2006 -0800 > > > > > > [PATCH] make kernel/signal.c:kill_proc_info() static > > > > > > Signed-off-by: Adrian Bunk <bunk@stusta.de> > > > Signed-off-by: Andrew Morton <akpm@osdl.org> > > > Signed-off-by: Linus Torvalds <torvalds@osdl.org> > > > > There are hundreds of such patches of mine that got included in Linus' > > tree and that didn't cause problems. Besides making the kernel smaller, > > they regularly find "it should have been used" bugs. > > > In this one case, a patch that made something static that wasn't used > > from other files during the over 9 years of it's existence clashes with > > another patch that adds a user. > > I'm really not that interested in the number of users ... that's only > one part of the measure of the relevance of an API. However, if we're > actually going to revoke an API I'd like it to be done on the API's > merits (or lack of them) rather than simply whether there are any > current in-kernel users. > > > Can we agree that it's not a usual case that the first user gets added > > after more than 9 years? > > Actually, the compat_rtsiginfo patch has been argued over and honed for > at least 3 years, so I'd say your statement isn't necessarily correct. > For some of its life, it was even in -mm. > > > And making it global again when a user gets included isn't really that > > hard. > > The life of a non-x86 architecture maintainer is hard ... it involves > having lots of volunteers tirelessly chasing down things that broke > during the big two week merge frenzy. It would be really helpful if > things like this didn't add to that burden. The change was not in -mm recently. The simple rules: - get your changes in -mm and - test -mm kernels and scream if someone broke your architecture would discover many problems before the 2 weeks merge window (and before problems hit Linus' tree). This would also eliminate problems like the parisc defconfig not compiling in 2.6.20 due to the work_struct changes. > James cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20070211073520.GR12958@stusta.de>]
* [parisc-linux] Re: Fw: Another problem with making things static [not found] ` <20070211073520.GR12958@stusta.de> @ 2007-02-11 15:56 ` James Bottomley 0 siblings, 0 replies; 9+ messages in thread From: James Bottomley @ 2007-02-11 15:56 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, Linus Torvalds, Parisc List On Sun, 2007-02-11 at 08:35 +0100, Adrian Bunk wrote: > On Sat, Feb 10, 2007 at 07:47:16PM -0600, James Bottomley wrote: > > On Sat, 2007-02-10 at 22:43 +0100, Adrian Bunk wrote: > > > First of all thanks to Andrew for forwarding this email to me - it's > > > otherwise a bit hard to defend against an email that doesn't reach me. > > > > I think if you read the email you'll find it didn't actually attack you > > at all ... I was careful only to ask for a change of policy before > > accepting a patch that does nothing but make a function static. > > Then let's call it "trying to establish rule forbidding something > established without even informing the people whose actions you want to > become forbidden". I'm sorry, but I didn't realise you would be unable to come up with justifications for API removal, and thus this would become an insuperable bar to you. The justification criterion was meant to be a more objective way of judging whether some API should be revoked and it seems to me, as a developer, to be a reasonable and not too onerous one. As Andrew pointed out, for most of the driver and FS symbols the justification is simply that this module isn't supposed to be exporting an API at all. James _______________________________________________ parisc-linux mailing list parisc-linux@lists.parisc-linux.org http://lists.parisc-linux.org/mailman/listinfo/parisc-linux ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-02-12 17:15 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20070210130136.9538498b.akpm@linux-foundation.org> [not found] ` <20070210214309.GP12958@stusta.de> 2007-02-11 1:47 ` [parisc-linux] Re: Fw: Another problem with making things static James Bottomley [not found] ` <1171158436.3373.51.camel@mulgrave.il.steeleye.com> 2007-02-11 4:19 ` Andrew Morton [not found] ` <20070210201911.7a16b5f3.akpm@linux-foundation.org> 2007-02-11 7:25 ` Grant Grundler [not found] ` <20070211072552.GC22248@colo.lackof.org> 2007-02-11 7:44 ` Andrew Morton [not found] ` <20070210234424.500ed1c9.akpm@linux-foundation.org> 2007-02-11 16:54 ` Kyle McMartin [not found] ` <20070211075738.GD22248@colo.lackof.org> 2007-02-12 11:42 ` Thibaut VARENE [not found] ` <20070211165405.GA4050@athena.road.mcmartin.ca> 2007-02-12 17:15 ` Andrew Morton 2007-02-11 7:35 ` Adrian Bunk [not found] ` <20070211073520.GR12958@stusta.de> 2007-02-11 15:56 ` James Bottomley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.