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]
Date:   Sat, 14 Nov 2020 11:23:20 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>
Cc:     陈华才 <chenhc@...ote.com>,
        Roman Kiryanov <rkir@...gle.com>,
        Huacai Chen <chenhuacai@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Lingfeng Yang <lfy@...gle.com>, Rob Herring <robh@...nel.org>,
        anup.patel@....com, Alistair.Francis@....com, qemu-riscv@...gnu.org
Subject: Re: Re: [PATCH] drivers: rtc: retire RTC_DRV_GOLDFISH

On Sat, Nov 14, 2020 at 05:47:47PM +0800, Jiaxun Yang wrote:
> 
> 
> 在 2020/11/14 下午4:15, Greg KH 写道:
> 
> + qemu-riscv list and QEMU device maintainers of goldfish_rtc
> 
> > On Sat, Nov 14, 2020 at 04:06:24PM +0800, 陈华才 wrote:
> > > Hi, All,
> > > 
> > > Goldfish RTC works well on MIPS, and QEMU RISC-V emulator use Goldfish
> > > as well, so I think  we should keep it in kernel.
> > But does anyone actually use it for anything?  Having something in qemu
> > is nice, but not required if it doesn't provide something that is
> > already there for other virtual devices, right?
> 
> Hi all,
> 
> Both QEMU MIPS loongson3-virt and riscv virt machine are using goldfish_rtc
> as sole RTC
> device, it have been hardcoded in QEMU for a long while and sudden drop in
> kernel would
> break these machines.
> RTC is essential for virt machines to keep time synchronized with host.
> 
> Given that it is the simplest RTC implementation for now, it won't give us
> much maintenance
> overhead.
> 
> Thus I do think it shouldn't be retired as for now. If nobody comes in I'd
> also willing to maintain
> it.

Ok, can someone submit a patch to update the MAINTAINERS file for this
so we know who to route issues to over time?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ