Date: Sun, 10 Mar 2002 01:09:47 -0800 From: Michael Smith <msmith@freebsd.org> To: Luigi Rizzo <rizzo@icir.org> Cc: Michael Smith <msmith@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: For review: machdep.bootdev sysctl (for i386) Message-ID: <200203100909.g2A99lj02920@mass.dis.org> In-Reply-To: Your message of "Sat, 09 Mar 2002 22:43:10 PST." <20020309224310.A28779@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I am not claiming that bootdev gives the correct answer in 100% of > the cases. As you correctly notice, there is probably not a "perfect" > solution. This isn't really the issue. The issue is that one cannot tell whether it's giving you an accurate answer unless you already know what the answer is, in which case it's useless anyway. > However, _having tried_ to use it (with the sysctl patch that I > posted as a followup, which does essentially the same mapping that > is in boot/i386/boot2/boot2.c and presumably was in the ancient > i386/i386/autoconf.c), I have to disagree with you on the usefulness > of this number. It gives some reasonable information in some common > cases, e.g. when you boot off a floppy or a hard disk/CompactFlash > slice, and i think it is a big improvement over the current situation > where we can only do a blind guess having no information at all. Again, in these cases you already know what the boot device was, or you are otherwise in control of the process and don't need to be told. > I am not suggesting to use this method as a standard piece of /etc/rc, > just make this info available for those users who might have a need > for it (and know of its limitations). > As I said, if anyone has a better way to do this I'll be glad to > hear that. Since you already know the configuration, simply embed the requisite information in your configuration. > As for the cases I care about (booting PicoBSD, but that would also > apply to install disks to make another example), the root device > comes from MFS and it is obviously not the root device. ... ergo you don't need something that won't tell you what you really booted from anyway. > So, to summarise: comments received, thanks, we agree on some things, > disagree on some others (and I have shown you examples why), and > since the gist of my proposal was to export a single kernel variable > through sysctl which does not expose any security risk, I do not > believe that people should be too upset by this change. I'm extremely upset by this proposed change. It exports a bogus and unuseful datum which cannot be decoded in a meaningful fashion in anything other than a contrived situation where it is not necessary at all. The bootdev parameter is obsolete and ideally I should have diked it out several years ago. It was left there as a sop to people with old bootstraps or broken configurations. Your examples don't actually demonstrate how you plan to decode bootdev into anything meaningful in the BSD space; without this, your entire exercise is a waste of time, since you can't *do* anything with the value otherwise. > For what matters, we already export lots of stuff (such as > machdep.bootinfo, debug.boothowto, debug.sizeof.*). of questionable > usefulness (to me, but then others might have some use for this > information). The key difference here is that these and many other data are accurate and can be meaningfully decoded. The bootdev parameter is not, and cannot be, and exporting it in the general case is simply a Really Bad Idea. You're trying to hit something that isn't a nail with the sort of hammer best left to a toddler chasing the family cat. = Mike -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203100909.g2A99lj02920>