All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Michal Marek <mmarek@suse.cz>,
	linux-arch@vger.kernel.org, Michal Simek <monstr@monstr.eu>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>,
	Mike Frysinger <vapier@gentoo.org>,
	linux-sh@vger.kernel.org, microblaze-uclinux@itee.uq.edu.au,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Mundt <lethal@linux-sh.org>,
	uclinux-dist-devel@blackfin.uclinux.org,
	sparclinux@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	Haavard Skinnemoen <hskinnemoen@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org,
	Hans-Christian Egtvedt <egtvedt@samfundet.no>
Subject: Re: [PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD
Date: Wed, 7 Mar 2012 20:08:20 +0100	[thread overview]
Message-ID: <20120307190820.GD27213@game.jcrosoft.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1203071336210.24151@xanadu.home>

On 13:50 Wed 07 Mar     , Nicolas Pitre wrote:
> On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > > This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > > if their arch Kconfig allows it, and they desire.
> > > 
> > > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > > ---
> > > The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > > that some other architectures will also be able to enable it, but I'm
> > > not familiar enough with any to know which.
> > I'm going to repeat. I don't think any impromevent here.
> 
> You know what?  I agree with you... on a conceptual level only though.
> 
> In reality, some people are are just too used to it, either for 
> emotional reasons or simply because that's what was there before so they 
> simply perpetuated it without thinking further, or whatever.  REmoving 
> that support would just upset a lot of people.  And frankly we have 
> better things to do than starting a flamewar over this.
My concern is this new feature is available on new version of U-Boot only
and people that does not have it and built the uImage are going to ask the
question. Why bla bla bla....

Where people are supposed to RTFM

I do do not want to have the answer this and manage this.
> 
> So the next best thing is to make this u-Boot stuff well contained in a 
> common place and make sure it doesn't spread incoherently over multiple 
> architecture's directories and makefiles.  This way the u-Boot cruft 
> won't be the ARM maintainer, or the PPC maintainer, or the SPARC 
> maintainer, or any other architecture maintainer's business, but the 
> responsibility of those who do care about it without affecting anyone 
> else.
Ditto here

People does not read the doc they as lazy and I do not want to manage this.

> 
> > And the uImage format here is called the legacy format where now U-Boot
> > support a new format based on DT format.
> > 
> > Will you plan to add it too?
> 
> Why not if someone cares?  At least this will be done only 
> once, centrally, without having to involve architecture maintainers.
So you manage this because I will not answer one e-mail that ask for help
Because for my point of view RTFM or boot the zImage

Best Regards,
J.

WARNING: multiple messages have this Message-ID (diff)
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
	Michal Marek <mmarek@suse.cz>,
	linux-arch@vger.kernel.org, Michal Simek <monstr@monstr.eu>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>,
	Mike Frysinger <vapier@gentoo.org>,
	linux-sh@vger.kernel.org, microblaze-uclinux@itee.uq.edu.au,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	Paul Mundt <lethal@linux-sh.org>,
	uclinux-dist-devel@blackfin.uclinux.org,
	sparclinux@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	Haavard Skinnemoen <hskinnemoen@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org,
	Hans-Christian Egtvedt <egtvedt@samfundet.no>
Subject: Re: [PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD
Date: Wed, 07 Mar 2012 19:08:20 +0000	[thread overview]
Message-ID: <20120307190820.GD27213@game.jcrosoft.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1203071336210.24151@xanadu.home>

On 13:50 Wed 07 Mar     , Nicolas Pitre wrote:
> On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > > This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > > if their arch Kconfig allows it, and they desire.
> > > 
> > > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > > ---
> > > The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > > that some other architectures will also be able to enable it, but I'm
> > > not familiar enough with any to know which.
> > I'm going to repeat. I don't think any impromevent here.
> 
> You know what?  I agree with you... on a conceptual level only though.
> 
> In reality, some people are are just too used to it, either for 
> emotional reasons or simply because that's what was there before so they 
> simply perpetuated it without thinking further, or whatever.  REmoving 
> that support would just upset a lot of people.  And frankly we have 
> better things to do than starting a flamewar over this.
My concern is this new feature is available on new version of U-Boot only
and people that does not have it and built the uImage are going to ask the
question. Why bla bla bla....

Where people are supposed to RTFM

I do do not want to have the answer this and manage this.
> 
> So the next best thing is to make this u-Boot stuff well contained in a 
> common place and make sure it doesn't spread incoherently over multiple 
> architecture's directories and makefiles.  This way the u-Boot cruft 
> won't be the ARM maintainer, or the PPC maintainer, or the SPARC 
> maintainer, or any other architecture maintainer's business, but the 
> responsibility of those who do care about it without affecting anyone 
> else.
Ditto here

People does not read the doc they as lazy and I do not want to manage this.

> 
> > And the uImage format here is called the legacy format where now U-Boot
> > support a new format based on DT format.
> > 
> > Will you plan to add it too?
> 
> Why not if someone cares?  At least this will be done only 
> once, centrally, without having to involve architecture maintainers.
So you manage this because I will not answer one e-mail that ask for help
Because for my point of view RTFM or boot the zImage

Best Regards,
J.

WARNING: multiple messages have this Message-ID (diff)
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD
Date: Wed, 7 Mar 2012 20:08:20 +0100	[thread overview]
Message-ID: <20120307190820.GD27213@game.jcrosoft.org> (raw)
In-Reply-To: <alpine.LFD.2.02.1203071336210.24151@xanadu.home>

On 13:50 Wed 07 Mar     , Nicolas Pitre wrote:
> On Wed, 7 Mar 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On 17:30 Tue 06 Mar     , Stephen Warren wrote:
> > > This allows the user to use U-Boot's mkimage's -T kernel_noload option
> > > if their arch Kconfig allows it, and they desire.
> > > 
> > > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> > > ---
> > > The next patch enables this new CONFIG_ALLOW_ option for ARM. I assume
> > > that some other architectures will also be able to enable it, but I'm
> > > not familiar enough with any to know which.
> > I'm going to repeat. I don't think any impromevent here.
> 
> You know what?  I agree with you... on a conceptual level only though.
> 
> In reality, some people are are just too used to it, either for 
> emotional reasons or simply because that's what was there before so they 
> simply perpetuated it without thinking further, or whatever.  REmoving 
> that support would just upset a lot of people.  And frankly we have 
> better things to do than starting a flamewar over this.
My concern is this new feature is available on new version of U-Boot only
and people that does not have it and built the uImage are going to ask the
question. Why bla bla bla....

Where people are supposed to RTFM

I do do not want to have the answer this and manage this.
> 
> So the next best thing is to make this u-Boot stuff well contained in a 
> common place and make sure it doesn't spread incoherently over multiple 
> architecture's directories and makefiles.  This way the u-Boot cruft 
> won't be the ARM maintainer, or the PPC maintainer, or the SPARC 
> maintainer, or any other architecture maintainer's business, but the 
> responsibility of those who do care about it without affecting anyone 
> else.
Ditto here

People does not read the doc they as lazy and I do not want to manage this.

> 
> > And the uImage format here is called the legacy format where now U-Boot
> > support a new format based on DT format.
> > 
> > Will you plan to add it too?
> 
> Why not if someone cares?  At least this will be done only 
> once, centrally, without having to involve architecture maintainers.
So you manage this because I will not answer one e-mail that ask for help
Because for my point of view RTFM or boot the zImage

Best Regards,
J.

  reply	other threads:[~2012-03-07 19:08 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07  0:30 [PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions Stephen Warren
2012-03-07  0:30 ` Stephen Warren
2012-03-07  0:30 ` Stephen Warren
2012-03-07  0:30 ` [PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD Stephen Warren
2012-03-07  0:30   ` Stephen Warren
2012-03-07  0:30   ` Stephen Warren
2012-03-07  0:52   ` Julian Calaby
2012-03-07  0:52     ` Julian Calaby
2012-03-07  0:52     ` Julian Calaby
2012-03-07  0:52     ` Julian Calaby
     [not found]   ` <1331080238-1524-2-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-03-07  6:52     ` [microblaze-linux] " Guan Xuetao
2012-03-07  6:52       ` Guan Xuetao
2012-03-07  6:52       ` Guan Xuetao
2012-03-07  6:52       ` Guan Xuetao
2012-03-07 18:10       ` Stephen Warren
2012-03-07 18:10         ` Stephen Warren
2012-03-07 18:10         ` Stephen Warren
2012-03-07 18:08   ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 18:08     ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 18:08     ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 18:40     ` Stephen Warren
2012-03-07 18:40       ` Stephen Warren
2012-03-07 18:40       ` Stephen Warren
2012-03-07 18:36       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 18:36         ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 18:36         ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 19:02         ` Nicolas Pitre
2012-03-07 19:02           ` Nicolas Pitre
2012-03-07 19:02           ` Nicolas Pitre
2012-03-07 20:27         ` Stephen Warren
2012-03-07 20:27           ` Stephen Warren
2012-03-07 20:27           ` Stephen Warren
2012-03-07 21:03           ` Nicolas Pitre
2012-03-07 21:03             ` Nicolas Pitre
2012-03-07 21:03             ` Nicolas Pitre
2012-03-07 21:30             ` Russell King - ARM Linux
2012-03-07 21:30               ` Russell King - ARM Linux
2012-03-07 21:30               ` Russell King - ARM Linux
2012-03-07 22:43               ` Nicolas Pitre
2012-03-07 22:43                 ` Nicolas Pitre
2012-03-07 22:43                 ` Nicolas Pitre
2012-03-07 21:28           ` Russell King - ARM Linux
2012-03-07 21:28             ` Russell King - ARM Linux
2012-03-07 21:28             ` Russell King - ARM Linux
2012-03-07 18:50     ` Nicolas Pitre
2012-03-07 18:50       ` Nicolas Pitre
2012-03-07 18:50       ` Nicolas Pitre
2012-03-07 19:08       ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2012-03-07 19:08         ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 19:08         ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 19:31         ` Nicolas Pitre
2012-03-07 19:31           ` Nicolas Pitre
2012-03-07 19:31           ` Nicolas Pitre
2012-03-07  0:30 ` [PATCH 3/3] ARM: Allow the user to enable UIMAGE_KERNEL_NOLOAD Stephen Warren
2012-03-07  0:30   ` Stephen Warren
2012-03-07  0:30   ` Stephen Warren
2012-03-07  3:56 ` [PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions Mike Frysinger
2012-03-07  3:56   ` Mike Frysinger
2012-03-07  3:56   ` Mike Frysinger
2012-03-07 17:41   ` Stephen Warren
2012-03-07 17:41     ` Stephen Warren
2012-03-07 17:41     ` Stephen Warren
2012-03-07 18:25     ` Mike Frysinger
2012-03-07 18:25       ` Mike Frysinger
2012-03-07 18:25       ` Mike Frysinger
2012-03-07  9:00 ` Hans-Christian Egtvedt
2012-03-07  9:00   ` Hans-Christian Egtvedt
2012-03-07  9:00   ` Hans-Christian Egtvedt
2012-03-07 14:15 ` Josh Boyer
2012-03-07 14:15   ` Josh Boyer
2012-03-07 14:15   ` Josh Boyer
2012-03-07 18:29   ` Stephen Warren
2012-03-07 18:29     ` Stephen Warren
2012-03-07 18:29     ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120307190820.GD27213@game.jcrosoft.org \
    --to=plagnioj@jcrosoft.com \
    --cc=davem@davemloft.net \
    --cc=egtvedt@samfundet.no \
    --cc=gxt@mprc.pku.edu.cn \
    --cc=hskinnemoen@gmail.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=microblaze-uclinux@itee.uq.edu.au \
    --cc=mmarek@suse.cz \
    --cc=monstr@monstr.eu \
    --cc=nico@fluxnic.net \
    --cc=sparclinux@vger.kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.