to gzip when compressing so it doesn't store the timestamp in the file
header. For MKREPRO, but unconditional as the information omitted isn't
particularly useful. PR 50116.
reset. If you had previously switched to 1.8V signaling level, upon reboot
the card will still be in 1.8V mode and you cannot detect it with an S18R
request.
A card in 1.8V mode will report UHS modes though, so if the card reports
SDR50, DDR50, or SDR104 capabilities, and the previous S18R request failed
to switch, use this as an opportunity to re-enable UHS support in the
subsystem and host controller drivers.
Last year when I killed off some evil dirop-related macros, I added
these assertions because if the things they asserted weren't true we'd
be leaking vnodes. Well, it seems that the code at the time did leak
vnodes, so certain failure cases (e.g. mkdir with disk full) would
assert. Nobody apparently tripped on this in the past fourteen months,
until I broke balloc so it always failed (unrelatedly) while working
on some LFS64 changes.
However, the vnode leak has since been removed by hannken@ as part of
the vnode cache changes, so the assertions are now superfluous;
instead, just make sure *vpp gets nulled on failure, and don't worry
about whether or not VU_DIROP is set as it shouldn't matter any more.
XXX: there's still a lot of gratuitous pointer aliasing in here that
should be tidied away.
ndp(8) uses RTM that requires that getpid(2) works correctly. Unfortunately
supporting getpid(2) in librumphijack will be tricky so that we rump-ify
ndp(8) as well as arp(8).
2. honor O_CLOEXEC, so the children of daemons that use cloning devices, don't
end up with the parents descriptors
fd_clone and in general the fd approach of 'allocate' > 'play with guts' >
'attach' should be converted to be more constructor like.
XXX: pullup-{6,7}
Remove some hackish intentional 64->32 truncations next to the checks
using LFS_MAX_DADDR, and tackle the problem they handled in bmap
instead.
The problem: the magic block pointer value UNWRITTEN has magic value
-2, and if it's not handled specifically, uint32 -> uint64 promotion
turns it into 4294967294, which then causes consternation and
monkeyhouse downstream.
What's here is still kind of a hack, but it's a step forward.
Add pieces of support for using both superblock types where
convenient, and specifically to the superblock accessors, but don't
actually enable it anywhere.
First substantive step on PR 50000.
(lfs_curseg/lfs_nextseg in the superblock) using the wrong units.
These fields are for whatever reason the start addresses of segments
(measured in frags) rather than the segment numbers 0..n.
This only apparently affects dumping from a mounted fs; however, it
trashes the fs.
I would really, really like to have a static analysis tool that can
keep track of the units things are measured in, since fs code is full
of conversion macros and the macros are named inscrutable things like
"sntod" whose letters don't necessarily even correspond to the units
they convert. It is surprising that more of these are not wrong.
in blocks instead of frags, so use lfs_blkstofrags to correct it.
This code was instead multiplying by the block size divided by
DEV_BSIZE to get the number of disk blocks rather than the number of
frags. (I gather that originally these were the same, but they're not
necessarily any more.)
