checkdiskconfig(): remove. It didn't make any sense to complain about
kernel keywords in user config files; it just made it more difficult
to convert. Now we ignore kernel keywords if we're not in kernel
mode.
get_empty_sd: initialize sectors.
free_drive: don't close if we don't have a vp. Maybe this will help
fix the problem that peter had, but I wouldn't count on it.
config_plex: If the plex is RAID-5, give it a rangelock structure.
start_config: Reset current drive, plex and volume so that a new
'create' command doesn't get long-dead defaults.
struct rqelement, enum rqinfo_type, struct rqinfo, union rqinfou: add
lock requests.
Add declarations for freerq and unlockrange. Since they include
request structures, they can't go in vinumext.h
stuff: unregister_methods() is horribly broken. The idea, if I'm not mistaken,
is that the refcount on a method is decremented, and only when it reaches
zero is the method freed. However desc->method is set to NULL unconditionally
regardless of the refcount, which means the method pointer is trashed the
first time the method is deallocated. The obvious detrimental effect is
that memory is leaked. The not so obvious effect is that when you call
unregister_method() the second time on the same method, you get a NULL
pointer dereference and a panic.
Now I can successfully unload network device drivers and the miibus module
without crashing the system.
*sigh*
A complete rewrite by dillon and myself to separate
the implementation of behaviors that effect the vm_map_entry
from those that effect the vm_object.
A result of this change is that madvise(..., MADV_FREE);
is much cheaper.
operations. This allows a device driver better insight into
what is going on that the current:
proc1: open /dev/foo R/O
devsw->open( R/O, proc1 )
proc2: open /dev/foo R/W
devsw->open( R/W, proc2 )
proc2: close
/* nothing, but device is
really only R/O open */
proc1: close
devsw->close( R/O, proc1 )
in deterministic behaviour. In this case known garbage out.
The fix is different than suggested in the PR.
PR: 12749
Originator: Boris Nikolaus <boris@cs.tu-berlin.de>
> The route(4) manpage says:
>
> User processes can obtain information about the routing entry to a spe-
> cific destination by using a RTM_GET message, or by reading the /dev/kmem
> device, or by issuing a getkerninfo(2) system call.
>
> IMHO, the above sentence should probably be altered by replacing the
> first comma with a period, and throwing away the rest of it.
No one's objected, so I've made this change. This sort of fixes docs/12220,
by removing the reference to the undocumented getkerninfo(2) call. So I'll
close the PR as well.
PR: docs/12220
This setting is also acceptable for Celerons and Pentium Pros
with less than 1MB L2 caches.
Note: PQ_L2_SIZE is a misnomer. The correct number of colors is
a function of the cache's degree of associativity as well as its size.
Submitted by: bde and alc
