datastructures allowed! Punt.
accessTraceBufCount, rf_accessTraceBufSize, and
rf_stopCollectingTraces are similarly declared, initialized, and then
never changed. Punt.
rf_ShutdownAccessTrace() now does nothing. Remove it, and the
callback setup stuff from rf_ConfigureAccessTrace().
wdc_drvprobe() function. wdc_drvprobe() is used if the controller
does not specify a custom one prior to calling wdcattach(). The
WDC_CAPABILITY_DRVPROBE bit is gone.
virtual memory reservation and a private pool of memory pages -- by a scheme
based on memory pools.
This allows better utilization of memory because buffers can now be allocated
with a granularity finer than the system's native page size (useful for
filesystems with e.g. 1k or 2k fragment sizes). It also avoids fragmentation
of virtual to physical memory mappings (due to the former fixed virtual
address reservation) resulting in better utilization of MMU resources on some
platforms. Finally, the scheme is more flexible by allowing run-time decisions
on the amount of memory to be used for buffers.
On the other hand, the effectiveness of the LRU queue for buffer recycling
may be somewhat reduced compared to the traditional method since, due to the
nature of the pool based memory allocation, the actual least recently used
buffer may release its memory to a pool different from the one needed by a
newly allocated buffer. However, this effect will kick in only if the
system is under memory pressure.
- nothing needs to be done if ci_want_resched is already set.
- if the cpu isn't running any lwp, send a no-op ipi to it
so that it can resume immediately from halting in idle loop
without having to wait until the next clock tick.
some advices from Stephan Uphoff.
- pmap_enter: zap PTE and read attributes atomically to
eliminate a race window which could cause lost of attributes.
- reduce number of TLB shootdown by using some assumptions
about PTE handling.
for more details, see "SMP improvements for pmap" thread on port-i386@
around May 2003.
need the data in the mbuf later and m_clget() changes some fields
overlaid to regular mbuf data. Instead, rearange code a bit, create
data into a new allocated buffer and and use MEXTADD to attach it to
the mbuf, if the mbuf internal space is not sufficient.
This fixes a crash on sparc64 (and probably all other archs where
sizeof(int) != sizeof(struct file *)) when running
regress/sys/kern/unfdpass.
Idea for solution from Matt Thomas, with additional input from YAMAMOTO
Takashi.
- hpc1_hdd_{ctl,bufptr} and hpc3_hdd_{ctl,bufptr} are
established in hpcreg.h. All references to these fields
are updated with the exception of if_sq: (haltwo,
hpcdma). This makes reading the code and spotting bugs
easier.
- hpcdma.c was applying EOCHAIN to the wrong descriptor
word for the hpc1 case.
- I added scsi_max_xfer to the abstraction layer, and it
allows some crusty #defines in wdsc.c to be removed.
hpc1 now doesn't waste descriptors as it once did.
- hpcreg.h was updated to reflect the lack of XMITDONE
bit in hpc1. HPC1_REV15 added for a test in hpc.c
- hpc.c now verifies HPC1 revisions (1.0 vs 1.5) and
prints the output a little prettier ;)
- power interrupts shouldn't establish on non-IP22
platforms.
can't fail. Simplify life in rf_BootRaidframe(), and then nuke
rf_lkmgr_mutex_init(). Cleanup rf_threadstuff.h a bit more too.
rf_threadstuff.c is about to Go Away.
(other than NULL when raidPtr is initialized). That means
SignalReconDone() never does anything useful. Bye-bye!
Say good-bye to recon_done_procs and recon_done_procs_mutex (and its
initializer) as well.
Mash DO_RAID_COND in rf_driver.c out of existance.
- Nuke (already #if 0'ed) _rf_create_managed_lkmgr_mutex() while we're
busy here.
simplify DO_INIT in rf_engine.c
here" department.
remove _rf_init_threadgroup() and rf_destroy_threadgroup() which were
already #if 0'ed.
rf_cond_destroy() does nothing. Nuke it, and all callers.
rf_cond_init() doesn't deserve to be a separate function any more.
Fix up the remaining 3 callers, and nuke rf_cond_init().
Another 0.4K goes "poof", but still no functionality lost!
rf_mutex_init(m)
now. The rest of the fluff is no longer needed.
It also cannot fail, so error checking on rf_create_managed_mutex()
is just wasting space.
Nuke the #define's associated with rf_create_managed_mutex().
Convert rf_create_managed_mutex(listp,m) to just rf_mutex_init(m).
Remove wasteful "error checking" and simplify all instances where this
is called. (another 0.3K saved in the binary, but the real savings
is in code readability!)
neither of these ever fail, no need to have a return value. That
makes all the "error detection" on these functions completely
unneeded. But since we're here, if we don't have a return value, then
why not make these macros? My.. look how things keep shrinking, with
no loss in functionality!
clean_rad() were -- these days they only serve to clutter things up.
Remove the functions, and put the 2 lines of actual useful initialization
into rf_AllocMCPair().
to make things look far more complicated than they really are. It was
also impossible for any of the mutex/cond initializations in
init_rad() to actually fail, making the "error detection code"
unneeded. Collapse the little work done by init_rad into
rf_AllocRaidAccDesc(), and nuke init_rad() and clean_rad(). Save
another 0.25K in GENERIC.
[To be accurate/complete, init_rad() and clean_rad() *ARE* used in the
simulator version of RAIDframe. But we're so far removed from that
now that there is no point pretending otherwise.]
- all freelists converted to pools
- initialization of structure members in certain cases where
code was relying on specific allocation and usage properties
to keep structures in a "known state" (that doesn't work with
pools!).
- make most pool_get() be "PR_WAITOK" until they can be analyzed
further, and/or have proper error handling added.
- all RF_Mallocs zero the space returned, so there is no difference
between RF_Calloc and RF_Malloc. In fact, all the RF_Calloc()'s
do is tend to do is get things horribly confused.
Make RF_Malloc() the "general memory allocator", with
RF_MallocAndAdd() the "general memory allocator with
allocation list".
- some of these RF_Malloc's et al. are destined to disappear.
- remove rf_rdp_freelist entirely (it's not used anywhere!)
- remove: #include "rf_freelist.h"
- to the files that were relying on the above, add: #include "rf_general.h"
- add: #include "rf_debugMem.h" to rf_shutdown.h to make it happy
about the loss of: #include "rf_freelist.h".
This shrinks an i386 GENERIC kernel by approx 5K. RAIDframe now
weighs in at about 162K on i386.
of strenuous agreement, and some general agreement, this commit is
going ahead because it's now starting to block some other changes I
wish to make.]
Remove most of the support for the concept of "rows" from RAIDframe.
While the "row" interface has been exported to the world, RAIDframe
internals have really only supported a single row, even though they
have feigned support of multiple rows.
Nothing changes in configuration land -- config files still need to
specify a single row, etc. All auto-config structures remain fully
forward/backwards compatible.
The only visible difference to the average user should be a
reduction in the size of a GENERIC kernel (i386) by 4.5K. For those
of us trolling through RAIDframe kernel code, a lot of the driver
configuration code has become a LOT easier to read.
being requested so that (1) the uniprocessor case and the
multiprocessor case are more similar and (2) so that we return ENOENT
when a non-existent processor is requested (which is both more
sensible and follows the general order of things anyway).
domainname. Note that there's no need to copy rnode since we're not
changing any of it, nor protecting anything from change.
Thanks to martin for initial work.
raised the exception, don't release the lock, this causes a crash (the lock
shall be released by the process that took it). Wakeup the thread instead,
it will release the lock itself.
some iBook and PowerBook models.
this driver was written by Tsubai Masanari and further hacked on by
Jared D. McNeill to work on his iBook.
the driver is limited (master volume control only, and I haven't
tested recording) but has been functioning perfectly on my PowerBook
g4 DVI (ivory) for some time.
ok'd by matt.