:> This would be trivial, you can use the swap allocation code (example:
:> see the VN device, dev/vn/vn.c) to reserve, read, and write the swap.
:> However, I don't see much of a point in doing this. Not everyone
:> configures swap, so you can't count on it, and a system dump will
:> overwrite swap, so you would have to mess around with that as well
:> and I can tell you it just isn't worth the effort. Maintaining an entropy
:> file in /var/db has no downside at all and is a whole lot easier
:> to manage.
:There is the problem that for each setup, there are many admins who
:will have a non-writable filesapce for at least one of (/ /var /boot /etc).
:Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best
:place to put stashed entropy.
/etc/rc already assumes that /var is writable. I recommend that you make
that assumption by default... have the default entropy file be something
like "/var/db/entropy_seed" and allow the administrator to override it
with an RC variable. You could allow the administrator to select a
different entropy file and you could have another RC variable which allows
the administrator to set a command which, when executed, returns an
arbitrary sequence of bytes on its stdout to initialize entropy with.
defaults (in /etc/defaults/rc.conf) (this is an example)
entropy_program="/sbin/gather_entropy -time -hostname -rootstatfs"
Another example override:
# seed with read-only entropy file and then gather additional
# entropy from other sources, like the time.
entropy_program="/sbin/gather_entropy -network -time -keyboard_if_insufficient"
This would give us maximum flexibility, yet provide suitable defaults
for most sysinstall-based configurations. For example, this gives you
the ability to write an /sbin utility to do the more complex (or more
secure) entropy gathering as part of the boot process and then allow
the administrator to specify it with appropriate options to suit his
tastes, rather then having to build it into the kernel.
Your /sbin program could deal with things like using swap instead of
an entropy file and so forth. I think if you did things this way it
would remove virtually all the pain developers are feeling from the
current state of affairs.
:> lot happier.
::-) I'd like your suggestion a lot more if you supplied some more concrete
:hints. I like KISS, and current evolution is looking a little wierd. I'd
:enjoy seeing a true/beautiful/simple solution - patches welcome. :-)
:Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message