From: Nishanth Menon <menon.nishanth@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
Date: Sat, 06 Nov 2010 00:00:49 -0400 [thread overview]
Message-ID: <4CD4D2F1.3010203@gmail.com> (raw)
In-Reply-To: <AANLkTi=LLSBLz+L9_TyGkWqCY6vCw9HkvS9vyc47kVEv@mail.gmail.com>
Steve Sakoman wrote, on 11/05/2010 10:47 PM:
> While I understand that you are frustrated with the slow movement in
> getting the kernel mux cleaned up, I really can't support deliberately
> breaking systems to force the issue.
>
> I don't think it does end users any service to have a u-boot "upgrade"
> break their systems. In the end, they are the ones who will be hurt
> and u-boot will get the blame for causing the breakage.
>
> I'd rather see us put the energy into helping get the kernel in shape.
In 2009 July[1], I raised the concern for OMAP3. at that point the fact
was we did not have a clean mux framework in kernel. ok great, 2010 Nov
now, there is *already* a framework for doing it in kernel upstream
today. What rationale is there for OMAP3 beagleboard [1] still do muxing
as it does today - we as a community are lazy to clean up our code? What
happend as a result? There are linux-products out there which dont use
u-boot as bootloader and development non-linux OS's out there which use
u-boot as a bootloader - in the case of the linux-products, surprises
were found for the upstream kernel depending on u-boot for their muxes
and development-OSes found the same mistake when they switched to their
native bootloaders at a later point.
Why should OMAP4 mux framework not move forward despite two rounds of
RFC patches posted[3]? I am not asking this to be done tomorrow, I am
asking our community for a deadline - If v2010.12 is too close, fine,
then lets schedule it for after v2011.03 tag for example -> is'nt 4
months not good enough to get an already existing mux framework upstream
in kernel.org for OMAP4? or should OMAP4 products go through the same
experience of OMAP3?
Conceptually it is simple - a software does just what it is supposed to
do - u-boot for OMAP today does way more than it's charter and I
personally find it obnoxious! All I am saying is this: we all agree this
is messed up, I have an itch, I am willing to do the cleanup as well,
just tell me when it is right to do it, I just don't want to deal with
crappy code anymore!
Ref:
[1] http://www.mail-archive.com/u-boot at lists.denx.de/msg17423.html
[2]
http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/beagle/beagle.h;h=ec0da6d745477437c1c776db7929690e1e568437;hb=HEAD
[3] http://marc.info/?l=linux-omap&m=128752700004693&w=2
--
Regards,
Nishanth Menon
next prev parent reply other threads:[~2010-11-06 4:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 19:56 [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX Nishanth Menon
2010-11-06 2:47 ` Steve Sakoman
2010-11-06 4:00 ` Nishanth Menon [this message]
2010-11-06 4:59 ` Peter Barada
2010-11-09 0:38 ` Nishanth Menon
2010-11-09 8:48 ` Premi, Sanjeev
2010-11-09 11:38 ` Nishanth Menon
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=4CD4D2F1.3010203@gmail.com \
--to=menon.nishanth@gmail.com \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox