On Sun, 20 Mar 2016 16:09:40 +0100
Bernhard Nortmann <[email protected]> wrote:
> Hi Siarhei!
>
> Am 20.03.2016 um 15:49 schrieb Siarhei Siamashka:
> > This patch is just unsafe if pushed alone, that's why it implicitly
> > depends on the other "fel: Move the temporary scratch buffer under the
> > IRQ stack" patch.
>
> I see. My impression was that while "unclean" on its own, it's still
> functional - at least to a degree where stuff like "sunxi-fel sid" might
> actually allow device identification before doing more complicated stuff
> (in a second sunxi-fel invocation). But of course it's preferable to
> properly resolve the dependenices first.
It is functional as long as you are fine with corrupting memory at
0x2000 as a side effect. This address 0x2000 is special because it is
the usual location where sunxi-fel users are supposed to upload their
code for execution, as instructed by many existing examples and
tutorials. Consider the following shell code:
if [ "`sunxi-fel ver | grep \(A10\)`" ] ; then
sunxi-fel write 0x2000 some_code_for_a10_soc
if [ "`sunxi-fel sid | grep 16236747-80728452-50574848-064163D5`" ] ; then
sunxi-fel exe 0x2000
else
echo "Oh, wrong device, nevermind"
fi
else
echo "Oh, wrong SoC type, nevermind"
fi
> > And instead of cluttering the documentation with the "Use these commands
> > with caution!" warnings (which many people will miss or ignore anyway),
> > it's better to do a proper job in the first place.
>
> It would simply give us something to point users to, if they try antics
> like "./sunxi-fel readl 0x88888888" and come back complaining "That
> always fails with: libusb usb_bulk_send error -7". (Just like you) I
> suspect people will do this anyway, no matter where / how we put up
> warning signs in the first place... :-P
The user may run into a trouble by using the documented functionality
in a wrong way. But this is relatively easy to debug and makes the user
learn his lesson pretty fast.
But running into a trouble because of an undocumented (or poorly
documented) side effect is entirely different. Such problems are
usually much harder to debug. Check the
https://en.wikipedia.org/wiki/Principle_of_least_astonishment
Corrupting memory at 0x2000 clearly violates this principle, even if
we bother to document this behaviour somewhere.
Still I don't understand why we are even discussing this. A simple patch
to address this issue already exists.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
