From owner-svn-src-head@FreeBSD.ORG Sun Oct 13 18:08:31 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50CAADB9; Sun, 13 Oct 2013 18:08:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB7352FB1; Sun, 13 Oct 2013 18:08:30 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id i13so1926002qae.1 for ; Sun, 13 Oct 2013 11:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lnK0LsSUfg4NK1RKB/QG+4NYiTGbZARxyyuxmrnKbNo=; b=GAbRNnoyGetChKAth35Aj5UX7NSRzhEpl2u00/EE5xEgfj97RfQMMU19g9gMCU2oKe c1r4M1RpMR/2yj/P2g3lQ+hRrjViUd5X7Smwe6AExVkS7MM40G6DzLjXBbGfWNsVUlXL A1VluESk1ZXwyq0VvuBLr8i4BqgTuLCHHbWTHa0aS4S9E6q5Y/pjM/lC4AsiwYYIZEU3 In4A/Xijr+HT7cGXGfGnT7ZKvyEHE4AMbjGJnNPMpCAt9AvkjaMrUFZRfuW3q59Uvp7l EbvO34I2ESvMkgVQTffcwHSRk+f+QEL3R7zIUqPvrGeFQ8qgr/BE/kMNncdI6DZzF8sA wtCQ== MIME-Version: 1.0 X-Received: by 10.224.23.66 with SMTP id q2mr2525347qab.100.1381687709923; Sun, 13 Oct 2013 11:08:29 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Sun, 13 Oct 2013 11:08:29 -0700 (PDT) In-Reply-To: <6E7CF22B-B83B-4F31-955D-DC64441FAC8D@grondar.org> References: <201310121257.r9CCvvjO006546@svn.freebsd.org> <20131013074825.GO41229@kib.kiev.ua> <3B77143C-7D82-4E62-9974-BC2C6846893F@grondar.org> <20131013151359.GR41229@kib.kiev.ua> <812C1C64-75B0-4FE9-8FCD-B25A484448C6@grondar.org> <1381681119.42859.33.camel@revolution.hippie.lan> <6E7CF22B-B83B-4F31-955D-DC64441FAC8D@grondar.org> Date: Sun, 13 Oct 2013 11:08:29 -0700 X-Google-Sender-Auth: 7WjZcc1n6TEw1VijfIDVnGgchOg Message-ID: Subject: Re: svn commit: r256377 - in head: etc/defaults etc/rc.d share/examples/kld/random_adaptor share/man/man4 sys/boot/forth sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe ... From: Adrian Chadd To: Mark R V Murray Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" , Ian Lepore X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2013 18:08:31 -0000 Hi Mark, Can we make the VFS random seeding stuff a compile time option, so we can disable it for the embedded platforms where we'll never use it? Thanks, -adrian On 13 October 2013 10:03, Mark R V Murray wrote: > > On 13 Oct 2013, at 17:18, Ian Lepore wrote: > > > On Sun, 2013-10-13 at 16:18 +0100, Mark R V Murray wrote: > >> On 13 Oct 2013, at 16:13, Konstantin Belousov > wrote: > >>> Surely this works, thank you. The rwfile.c content probably should be > >>> taken under the #ifdef RANDOM_RWFILE. > >> > >> OK - thanks for the feedback! > >> > >>> But I do not see much use for the randomdev_read_file() and > >>> randomdev_write_file() functions. It would be better to directly code > >>> the VFS calls in the random_harvestq_cache(). For one thing, it would > >>> eliminate unneccessary close and open of the entropy file. > >> > >> There is some uncertainty about the future of that code, so I want > >> to keep it that way for now. Writing files from the kernel is making so@ > >> very uncomfortable, and there is too much scope for error there. > >> > > > > Indeed, it makes me nervous too, as a heavy user of readonly root > > filesystems. If writing this file is so critical that it has to be done > > by the kernel, then what happens when it fails? Right now it prints an > > error and continues -- if it is not so critical that failure means > > panic, then why is the kernel doing it at all? > > Good points all. The intent is not to win the arms-race outright, but to > win the common-case battles as convincingly as possible. That said, its > not looking good for the process, but I still want to give it a decent > look before/if yanking it. > > > Why is the file even in the root filesystem? /var/db seems to be the > > right place for a transient file needed by the system. > > Because that appears to be the best place to put first-boot entropy from > sysinstall/bsdinstall. /var/db/entropy/... will also be used if possible; > watch this space. > > > Speaking of errors, that might include things like the current code > > calling vn_close() with the FREAD flag on a file open for writing. > > > Thanks :-( :-) > > M > -- > Mark R V Murray > >