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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200809081629.21125.david-b@pacbell.net>
Date:	Mon, 8 Sep 2008 16:29:20 -0700
From:	David Brownell <david-b@...bell.net>
To:	David Miller <davem@...emloft.net>
Cc:	James.Bottomley@...senpartnership.com,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-parisc@...r.kernel.org,
	Alessandro Zummo <alessandro.zummo@...ertech.it>
Subject: Re: [PATCH] fix RTC_CLASS regression with PARISC

On Monday 08 September 2008, David Miller wrote:
> I think the powerpc folks did the wrong thing and should just register
> generic platform_device objects in their platform code, and let the
> RTC layer drive the individual devices in response.

I kind of thought that was a migration aid ... 


> All the powerpc folks are doing is providing a dummy shim into the
> RTC layer using their machine description vector, and not really using
> the RTC layer drivers at all.

I basically agree.  There's functional overlap between those
machine descriptions and the RTC framework, and it should be
removed (by shrinking those descriptions).  The shim gets
/dev/rtcN support, and thus hwclock; also /sys/class/rtc/*
stuff.  But no wake alarms...


That said, there's a bit of unresolved stuff around NTP hooks
in the kernel.  Some patches are pending to let thtem work with
the RTC framework -- where writing an RTC may need to sleep,
for example because the RTC is on an I2C or SPI bus.  And
then there's the discussion of whether that shouldn't all be
handled by NTPD anyway, no special kernel support desired.
Alessandro has opinions there.  ;)

ISTR that was a factor in the powerpc taking that "sideways"
step.  Or if not powerpc, then some other arch.

- Dave

--
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