Emmanuel Dreyfus m...@netbsd.org wrote:
Or just avoid uvm_vnp_setsize() calls?
I wonder is that does not open the door to situation where fsync
semantics gets broken, because of a skiped uvm_vnp_setsize().
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
We would have a PNODE_IN_RESIZE flag for struct pnode's pn_stat, set and
cleared in dosetattr(), and use vp-v_size on uvm_vnp_setsize() calls
when set? Or just avoid uvm_vnp_setsize() calls?
just avoid the calls.
There is a problem if two
Emmanuel Dreyfus m...@netbsd.org wrote:
Or just avoid uvm_vnp_setsize() calls?
I wonder is that does not open the door to situation where fsync
semantics gets broken, because of a skiped uvm_vnp_setsize().
nothing i can think of right now.
do you have a particular idea what semantics
YAMAMOTO Takashi y...@mwd.biglobe.ne.jp wrote:
do you have a particular idea what semantics might be broken?
Not sure, I am still searching.
Here is a current posible behaviour:
thread1 puffs_vnop_setattr dosetattr size1 SETATTR size1 sent
thread2 puffs_vnop_write uvm_vnp_setsize
On Aug 22, 2011, at 2:04 PM, paul_kon...@dell.com paul_kon...@dell.com
wrote:
I would think that memory errors are far more likely than cache errors. If a
CPU gets cache errors, it is very badly broken.
Probably true but.
I'm not sure it's worth doing anything other than panic for cache
besides panicing, of course.
Ideally, I think...
Corrected error: Usually, log and ignore. Maybe watch for elevated
levels of corrected errors and disable either the containing page or
the containing memory stick, depending on how much the hardware lets
the kernel determine and maybe policy
I'm trying to modularize a couple of drivers, and one of them is
generating some gcc errors due to comparison of signed and unsigned
values.
The driver module is currently being compiled with WARNS=4 (just picked
that up from another Makefile). Is there a more appropriate WARNS=n to
use to
In article pine.neb.4.64.1108222146340.22...@screamer.whooppee.com,
Paul Goyette p...@whooppee.com wrote:
I'm trying to modularize a couple of drivers, and one of them is
generating some gcc errors due to comparison of signed and unsigned
values.
The driver module is currently being compiled
[...] gcc errors due to comparison of signed and unsigned values.
It is best to fix the errors.
What errors?
It is not necessarily an error to compare signed and unsigned values.
In my experience, that warning produces so many more false positives
than useful warnings that I normally shut it
