Re: kern/40384 (64 bit time_t broke wscons)

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR kern/40384; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
        netbsd-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: kern/40384 (64 bit time_t broke wscons)
Date: Wed, 14 Jan 2009 11:23:53 -0500

 On Jan 15,  1:05am, yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) wrote:
 -- Subject: Re: kern/40384 (64 bit time_t broke wscons)
 
 | > On Jan 14, 11:57pm, yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) 
wrote:
 | > -- Subject: Re: kern/40384 (64 bit time_t broke wscons)
 | > 
 | > | it flushes the queue, yes.  but it seems unsafe to me.
 | > | eg. if malloc() sleeps.
 | > | eg. if someone is in the middle of wsevent_read().
 | > | necessary locking complicates the code more, i guess.
 | > 
 | > Got it. Fixed.
 | > 
 | > Thanks,
 | > 
 | > christos
 | 
 | well, have you checked whether it's safe even if every EVSIZE()
 | returns different values due to concurrent setversions?
 
 >From a cursory glance, the worst that can happen is that you get junk data.
 
 | with the way i suggested, only uiomove in wsevent_read and
 | _INJECT ioctl needs conversion, right?  would it be so complicate?
 
 It is not too complicated (I think), go ahead and change it if you want.
 I just wanted to keep knowledge of the compat stuff only in wsevent.c.
 
 christos