| Age | Commit message (Collapse) | Author |
|---|
|
curproc. A bunch of callers were passing in 0 (not even NULL, 0) as this
pointer, which was fine until the called vnode function tried to do
something with it. Typically, this code was then copy/pasted to various
parts of the tree.
Accept the facts of life and switch all of these over to passing curproc
for now until the argument can be removed.
Discovered by stsp trying to create a softraid on top of a vnd, which
crashed with a NULL deref in vndioctl.
softraid bits tested by mikeb and jsing. raidframe bits tested by pea,
matthieu and naddy. The rest tested by at least thib, jsing and myself.
ok thib@, jsing@.
|
|
have been resolved.
|
|
vector setup that has questionable features (that have, as far as I can
tell never been used in practice, atleast not in OpenBSD), remove all
the gunk and favor a simple struct full of function pointers that get
set directly by each of the filesystems.
Removes gobs of ugly code and makes things simpler by a magnitude.
The only downside of this is that we loose the vnoperate feature so
the spec/fifo operations of the filesystems need to be kept in sync
with specfs and fifofs, this is no big deal as the API it self is pretty
static.
Many thanks to armani@ who pulled an earlier version of this diff to
current after c2k10 and Gabriel Kihlman on tech@ for testing.
Liked by many. "come on, find your balls" deraadt@.
|
|
sync a few comments to reality (or remove them), remove the cn_hash member
from struct componentname, spacing.
ok beck@
|
|
this appears to fix a mmap vs read sync issue I've been seeing since forever
ok thib@
|
|
which is exactly what the macro does.
Macro's that are nothing more then:
#define FUNCTION(arg) function(arg)
are almost always pointless and should go away.
OK blambert@
Agreed by many.
|
|
allocator).
"i can't see any obvious problems" oga
|
|
arches. ok todd@ beck@
|
