| Submitter | Gary Thomas |
|---|---|
| Date | March 1, 2012, 2:43 p.m. |
| Message ID | <1330612994-26329-1-git-send-email-gary@mlbassoc.com> |
| Download | mbox | patch |
| Permalink | /patch/22535/ |
| State | New |
| Headers | show |
Comments
On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: > Recent changes have attempted to make consistant use of /etc/timestamp > In particular > 5aab665 initscripts: Make /etc/timestamp consistent again. > 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes > > This new format can cause problems as the value is too large for > most [32 bit] machines. Work around this by only comparing the > YYYYMMDD portion (which does fit in 32 bits). Also, the new format > is not directly compatible with the 'date' command line, so it > must be reformatted for use. > > Signed-off-by: Gary Thomas <gary@mlbassoc.com> > --- > .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) I merged the changes to busybox in relation to this. Is this patch still needed? Cheers, Richard
On 2012-03-01 07:59, Richard Purdie wrote: > On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: >> Recent changes have attempted to make consistant use of /etc/timestamp >> In particular >> 5aab665 initscripts: Make /etc/timestamp consistent again. >> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes >> >> This new format can cause problems as the value is too large for >> most [32 bit] machines. Work around this by only comparing the >> YYYYMMDD portion (which does fit in 32 bits). Also, the new format >> is not directly compatible with the 'date' command line, so it >> must be reformatted for use. >> >> Signed-off-by: Gary Thomas<gary@mlbassoc.com> >> --- >> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) > > I merged the changes to busybox in relation to this. Is this patch still > needed? Let me check - I didn't see the related busybox change.
On 2012-03-01 08:11, Gary Thomas wrote: > On 2012-03-01 07:59, Richard Purdie wrote: >> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: >>> Recent changes have attempted to make consistant use of /etc/timestamp >>> In particular >>> 5aab665 initscripts: Make /etc/timestamp consistent again. >>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes >>> >>> This new format can cause problems as the value is too large for >>> most [32 bit] machines. Work around this by only comparing the >>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format >>> is not directly compatible with the 'date' command line, so it >>> must be reformatted for use. >>> >>> Signed-off-by: Gary Thomas<gary@mlbassoc.com> >>> --- >>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- >>> 1 files changed, 2 insertions(+), 2 deletions(-) >> >> I merged the changes to busybox in relation to this. Is this patch still >> needed? > > Let me check - I didn't see the related busybox change. > I missed the busybox change because there was no PR bump :-( The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that now 'date' from busybox works one way and 'date' from coreutils works another. Using coreutils: root@cobra8148p81:~# date 201203011520 date: invalid date `201203011520' root@cobra8148p81:~# date 030115202012 Thu Mar 1 15:20:00 UTC 2012 root@cobra8148p81:~# ls -l /bin/date lrwxrwxrwx 1 root root 14 Mar 1 15:14 /bin/date -> date.coreutils Using busybox: root@cobra8148p81:~# ln -s /bin/busybox /tmp/date root@cobra8148p81:~# /tmp/date 201203011520 Thu Mar 1 15:20:00 UTC 2012 I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back on along with my reformatting change. I can make an updated patch if you agree.
On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote: > On 2012-03-01 08:11, Gary Thomas wrote: > > On 2012-03-01 07:59, Richard Purdie wrote: > >> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: > >>> Recent changes have attempted to make consistant use of /etc/timestamp > >>> In particular > >>> 5aab665 initscripts: Make /etc/timestamp consistent again. > >>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes > >>> > >>> This new format can cause problems as the value is too large for > >>> most [32 bit] machines. Work around this by only comparing the > >>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format > >>> is not directly compatible with the 'date' command line, so it > >>> must be reformatted for use. > >>> > >>> Signed-off-by: Gary Thomas<gary@mlbassoc.com> > >>> --- > >>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- > >>> 1 files changed, 2 insertions(+), 2 deletions(-) > >> > >> I merged the changes to busybox in relation to this. Is this patch still > >> needed? > > > > Let me check - I didn't see the related busybox change. > > > > I missed the busybox change because there was no PR bump :-( > > The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that > now 'date' from busybox works one way and 'date' from coreutils works another. > > Using coreutils: > > root@cobra8148p81:~# date 201203011520 > date: invalid date `201203011520' > root@cobra8148p81:~# date 030115202012 > Thu Mar 1 15:20:00 UTC 2012 > root@cobra8148p81:~# ls -l /bin/date > lrwxrwxrwx 1 root root 14 Mar 1 15:14 /bin/date -> date.coreutils > > Using busybox: > > root@cobra8148p81:~# ln -s /bin/busybox /tmp/date > root@cobra8148p81:~# /tmp/date 201203011520 > Thu Mar 1 15:20:00 UTC 2012 > > I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back > on along with my reformatting change. > > I can make an updated patch if you agree. Is this going to cause us a problem in real world usage? I'd hope in the general case we use standard formatting? I have to admit I'm getting more than a little frustrated with what seems like a continual set of changes bouncing this format around in different directions :(. Cheers, Richard
On 2012-03-01 08:44, Richard Purdie wrote: > On Thu, 2012-03-01 at 08:27 -0700, Gary Thomas wrote: >> On 2012-03-01 08:11, Gary Thomas wrote: >>> On 2012-03-01 07:59, Richard Purdie wrote: >>>> On Thu, 2012-03-01 at 07:43 -0700, Gary Thomas wrote: >>>>> Recent changes have attempted to make consistant use of /etc/timestamp >>>>> In particular >>>>> 5aab665 initscripts: Make /etc/timestamp consistent again. >>>>> 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes >>>>> >>>>> This new format can cause problems as the value is too large for >>>>> most [32 bit] machines. Work around this by only comparing the >>>>> YYYYMMDD portion (which does fit in 32 bits). Also, the new format >>>>> is not directly compatible with the 'date' command line, so it >>>>> must be reformatted for use. >>>>> >>>>> Signed-off-by: Gary Thomas<gary@mlbassoc.com> >>>>> --- >>>>> .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- >>>>> 1 files changed, 2 insertions(+), 2 deletions(-) >>>> >>>> I merged the changes to busybox in relation to this. Is this patch still >>>> needed? >>> >>> Let me check - I didn't see the related busybox change. >>> >> >> I missed the busybox change because there was no PR bump :-( >> >> The problem with the change turning off CONFIG_FEATURE_DATE_COMPAT is that >> now 'date' from busybox works one way and 'date' from coreutils works another. >> >> Using coreutils: >> >> root@cobra8148p81:~# date 201203011520 >> date: invalid date `201203011520' >> root@cobra8148p81:~# date 030115202012 >> Thu Mar 1 15:20:00 UTC 2012 >> root@cobra8148p81:~# ls -l /bin/date >> lrwxrwxrwx 1 root root 14 Mar 1 15:14 /bin/date -> date.coreutils >> >> Using busybox: >> >> root@cobra8148p81:~# ln -s /bin/busybox /tmp/date >> root@cobra8148p81:~# /tmp/date 201203011520 >> Thu Mar 1 15:20:00 UTC 2012 >> >> I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back >> on along with my reformatting change. >> >> I can make an updated patch if you agree. > > Is this going to cause us a problem in real world usage? I'd hope in the > general case we use standard formatting? > > I have to admit I'm getting more than a little frustrated with what > seems like a continual set of changes bouncing this format around in > different directions :(. I agree and I'm sorry I missed this in my first change - I was just trying to make the time stamps be consistent. As far as I can recall (which is a really long time), 'date' has always wanted the format MMDDHHmm[YYYY], so I think that's what we should expect. That format doesn't compare easily which is why the timestamp was changed (not by me) to a more ISO standard YYYYMMDDHHmm. If busybox has 64-bit math enabled, then this can be compared with no problems, it just has to be munged into the format 'date' wants.
On Thu, Mar 1, 2012 at 12:27, Gary Thomas <gary@mlbassoc.com> wrote: > I think the best thing would be to turn CONFIG_FEATURE_DATE_COMPAT back > on along with my reformatting change. > > I can make an updated patch if you agree. This is indeed the better solution. Please send an updated patch in meanwhile so Richard can apply it once he has some time and restore the right behavior.
On Thu, Mar 1, 2012 at 12:52, Gary Thomas <gary@mlbassoc.com> wrote: > On 2012-03-01 08:44, Richard Purdie wrote: >> Is this going to cause us a problem in real world usage? I'd hope in the >> general case we use standard formatting? >> >> I have to admit I'm getting more than a little frustrated with what >> seems like a continual set of changes bouncing this format around in >> different directions :(. > > I agree and I'm sorry I missed this in my first change - I was just > trying to make the time stamps be consistent. > > As far as I can recall (which is a really long time), 'date' has always > wanted the format MMDDHHmm[YYYY], so I think that's what we should expect. > That format doesn't compare easily which is why the timestamp was changed > (not by me) to a more ISO standard YYYYMMDDHHmm. If busybox has 64-bit > math enabled, then this can be compared with no problems, it just has > to be munged into the format 'date' wants. So we can have compat and 64-bit math and have it properly behaving?
On 2012-03-01 09:04, Otavio Salvador wrote: > On Thu, Mar 1, 2012 at 12:52, Gary Thomas<gary@mlbassoc.com> wrote: >> On 2012-03-01 08:44, Richard Purdie wrote: >>> Is this going to cause us a problem in real world usage? I'd hope in the >>> general case we use standard formatting? >>> >>> I have to admit I'm getting more than a little frustrated with what >>> seems like a continual set of changes bouncing this format around in >>> different directions :(. >> >> I agree and I'm sorry I missed this in my first change - I was just >> trying to make the time stamps be consistent. >> >> As far as I can recall (which is a really long time), 'date' has always >> wanted the format MMDDHHmm[YYYY], so I think that's what we should expect. >> That format doesn't compare easily which is why the timestamp was changed >> (not by me) to a more ISO standard YYYYMMDDHHmm. If busybox has 64-bit >> math enabled, then this can be compared with no problems, it just has >> to be munged into the format 'date' wants. > > So we can have compat and 64-bit math and have it properly behaving? Yes, I believe so. I'll work up the patch and test it now.
On 03/01/2012 06:06 PM, Gary Thomas wrote: >>> As far as I can recall (which is a really long time), 'date' has always >>> wanted the format MMDDHHmm[YYYY], so I think that's what we should >>> expect. >>> That format doesn't compare easily which is why the timestamp was >>> changed >>> (not by me) to a more ISO standard YYYYMMDDHHmm. If busybox has 64-bit >>> math enabled, then this can be compared with no problems, it just has >>> to be munged into the format 'date' wants. >> >> So we can have compat and 64-bit math and have it properly behaving? > > Yes, I believe so. I'll work up the patch and test it now. It might be very helpful for other developers if 64-bit math requirement of busybox would be documented somewhere. BR, Lauri
Patch
diff --git a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh index 20ec0a0..383de82 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/bootmisc.sh @@ -70,8 +70,8 @@ if test -e /etc/timestamp then SYSTEMDATE=`date -u +%4Y%2m%2d%2H%2M` read TIMESTAMP < /etc/timestamp - if [ ${TIMESTAMP} -gt $SYSTEMDATE ]; then - date -u $TIMESTAMP + if [ ${TIMESTAMP%????} -gt ${SYSTEMDATE%????} ]; then + date -u ${TIMESTAMP#????}${TIMESTAMP%????????} /etc/init.d/hwclock.sh stop fi fi
Recent changes have attempted to make consistant use of /etc/timestamp In particular 5aab665 initscripts: Make /etc/timestamp consistent again. 173a48f image.bbclass: Ensure timestamp matches format used in initscripts after recent changes This new format can cause problems as the value is too large for most [32 bit] machines. Work around this by only comparing the YYYYMMDD portion (which does fit in 32 bits). Also, the new format is not directly compatible with the 'date' command line, so it must be reformatted for use. Signed-off-by: Gary Thomas <gary@mlbassoc.com> --- .../initscripts/initscripts-1.0/bootmisc.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)