Renaming a file of any non-directory type over another file of any
other non-directory type is OK -- they need not match as long as
neither is a directory, so loosen the kassert to reflect this.
XXX Need to write test cases for this.
ok dholland, rmind
the inode in the guts of ufs. Now, in VOPs where i_crap is used it is
used (directly) only immediately on entry to the VOP call and then
passed around by reference.
Except for rename, which needs explicit sorting out. The code in
ufs_wapbl_rename is unchanged in behavior but I'm increasingly
inclined to think it's wrong.
for the assembler files, define the old names to the new names
since using the new names cause ugliness due to longer identifer
names, and reduces churn.
fixes build issues in dtv and vaguely makes <machine/psl.h> slightly
less name-space invasive.
the vnode when lookup returns and fished out again later.
1. Create struct ufs_lookup_results to hold these.
2. Call the ufs_lookup_results instance in struct inode "i_crap" to be
clear about exactly what's going on, and to distinguish the lookup
results from respectable members of struct inode.
3. Update references to these members in the directory access
subroutines.
4. Include preliminary infrastructure for checking that the i_crap
being used is still valid when it's used. This doesn't actually do
anything yet.
5. Update the way ufs_wapbl_rename manipulates these elements to use
the new data structures. I have not changed the manipulation; it may
or may not be correct but I continue to suspect that it is not.
The word of the day is "stigmergy".
VOPs do. Layered file systems no longer have to modify bp->b_vp and run
into trouble when an async VOP_BWRITE() uses the wrong vnode.
- change all occurences of VOP_BWRITE(bp) to VOP_BWRITE(bp->b_vp, bp).
- remove layer_bwrite().
- welcome to 5.99.55
Adresses PR kern/38762 panic: vwakeup: neg numoutput
No objections from tech-kern@.
VOPs do. Layered file systems no longer have to modify bp->b_vp and run
into trouble when an async VOP_BWRITE() uses the wrong vnode.
Adresses PR kern/38762 panic: vwakeup: neg numoutput
No objections from tech-kern@.
fails, make sure that the following nm -u's success doesn't cause make
to believe the target was built. now amiga builds with HAVE_GCC=45
actually fail here, rather than fail at sets time due to missing files.
dyoung