Sort them, omit needless ones, and add omitted needful ones.
Omissions revealed by pilfering the code and trying to build it on
Mac OS X. We ought to have a better way to reveal these omissions...
- setattr_ttl is updated to add a flag argument. Since it was not present in
a previous release, we can change its API
- write2 is introduced, this is write with an extra flag for FAF.
- fsync already has the FAF information in a flag and needs no change
- for other operations, FAF is unconditional
* Corrected menu item neighbour calculation so it works when O_ROWMAJOR
is set and unset. This corrects item navigation which was previously
broken when O_ROWMAJOR was not set.
This resolves lib/46620.
http://mail-index.netbsd.org/port-xen/2012/06/25/msg007431.html
The xen_p2m API comes next.
ok bouyer@.
Tested on i386 PAE and amd64 (Xen 3.3 on private test bed, and
Xen 3.4 for Amazon EC2).
FWIW, Amazon always reported:
hypervisor0 at mainbus0: Xen version 3.4.3-kaos_t1micro
multiple times for Europe and US West-1, so I guess they are now at
3.4 (32 and 64 bits).
still reports a number of bytes transfered equal to bcount.
This then triggers a KASSERT in physio_biodone:
if (done == todo)
KASSERT(bp->b_error == 0);
Detect this case in wd(4) (so that the workaround works for other controllers
too if they have the same issue, or if the issue is with the drive)
and claim we didn't read/write anything.
trigger the following warning when gcc-4.5 was silent:
nd6_rtr.c: In function 'nd6_ra_input':
nd6_rtr.c:788: warning: 'ext' may be used uninitialized in this function
Eventually determined that it was not unreasonable for gcc-4.1 to
bleat in this case as there is a nasty 'goto insert' which could
indeed have resulted in an uninitialised variable use. Yay gcc 4.1.
in the eighties but that time has long past. Minimally invasive
fix using a temporary long variable, so while we can still overflow
at least we're less broken.
Especially, remove the special treatment when |x| < 1
because it forgets to consider FPCR round mode.
See PR/46627 for the detail. Thanks Y.Sugahara for advice.
Interested readers can follow the references or read Wikipedia; this
is the wrong place to explain cryptographic hash functions and give
security advice.
save/restore.
For an unknown reason (to me) Xen refuses to update VM translations
when the entry is pointing back to itself (which is precisely
what our recursive VM model does). So enable the functions that take
care of this, which will avoid all sort of memory corruption upon restore
leading domU to trample upon itself.
Save/restore works again for amd64. The occasional domU frontend corruption is
still present, but is harmless to dom0. Now we have a working shell and
ddb inside domU, that helps debugging a tiny bit.
XXX pull-up to -6.
