| Message ID | 1336913407-7383-2-git-send-email-holler@ahsoftware.de |
|---|---|
| State | Rejected, archived |
| Delegated to: | Tom Rini |
| Headers | show |
Dear Alexander Holler, > Use the new option -r for env import. > > Signed-off-by: Alexander Holler <holler@ahsoftware.de> > --- > include/configs/omap3_beagle.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/include/configs/omap3_beagle.h > b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644 > --- a/include/configs/omap3_beagle.h > +++ b/include/configs/omap3_beagle.h > @@ -258,7 +258,7 @@ > "bootenv=uEnv.txt\0" \ > "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ > "importbootenv=echo Importing environment from mmc ...; " \ > - "env import -t $loadaddr $filesize\0" \ > + "env import -t -r $loadaddr $filesize\0" \ Not everyone importing env on beagle use broken tools ;-) > "ramargs=setenv bootargs console=${console} " \ > "${optargs} " \ > "mpurate=${mpurate} " \ Best regards, Marek Vasut
On 13.05.2012 19:09, Marek Vasut wrote: > Dear Alexander Holler, > >> Use the new option -r for env import. >> >> Signed-off-by: Alexander Holler<holler@ahsoftware.de> >> --- >> include/configs/omap3_beagle.h | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/include/configs/omap3_beagle.h >> b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644 >> --- a/include/configs/omap3_beagle.h >> +++ b/include/configs/omap3_beagle.h >> @@ -258,7 +258,7 @@ >> "bootenv=uEnv.txt\0" \ >> "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ >> "importbootenv=echo Importing environment from mmc ...; " \ >> - "env import -t $loadaddr $filesize\0" \ >> + "env import -t -r $loadaddr $filesize\0" \ > > Not everyone importing env on beagle use broken tools ;-) Who said that? Regards, Alexander
Dear Marek Vasut, In message <201205131909.49488.marek.vasut@gmail.com> you wrote: > > > - "env import -t $loadaddr $filesize\0" \ > > + "env import -t -r $loadaddr $filesize\0" \ > > Not everyone importing env on beagle use broken tools ;-) It's not a problem of using broken tools - the problem is of ignorant people _not_ using decade old, working tools like dos2unix if they need them. As I mentionewd a coule of times before, I am seriously tempted to ignore this "problem". On the other hand, we usually say we accept code if it helps some, and doesn't hurt others. As is, the increase of code size is hurting. Best regards, Wolfgang Denk
Dear Alexander Holler, > On 13.05.2012 19:09, Marek Vasut wrote: > > Dear Alexander Holler, > > > >> Use the new option -r for env import. > >> > >> Signed-off-by: Alexander Holler<holler@ahsoftware.de> > >> --- > >> > >> include/configs/omap3_beagle.h | 2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/include/configs/omap3_beagle.h > >> b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644 > >> --- a/include/configs/omap3_beagle.h > >> +++ b/include/configs/omap3_beagle.h > >> @@ -258,7 +258,7 @@ > >> > >> "bootenv=uEnv.txt\0" \ > >> "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ > >> "importbootenv=echo Importing environment from mmc ...; " \ > >> > >> - "env import -t $loadaddr $filesize\0" \ > >> + "env import -t -r $loadaddr $filesize\0" \ > > > > Not everyone importing env on beagle use broken tools ;-) > > Who said that? You impose your -r option on all beagle users. That means everyone (even those with not-broken) tools will now use it (unless they replaced their env). > > Regards, > > Alexander Best regards, Marek Vasut
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201205131909.49488.marek.vasut@gmail.com> you wrote: > > > - "env import -t $loadaddr $filesize\0" \ > > > + "env import -t -r $loadaddr $filesize\0" \ > > > > Not everyone importing env on beagle use broken tools ;-) > > It's not a problem of using broken tools - the problem is of ignorant > people _not_ using decade old, working tools like dos2unix if they > need them. tr -d '\r' won't work? :-) > As I mentionewd a coule of times before, I am seriously tempted to > ignore this "problem". Can't the wincrap people be taught to use cygwin? Or possibly some Windows (R) (C)(TM)(???) rebuilt version of tr -d '\r' ? > On the other hand, we usually say we accept code if it helps some, and > doesn't hurt others. As is, the increase of code size is hurting. > > Best regards, > > Wolfgang Denk Best regards, Marek Vasut
On 13.05.2012 20:52, Marek Vasut wrote: > Dear Alexander Holler, > >> On 13.05.2012 19:09, Marek Vasut wrote: >>> Dear Alexander Holler, >>> >>>> Use the new option -r for env import. >>>> >>>> Signed-off-by: Alexander Holler<holler@ahsoftware.de> >>>> --- >>>> >>>> include/configs/omap3_beagle.h | 2 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/include/configs/omap3_beagle.h >>>> b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644 >>>> --- a/include/configs/omap3_beagle.h >>>> +++ b/include/configs/omap3_beagle.h >>>> @@ -258,7 +258,7 @@ >>>> >>>> "bootenv=uEnv.txt\0" \ >>>> "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ >>>> "importbootenv=echo Importing environment from mmc ...; " \ >>>> >>>> - "env import -t $loadaddr $filesize\0" \ >>>> + "env import -t -r $loadaddr $filesize\0" \ >>> >>> Not everyone importing env on beagle use broken tools ;-) >> >> Who said that? > > You impose your -r option on all beagle users. That means everyone (even those > with not-broken) tools will now use it (unless they replaced their env). Yes, and now they all will get doomed by ignored CRs before LFs. Anyway, just ignore those patches, it was lost time from the beginning and I should have known it better. Alexander
Dear Marek Vasut, In message <201205132057.47247.marex@denx.de> you wrote: > > > It's not a problem of using broken tools - the problem is of ignorant > > people _not_ using decade old, working tools like dos2unix if they > > need them. > > tr -d '\r' won't work? :-) Not as well - it will delete _all_ ocurrences of \r, which is more than just changing "\r\n" into "\n" (which still may be wrong in some cases). But yes, TIMTOWTDI. > Can't the wincrap people be taught to use cygwin? Or possibly some Windows (R) > (C)(TM)(???) rebuilt version of tr -d '\r' ? Do you care? Best regards, Wolfgang Denk
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201205132057.47247.marex@denx.de> you wrote: > > > It's not a problem of using broken tools - the problem is of ignorant > > > people _not_ using decade old, working tools like dos2unix if they > > > need them. > > > > tr -d '\r' won't work? :-) > > Not as well - it will delete _all_ ocurrences of \r, which is more > than just changing "\r\n" into "\n" (which still may be wrong in some > cases). > > But yes, TIMTOWTDI. What's this NLA (or 9LA) ? :) > > > Can't the wincrap people be taught to use cygwin? Or possibly some > > Windows (R) (C)(TM)(???) rebuilt version of tr -d '\r' ? > > Do you care? Well Alexander does, so I'm trying to find a fitting solution for both parties (uboot and him). > > Best regards, > > Wolfgang Denk Best regards, Marek Vasut
Dear Marek Vasut, In message <201205132145.19997.marex@denx.de> you wrote: > > > But yes, TIMTOWTDI. > > What's this NLA (or 9LA) ? :) http://en.wikipedia.org/wiki/TIMTOWTDI > > Do you care? > > Well Alexander does, so I'm trying to find a fitting solution for both parties > (uboot and him). well, I suggested one: the code should be conditional, so it does not bloat code size for "all other" users. Except from that, I'd be wiling to accept it (ok, I haven't looked at the implementation yet). Best regards, Wolfgang Denk
On 13.05.2012 20:57, Marek Vasut wrote: > Dear Wolfgang Denk, > >> Dear Marek Vasut, >> >> In message<201205131909.49488.marek.vasut@gmail.com> you wrote: >>>> - "env import -t $loadaddr $filesize\0" \ >>>> + "env import -t -r $loadaddr $filesize\0" \ >>> >>> Not everyone importing env on beagle use broken tools ;-) >> >> It's not a problem of using broken tools - the problem is of ignorant >> people _not_ using decade old, working tools like dos2unix if they >> need them. > > tr -d '\r' won't work? :-) > >> As I mentionewd a coule of times before, I am seriously tempted to >> ignore this "problem". > > Can't the wincrap people be taught to use cygwin? Or possibly some Windows (R) > (C)(TM)(???) rebuilt version of tr -d '\r' ? Sorry, it seems you just are unable or yiu don't want to understand the problem. So here is my last message on this topic, trying to explain it for you. env import -t is a handy solution to give users (not only devs) a possibility to modify variables (options) used to boot some OS. They don't have to deal with the u-boot command-line and, depending how it's used, env import -t is an alternative to persistent modify the env without the need for NAND. So one just tells the user(s) that if they want to change some option they just have to create a text file on a specific place which contains a line like e.g. foo=bar The only problem is that such a description currently only works for Linux users. I don't know with what devices and users you are dealing, but there are some people out in the wild which don't know (much) about Linux, or even about the difference in line endings between text files creates using Windows or Linux. Some of them even just want to use their device. And in addition, the resulting problems hare very hard to diagnose, because there will be no obvious error message when something contains a trailing CR. It would be interesting how long you would need to diagnose such a problem without knowing about that problem, but we now will never know. Now I needed about 10 mails to describe a problem from which I thought it's totally obvious. Sorry, but I accept that I'm totally unable to deal with this list in any, for me reasonable, time frame. Regards, Alexander
Dear Alexander, In message <4FB01720.90402@ahsoftware.de> you wrote: > > Sorry, it seems you just are unable or yiu don't want to understand the > problem. So here is my last message on this topic, trying to explain it > for you. I'm sorry you are giving up so early, just one resubmit before getting this into an acceptable state. > So one just tells the user(s) that if they want to change some option > they just have to create a text file on a specific place which contains > a line like e.g. I guess this is the point where the problem starts. You should not write anywhere "they just have to create a text file", because "a text file" is not a precise enough definition of the required input format. > The only problem is that such a description currently only works for > Linux users. ... The problem is not Windows users versus Linux users here. The problem is unsufficient information. > ... I don't know with what devices and users you are dealing, > but there are some people out in the wild which don't know (much) about > Linux, or even about the difference in line endings between text files > creates using Windows or Linux. Some of them even just want to use their > device. In either case, people are usually pretty good in following pre-canned recipies for doing things. Instead of "create a text file" one could for example document that "a UNIX style text file, i. e. with only "\n" line endings (and not the DOS-derived "\r\n" line endings) is needed". One could add some description that "on Windows systems, the command ... can be used to convert a DOS file into this format" (and provide a URL where to get this tool), "while on UNIX systems like Linux the dos2unix tool can be used". If you then add an example suitable for copy & paste you can solve a very large percentage of the propblems you see now. > And in addition, the resulting problems hare very hard to diagnose, > because there will be no obvious error message when something contains a > trailing CR. What exactly are such error modes, by the way? I would expect that trailing white space is pretty much harmless for most variable settings? > Now I needed about 10 mails to describe a problem from which I thought > it's totally obvious. Sorry, but I accept that I'm totally unable to > deal with this list in any, for me reasonable, time frame. What you provide is valuable input, and it really makes sense to discuss such issues. I would like to bring such discussions to a point where either we understand why your approach makes sense, or where you agree that there are alternatives that solve the problem as well (or better) as your original proposal. However, this is difficult to acchieve if you give up early. And believe me, this is taking my time (and Marek's) as much as yours. We do this not to annoy you, but because we are interested in the best possible solution. Best regards, Wolfgang Denk
Marek Vasut <marex@denx.de> writes: > Dear Wolfgang Denk, > >> Dear Marek Vasut, >> >> In message <201205131909.49488.marek.vasut@gmail.com> you wrote: >> > > - "env import -t $loadaddr $filesize\0" \ >> > > + "env import -t -r $loadaddr $filesize\0" \ >> > >> > Not everyone importing env on beagle use broken tools ;-) >> >> It's not a problem of using broken tools - the problem is of ignorant >> people _not_ using decade old, working tools like dos2unix if they >> need them. > > tr -d '\r' won't work? :-) > >> As I mentionewd a coule of times before, I am seriously tempted to >> ignore this "problem". > > Can't the wincrap people be taught to use cygwin? Or possibly some Windows (R) > (C)(TM)(???) rebuilt version of tr -d '\r' ? Most text editors on windows except notepad.exe have an option for Unix-style line breaks. People who insist on using notepad.exe deserve no sympathy.
Am 13.05.2012 23:38, schrieb Wolfgang Denk: > Dear Alexander, > > In message<4FB01720.90402@ahsoftware.de> you wrote: >> >> Sorry, it seems you just are unable or yiu don't want to understand the >> problem. So here is my last message on this topic, trying to explain it >> for you. > > I'm sorry you are giving up so early, just one resubmit before getting > this into an acceptable state. > >> So one just tells the user(s) that if they want to change some option >> they just have to create a text file on a specific place which contains >> a line like e.g. > > I guess this is the point where the problem starts. You should not > write anywhere "they just have to create a text file", because "a text > file" is not a precise enough definition of the required input format. > >> The only problem is that such a description currently only works for >> Linux users. ... > > The problem is not Windows users versus Linux users here. The problem > is unsufficient information. > >> ... I don't know with what devices and users you are dealing, >> but there are some people out in the wild which don't know (much) about >> Linux, or even about the difference in line endings between text files >> creates using Windows or Linux. Some of them even just want to use their >> device. > > In either case, people are usually pretty good in following pre-canned > recipies for doing things. > > Instead of "create a text file" one could for example document that "a > UNIX style text file, i. e. with only "\n" line endings (and not the > DOS-derived "\r\n" line endings) is needed". One could add some > description that "on Windows systems, the command ... can be used to > convert a DOS file into this format" (and provide a URL where to get > this tool), "while on UNIX systems like Linux the dos2unix tool can be > used". > > If you then add an example suitable for copy& paste you can solve a > very large percentage of the propblems you see now. Sorry, but you are just describing one of the oldest dreams (not only) in IT. You can write whatever you wish, users are able to not read it, to misread it, to ignore it, not to understand it or it will get missing in an one-line copy of the original multine description. Regards, Alexander
Am 13.05.2012 23:38, schrieb Wolfgang Denk: > Dear Alexander, > > In message<4FB01720.90402@ahsoftware.de> you wrote: > What exactly are such error modes, by the way? I would expect that > trailing white space is pretty much harmless for most variable > settings? The problem already starts in u-boot itself: a="b\r" I'm not sure if \r on the u-boot-cmdline does work, but you know what I mean. $a=="b" is false fatload $a fails (if the file is named 'b'). ... Regards, Alexander
Am 14.05.2012 11:07, schrieb Alexander Holler: > Am 13.05.2012 23:38, schrieb Wolfgang Denk: >> Dear Alexander, >> >> In message<4FB01720.90402@ahsoftware.de> you wrote: > >> What exactly are such error modes, by the way? I would expect that >> trailing white space is pretty much harmless for most variable >> settings? > > The problem already starts in u-boot itself: > > a="b\r" > > I'm not sure if \r on the u-boot-cmdline does work, but you know what I > mean. > > $a=="b" > > is false > > fatload $a > > fails (if the file is named 'b'). > > ... And a="1\r" isn't a number. So anything which expects a number will fail. E.g. fatls usb 0:${a} and every arithmetic which uses ${a} Regards, Alexander
On Sun, May 13, 2012 at 02:50:07PM +0200, Alexander Holler wrote: > Use the new option -r for env import. > > Signed-off-by: Alexander Holler <holler@ahsoftware.de> While I am sympathetic, the right answer is to tell users to use a text editor that can save with UNIX-style newlines. NAK.
Am 14.05.2012 18:02, schrieb Tom Rini: > On Sun, May 13, 2012 at 02:50:07PM +0200, Alexander Holler wrote: > >> Use the new option -r for env import. >> >> Signed-off-by: Alexander Holler<holler@ahsoftware.de> > > While I am sympathetic, the right answer is to tell users to use a text > editor that can save with UNIX-style newlines. NAK. > As long as you don't commit another wrong patch with me as author, I accept it and stop, as already promised, with patches. Regards Alexander
Dear Alexander Holler, > Am 14.05.2012 18:02, schrieb Tom Rini: > > On Sun, May 13, 2012 at 02:50:07PM +0200, Alexander Holler wrote: > >> Use the new option -r for env import. > >> > >> Signed-off-by: Alexander Holler<holler@ahsoftware.de> > > > > While I am sympathetic, the right answer is to tell users to use a text > > editor that can save with UNIX-style newlines. NAK. > > As long as you don't commit another wrong patch with me as author What happened? > , I > accept it and stop, as already promised, with patches. > > Regards > > Alexander > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Best regards, Marek Vasut
On 14.05.2012 20:45, Marek Vasut wrote: > Dear Alexander Holler, > >> Am 14.05.2012 18:02, schrieb Tom Rini: >>> On Sun, May 13, 2012 at 02:50:07PM +0200, Alexander Holler wrote: >>>> Use the new option -r for env import. >>>> >>>> Signed-off-by: Alexander Holler<holler@ahsoftware.de> >>> >>> While I am sympathetic, the right answer is to tell users to use a text >>> editor that can save with UNIX-style newlines. NAK. >> >> As long as you don't commit another wrong patch with me as author > > What happened? > Someone, which I never met in realitiy before, greeted me at the FOSDEM as the one who got famous (in some circles, don't know) for tty02 (0 as in zeroMAP, the well known processor from TI). Regards, Alexander
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index ddeb414..d8b10c2 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -258,7 +258,7 @@ "bootenv=uEnv.txt\0" \ "loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \ "importbootenv=echo Importing environment from mmc ...; " \ - "env import -t $loadaddr $filesize\0" \ + "env import -t -r $loadaddr $filesize\0" \ "ramargs=setenv bootargs console=${console} " \ "${optargs} " \ "mpurate=${mpurate} " \
Use the new option -r for env import. Signed-off-by: Alexander Holler <holler@ahsoftware.de> --- include/configs/omap3_beagle.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)