Patchwork initscripts: Properly handle new timestamp format

login
register
mail settings
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

Gary Thomas - March 1, 2012, 2:43 p.m.
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(-)
Richard Purdie - March 1, 2012, 2:59 p.m.
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
Gary Thomas - March 1, 2012, 3:11 p.m.
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.
Gary Thomas - March 1, 2012, 3:27 p.m.
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.
Richard Purdie - March 1, 2012, 3:44 p.m.
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
Gary Thomas - March 1, 2012, 3:52 p.m.
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.
Otavio Salvador - March 1, 2012, 4:01 p.m.
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.
Otavio Salvador - March 1, 2012, 4:04 p.m.
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?
Gary Thomas - March 1, 2012, 4:06 p.m.
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.
Lauri Hintsala - March 2, 2012, 6:15 a.m.
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