Sebastian Huber commented on a discussion: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1484#note_159630


The branch answers every point of my first review.  I built it on
`sparc/gr740` and ran the full test suite in four configurations.

## Test result

| Row | `RTEMS_SMP` | `RTEMS_DEBUG` and `RTEMS_POSIX_API` | Base d822f381652 | 
Branch 8a90da88 |
| ---------------- | --- | --- | 
-------------------------------------------------------------- | ---------- |
| `gr740`           | off | off | `dl06`                                        
                  | `dl06`     |
| `gr740-smp`       | on  | off | `dl06`                                        
                  | `dl06`     |
| `gr740-debug`     | off | on  | `dl06`, `psx09`, `spclock_err02`, 
`ts-validation-no-clock-0`    | `dl06`, `psx09` |
| `gr740-smp-debug` | on  | on  | `dl06`, `spclock_err02`, 
`ts-validation-no-clock-0`             | `dl06`     |

The table names the failures beyond the 24 filesystem tests which declare
`EXPECTED_FAIL`.  Those 24 and `dl06` fail in the base and in the branch.
`psx09` fails in `gr740-debug` in both.  This branch moves nothing else.

The two tests of the issue fail in both debug rows of the base.  They pass in
both debug rows of the branch.  The base fails this way:

```
assertion "_TOD_Is_valid_new_time_of_day( tod ) == STATUS_SUCCESSFUL" failed:
file "../../../cpukit/score/src/coretodset.c", line 57, function: _TOD_Set
```

Neither release row shows the defect.  That matches the issue.  A release
build tickles the realtime collection with a wrapped value and prints
nothing.

## The open item

The thread of @joel is the one discussion which stays open.  My position
stands.  The seconds field of a realtime watchdog tick holds 34 bits,
`cpukit/include/rtems/score/watchdogimpl.h:467`.  `_Watchdog_Tick()` converts
the current CLOCK_REALTIME on every tick.  A year above 2514 wraps that field. 
@joel, please resolve the thread or name the alternative.

## One point which needs no change

`TOD_SECONDS_1970_THROUGH_2400` keeps its name and holds 13601088000.  The
name states the count of seconds in the span 1970 through 2400.  That count is
13601088000, and the `>=` check makes the constant an exclusive bound.  No
rename is due.

## Small points

1. `cpukit/include/rtems/score/todimpl.h:141` still reads `This is the latest
   time of day which should be set by _TOD_Set().`  The constant is an
   exclusive bound after the `>=` change.  Write `A time of day below this
   value lies in the range which _TOD_Set() accepts.`

2. The branch deletes the forum link and the Y4K note.  @joel asked for that
   discussion.  Keep one sentence of the commit body which names the forum
   topic and the limit which the watchdog puts on it.

3. The commit body lists the six edits which the diff shows.  State the
   problem, then the approach.  The first paragraph holds the problem already.
   Drop the six list items.  The word `previously` also goes.  The commit
   removes that condition, so the simple past carries the fact on its own.

4. This point is older than the branch and sits next to the lines which the
   branch edits.  `cpukit/include/rtems/rtems/clock.h:113` names
   `2514-05-31T01:53:03.999999999Z`.  `WATCHDOG_MAX_SECONDS` is 17179869183,
   which is 2514-05-30T01:53:03Z.  The date is one day late.  The branch may
   fix it.

-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1484#note_159630
You're receiving this email because of your account on gitlab.rtems.org. 
Unsubscribe from this thread: 
https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-8c6csy10enl4rqouvnvr2ce2g-1d/unsubscribe
 | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | 
Help: https://gitlab.rtems.org/help


_______________________________________________
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs

Reply via email to