Date: Thu, 11 Jan 2001 14:40:49 -0800 (PST) From: Doug Barton <DougB@gorean.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: Sheldon Hearn <sheldonh@uunet.co.za>, <obrien@freebsd.org>, <cvs-committers@freebsd.org>, <cvs-all@freebsd.org> Subject: Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh Message-ID: <Pine.BSF.4.31.0101111412320.11112-100000@dt051n37.san.rr.com> In-Reply-To: <200101111912.f0BJCst72747@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Jan 2001, Matt Dillon wrote: > The level of sophistication and the number of hacks is *NOT* *NECESSARY* > when a simple, minor restructuring of /etc/rc and a tiny change to > mount_mfs (newfs) completely solves the problem. > > You guys are taking a bad idea and making it worse. > > I will be happy to submit a patchset to fix this mess, but it's so damn > simple Doug should be able to do it himself in less then an hour. You know, I thought I've repeated the mantra of, "The yarrow project is a work in progress and will probably be undergoing some changes as it develops" often enough that it wasn't necessary for me to repeat it again with this commit. Obviously I was wrong. The problem that placing this directory in / solves is that while I agree that for the most part var should be for variable things, / needs to have the things that the system needs to boot, and right now we have a chicken and egg problem with mounting certain types of filesystems that need randomness. Thanks to Sheldon for laying out the problems in detail. My goal for this initial step in the process was to get the ball rolling with a solution that is A) totally configurable (did anyone actually read the code?) and B) looks enough like what we want the final product to look like to give us a good idea as to whether we are heading in the right direction or not. The defaults I committed will work for the vast majority of -current users, and those for whom it does not work can either reconfigure the defaults or turn the thing off. (Did anyone actually read the code?) Again, I really thought this was all obvious, but clearly I failed to communicate my intentions, for which I apologize. Yes, periodically writing things into / is "non-traditional" to say the least, but I don't think it's going to set anyone's house on fire either. Now, given the current situation, and given that there were no (or so few that I have let them slip from memory) negative comments about placing the entropy file from rc.shutdown in /, I thought that /.entropy was a reasonable _default_ while we developed the idea further. It's a dot directory for the simple reason that it's a "behind the scenes" thing that you don't really need to see. Now I agree completely that it would be better in the long term to put the default location somewhere in /var. In order to make that work however we need to make some changes to other parts of the system. While I appreciate Matt's confidence, and while I'm sure that I probably could fix the mfs boot code, I wouldn't touch it with a 10' pole for the simple reason that I don't use it, and wouldn't have a solid grasp as to whether I was breaking things or not. I would welcome any assistance offered in understanding and/or straightening out the issues involved with mounting file systems that need randomness, of whatever quality. The other thing I considered last night was changing the mounting order in rc to mount /var right after root, possibly read only the way root is done now. There are a couple problems with that, most notably the variety of ways that people handle /var. I myself have /var as a seperate filesystem which is why I first got interested in the problem of how to handle the entropy seed files. I also feel strongly that when you are developing a new system that changes should be made in both a gradual and reversible way. Thus you can both easily identify the source of bogons that appear as a result of your changes, and ultimately fix them faster. The only "pain" that this temporary situation might cause down the road is a defunct directory to rm. Finally, has anyone missed the point that this system (in whatever form) will virtually eliminate the complaints currently being levelled against the /dev/random development that if it can't find a seed file it hangs for an unacceptably long period of time during boot? You (pl.) criticize Mark for not bringing a major advancement in our level of randomness production into life full born, then you criticize each development step along the way. I'm lucky in the sense that I am only involved in the fringes, but this kind of sniping is getting old fast. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.31.0101111412320.11112-100000>