lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060725222547.GA3973@localhost.localdomain>
Date:	Tue, 25 Jul 2006 18:25:47 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Dave Airlie <airlied@...il.com>,
	Segher Boessenkool <segher@...nel.crashing.org>,
	linux-kernel@...r.kernel.org, a.zummo@...ertech.it,
	jg@...edesktop.org
Subject: Re: [PATCH] RTC: Add mmap method to rtc character driver

On Tue, Jul 25, 2006 at 01:50:52PM -0700, H. Peter Anvin wrote:
> Neil Horman wrote:
> >
> >Agreed.  How about we take the /dev/rtc patch now (since its an added 
> >feature
> >that doesn't hurt anything if its not used, as far as tickless kernels 
> >go), and
> >I'll start working on doing gettimeofday in vdso for arches other than 
> >x86_64.
> >That will give the X guys what they wanted until such time until all the 
> >other
> >arches have a gettimeofday alternative that doesn't require kernel traps.
> >
> 
> It hurts if it DOES get used.
> 
Yes, but if its in trade for something thats being used currently which hurts
more (case in point being the X server), using this solution is a net gain.

I'm not arguing with you that adding a low res gettimeofday vsyscall is a better
long term solution, but doing that requires potentially several implementations
in the C library accross a range of architectures, some of which may not be able
to provide a time solution any better than what the gettimeofday syscall
provides today.  The /dev/rtc solution is easy, available right now, and applies
to all arches.  It has zero impact for systems which do not use it, and for
those applications which make a decision to use it instead of an alternate
method, the result I expect will be a net gain, until such time as we code up,
test and roll out a vsyscall solution 

Thanks & Regards
Neil 
> 	-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ