Partial fix: Don't allocate a new string if the length is equal to the
old length, because presumably the old string was also nul terminated
so it has the extra byte needed.
The real fix is to keep an adjunct array of bits, one for each environment
variable and keep track if the entry was allocated or not so that we can
free it in unsetenv.
- use PUFFS_KFLAG_WTCACHE to puffs_init so that all writes are
immediatly send to the filesystem, and we do not have anymore write
after inactive. As a consequence, we can close files at inactive
stage, and there is not any concern left with files opened at
create time. We also do not have anymore to open ourselves in readdir and
fsync.
- Fsync on close (inactive stage). That makes sure we will not need to
do these operations once the file is closed (FUSE want an open file).
short sircuit the request that come after the close, bu not fsinc'ing
closed files,
- Use PUFFS_KFLAG_IAONDEMAND to get less inactive calls
== Removed nodes ==
- more ENOENT retunred for operations on removed node (but there
are probably some still missing): getattr, ooen, setattr, fsync
- set PND_REMOVE before sending the UNLINK/RMDIR operations so that we avoid
races during UNLINK completion. Also set PND_REMOVED on node we overwirte
in rename
== Filehandle fixes ==
- queue open operation to avoid getting two fh for one file
- set FH in getattr, if the file is open
- Just requires a read FH for fsyncdir, as we always opendir in read
mode. Ok, this is misleading :-)
== Misc ==
- do not set FUSE_FATTR_ATIME_NOW in setattr, as we provide the time
- short circuit nilpotent operations in setattr
- add a filename diagnostic flag to dump file names
link-time errors caused by conflicts with normal user-space libraries
when we link statically.
The tests still pass for i386 after this set of changes, and this now
builds for sun2 (after a few more changes).
one. Fixes a panic reported by njoly@ in private Email
2. Acquire the device before checking whether or not the get_limits
routine exists.
XXX There's still a bug in here somewhere that prevents setting of
XXX limit values after using 'envstat -S'
paddr_t has limited interest in userland, and should only be used by specific
code like kvm(3) (for VA => PA translations). To support non PAE and PAE
kernels simultaneously in kvm(3), promote paddr_t to 64 bits.
No objection on current-users@. See also:
http://mail-index.netbsd.org/current-users/2010/09/07/msg014249.html
Kernel remains untouched by this change. In-kernel 64 bits for paddr_t is for
a future commit (Yes, I do not forget about that :) )
-int _kvm_kvatop(kvm_t *, u_long, u_long *);
-off_t _kvm_pa2off(kvm_t *, u_long);
+int _kvm_kvatop(kvm_t *, vaddr_t, paddr_t *);
+off_t _kvm_pa2off(kvm_t *, paddr_t);
Basically, use vaddr_t for VA and paddr_t for PA. In addition, for variables
representing addresses, use paddr_t or vaddr_t, depending on the context.
For most arches, vaddr_t and paddr_t are equivalent to unsigned long. However,
the change was needed for exotic situations, like i386 PAE, were unsigned long
is not suitable for PA which are 64 bits long. As this required a complete
change of the function prototypes, all arches had to be adapted accordingly.
Core files from before this commit should still work with the new code; I did
not see any direct dependency between core's structure and kvatop/pa2off.
The change was compile tested for all arches, as it impacts all of them.
See also:
http://mail-index.netbsd.org/current-users/2010/09/07/msg014249.html