Date: Wed, 10 Jun 1998 17:35:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: me@FreeBSD.ORG Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: new config Message-ID: <199806101735.KAA29235@usr01.primenet.com> In-Reply-To: <199806101155.NAA06221@fourier.int.consol.de> from "Michael Elbel" at Jun 10, 98 01:55:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [ very interesting things deleted ] > > Hmm, how would you store static mappings with your model, like: > > I absolutely, always, want SCSI-Id 2 on controller 3 to be sd0 and keeping > my root fs, like you now specify in the config file? > > I could image something with Poul Henning's MFS-in-the-kernel approach, but > am a bit at a loss how you'd put static mappings that absolutely have to be > there before you even mount the root fs in a fully dynamic environment like > you describe. > > Or should there be a "module" devmap.o or something that always gets loaded? No. Device parameters for devices that require parameters to be set (which should be fewer and fewer of them, as time goes on) should be code associative with the drivers that act on them. In other words, you have an ELF section linked into the kernel, or you have an ELF section in a seperate autonomous ELF module. This code implements the driver. It also implements the data for the driver, including a set of standard data in a vectorable block (either by symbol, by attribute, or by magic number and checksum; whatever). An external program can edit that data. I see this as being primarily for support of ISA, and then only for drivers that are somehow broken, either because of hardware, or because they aren't smart enough. The hardware, you can't do anything about. The drivers, you can. For example, the other day, a collegue was attempting to install FreeBSD on a system with an NE2000 at a known address (the probe found it), but at an unknown interrupt. It was possible for FreeBSD to determine the interrupt, yet the driver wasn't smart enough. The determination could have occurred four ways: 1) There was a driver setup disk. It knew how to identify the card and determine the interrupt. The FreeBSD driver could have done this as well, but it simply didn't have the code for it. This would not have been a destructive probe; the chip had already been located. 2) The card was a PnP ISA card in a non-PnP motherboard. Using the PnP commands, the card could have been binary searched and identified using the PnP information. This would resolve a large number of legacy motherboard + PnP hardware issues, but it wasn't done. FreeBSD doesn't (yet) have an ISA bus driver as a seperate bus attachment. 3) The existance of the "garbage interrupt" could be worked around. On the first "ed1 tiemout", the driver *could* have attempted to reattach at another interrupt. Certainly, the interrupt could have been identified. The method would be as follows: a) Establish a default interrupt handler for all interrupts -- a *seperate* one. b) Enable all interrupts. c) When a "missing interrupt" failure occurs, note which default interrupt handler was called. d) "Allocate" one of the "free" interrupts with any "spurious" activity on it, and retry the operation. e) Repeat until the hardware works. f) Record the information in the kernel image. g) Note that this cleans up the interference of "garbage" interrupts with the LPT port on IRQ 7. 4) A user, using a configuration program (in this case, the "visual" userconfig in the kernel) could do the same thing as #3, after visually noting which hardware interrupts were not allocated by running the BIOS setup. Then, at one reboot per attempt, the card could be located. The fourth was the method used, since a setup disk was unavailable. You have to got to bad hardware that *must* be destructively probed, and whose destructive probe conflicts with *other* bad hardwares destructive probing, before you can justify a device configuration for device parameter's sake. But what about for kernel configurations sake? My personal opinion is that the device name should map precisely and *invariantly* to the controller/target/LUN. That is, that what you want to do is technically undesirable. Given the example of the root device you've given, there are several alternatives, which you probably aren't going to like. The first is that the boot blocks must have identified the correct partition. If the bootblocks can get this information, so can the kernel. At a minimum, the file /etc/fstab, as well as the file /kernel, can be read. They are both on the same filesystem. In addition, it should be possible for the kernel to use BIOS-based drivers. If it could, the boot blocks could give the same BIOS information they used to locate the root device to the kernel so that it could also locate it. Switching to protected mode drivers can be accomplished by MD5'ing enough of the disk to make a determination about the BIOS-to-protected-mode-driver mapping. This is what VFAT in Windows 95 does in order to keep the registry and TSR files open across the switchover. A fallback position is that the 0x80 bit will be set on the active partition, and that this should be only one partition per bootable disk, at most. This identifies the DOS partition sufficiently to find the booted device in most instances. For the cases where two disks are bootable using a boot manager, the boot manager should unset the 0x80 bit on all partitions except the partition being booted, so that this is unambigous. Failing this, there is my favorite fallback soloution: Seperate the "last mounted on" marking from the mounting, and don't mark in the case of by-hand mounts. What this means is that the root partition may be identified by seeing the "/" as the "last mounted on" location. You may disambiguate devices with the same "last mounted on" by their superblock timestamp. Clearly, for compile-time options that are logical mappings (rather than mappings that result from the application of logic 8-)), you will need to make modifications. One would hope that this was a *great* exception to the general rule, and that we could count on you to add #define's to code by hand to get your behaviour (3 of you, 9 million of us). I don't presume to be able to answer all the little "I'm doing something this way, how can I ignore progress and keep doing it this way" type questions. Some existing practice will, inevitably, be required to change. The best we can hope for is to keep the impacts from the changes to a minimum (ie: avoid __errno and /dev/wd0a->/dev/wds0a type changes when possible, and to cluster them to minimize the duration of the impact when not possible). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806101735.KAA29235>