mutex instead of a MTX_DEF one in order to defer preemption while
reading the date and time registers. If we don't manage to read them
within the time slot where we are guaranteed that no updates occur we
might actually read them during an update in which case the output is
undefined.
- Add locking.
- Account for if the MC146818_NO_CENT_ADJUST flag is set we don't need
to check wheter year < POSIX_BASE_YEAR.
- Add some comments about mapping the day of week from the range the
generic clock code uses to the range the chip uses and which I meant
to add in the initial version.
- Minor clean-up, use __func__ instead of hardcoded function names in
error strings.
o in the rtc(4) front-end additionally:
- Don't leak resources in case mc146818_attach() fails.
- Account for ebus(4) defaulting to SYS_RES_MEMORY for the memory
resources since ebus.c rev. 1.22.
respective NetBSD driver for use with the genclock interface.
It's first use will be on sparc64 but it was also tested on alpha with
a preliminary patch to switch alpha to use the genclock code together
with this driver instead of the respective code in alpha/alpha/clock.c
and the rather MD mcclock(4). Using it on i386 and amd64 won't be that
hard but some changes/extensions to improve the genclock code in general
should be done first, e.g. add locking and make it easier to access the
NVRAM usually coupled with RTCs.
* Eliminate bus_t and make it possible for all devices to have
attached children.
* Support dynamically extendable interfaces for drivers to replace
both the function pointers in driver_t and bus_ops_t (which has been
removed entirely. Two system defined interfaces have been defined,
'device' which is mandatory for all devices and 'bus' which is
recommended for all devices which support attached children.
* In addition, the alpha port defines two simple interfaces 'clock'
for attaching various real time clocks to the system and 'mcclock'
for the many different variations of mc146818 clocks which can be
attached to different alpha platforms. This eliminates two more
function pointer tables in favour of the generic method dispatch
system provided by the device framework.
Future device interfaces may include:
* cdev and bdev interfaces for devfs to use in replacement for specfs
and the fixed interfaces bdevsw and cdevsw.
* scsi interface to replace struct scsi_adapter (not sure how this
works in CAM but I imagine there is something similar there).
* various tailored interfaces for different bus types such as pci,
isa, pccard etc.
work in progress and has never booted a real machine. Initial
development and testing was done using SimOS (see
http://simos.stanford.edu for details). On the SimOS simulator, this
port successfully reaches single-user mode and has been tested with
loads as high as one copy of /bin/ls :-).
Obtained from: partly from NetBSD/alpha
