The original code was certainly broken; it knows that whereto is
to be used for a sockaddr_in, so it should be declared as such.
To support multiple protocols, there is also a sockaddr_storage
struct that can be used; I don't think struct sockaddr is supposed
to be used anywhere other than for casts and pointers.
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
MFC after: 3 weeks
This one is strange and goes against my rusty compiler knowledge.
The global declaration
struct sockaddr whereto;
produces for both i386 && alpha:
.comm whereto,16,1
which means common storage, byte aligned. Ahem. I though structs
were supposed to be ALDOUBLE always? I mean, w/o pragma packed?
Later on, this address is coerced to:
to = (struct sockaddr_in *)&whereto;
Up until now, we've been fine on alpha because the address
just ended up aligned to a 4 byte boundary. Lately, though,
it end up as:
0000000120027b0f B whereto
And, tra la, you get unaligned access faults. The solution I picked, in
lieu of understanding what the compiler was doing, is to put whereto
as a union of a sockaddr and sockaddr_in. That's more formally correct
if somewhat awkward looking.
prematurely terminate the search for a usable disk. ENOENT is quite
normal in particulare now with the advent of devfs.
While being here, also remove /dev/wd0 and /dev/od0 from the list of
disks to search since we don't have them anymore.
MFC after: 1 week
backslash as nothing, treat it like a space so that adjacent lines
aren't glued together.
PR: 8479
Submitted by: Adrian Filipi-Martin <adrian@ubergeeks.com>
user runs with privilege, allowing the sending of icmp packets with
larger size (up to 48k, the default receive buffer size in ping),
which is useful for network driver development testing, as well
as experimentation with fragmentation.
Reviewed by: wpaul
ensure that we never proceed with the mount() syscall if the server
is replying from the wrong source address. Previously the userland
RPC call to the remote nfsd would succeed, but the kernel uses
connect() so it would not see the replies, resulting in a hung
mount.
NQNFS code is ancient, bug-ridden, and should probably be removed).
The wording here was very confusing; it was easy to get the impression
that NQNFS is an extension to NFSv3 when in fact it just uses some
NFSv3-like extensions on top of NFSv2. As witnessed by the mailing
lists and PRs, some people were reading the description and deciding
that NQNFS was what they wanted to use.
MFC after: 1 week
