Date: Sat, 5 Dec 1998 01:07:04 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Cc: mike@smith.net.au, wilko@yedi.iaf.nl, current@FreeBSD.ORG Subject: Re: New drivers and install floppy space Message-ID: <199812050607.BAA13658@skynet.ctr.columbia.edu> In-Reply-To: <3114.912833233@zippy.cdrom.com> from "Jordan K. Hubbard" at Dec 4, 98 08:47:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Jordan K. Hubbard had to walk into mine and say: > > This would mean having an installation utility that can parse > > some kind of description file that provides information about > > the type of driver, its name, and special loading instructions. > > You mean at boot time? This should all be theoretically possible > with the forth interpreter already in there, assuming we add the > right basic words to its wordset. It's no problem parsing files or > loading modules from forth. :) > > - Jordan Well, there are two instances that I'm thinking of. Say you're trying to do a fresh install of FreeBSD on a machine which has an EtherGronk 100 card, and you intend to do an FTP installation. The problem is that the latest FreeBSD release doesn't yet come with a driver for the EtherGronk 100 card. However, somebody has written a beta driver and has source and a KLD module of it available. So you boot the FreeBSD install floppy and it probes and finds all the hardware that it knows about and brings you to the opening menu of sysinstall (or son of sysinstall, or bride of sysinstall, or Abott & Costello meet sysinstall, or whatever we have by then). One of the menu options is 'Install unlisted/3rd party drivers.' So you select this option and it prompts you to insert a floppy diskette (or maybe some other media) with the driver KLD on it and a description file. The installer reads this file, and from there it learns the name of the driver and/or the devices it supports and displays it for the user to see. The user confirms the selection, and the installer kldloads the driver, which probes the EtherGronk 100 card and attaches it as an interface. The user can now proceed to do an FTP install with the EtherGronk card without needing a new boot floppy. Once the FreeBSD install is done, the user can choose to do one of two things: he can either let the installer copy the EtherGronk 100 driver KLD module to the hard disk and fix things up so that it gets loaded when the system boots, or he can not do this and install the driver himself later. In this case, the user has a choice since he'll be able to boot the system from the local disk and reach mult-user mode without needing to have the EtherGronk driver present; this would not be the case if we were talking about a driver for a SCSI disk controller that has to be present in order for the kernel to mount the rootfs. Basically, you're looking for the ability to load a device driver that can be used _during_ the install, and the ability to install a device driver _after_ the install. For example, if the user has an existing FreeBSD system already installed and running and he purchases an EtherGronk 100 card later, he'll want to be able to load the EtherGronk driver just by su'ing to root and running the driver install utility, which will copy the KLD into place, fix things up so that it'll be loaded at bootstrap time, and then kldload it right away so that he can begin using the card without having to reboot the system (unlike a certain other OS which shall remain nameless). The actual installation process should fix things up so that the KLD module is reloaded if the system is rebooted. In the case of a network card you can get away with having this done in the boot scripts, but for something like a SCSI controller driver, I suppose you would have to preload it from the boot loader so that the kernel can use it to mount the rootfs. If this is just a matter of fixing up some forth commands in a file that the boot loader reads, then hey: that's just what the doctor ordered (although I don't know a damn thing about forth). I'm not exactly fond of this whole thing because it has far too many similarities with Solaris and AIX, but I'm willing to overlook this because the KLD system gives you the option of having either a dynamically modular kernel _or_ a single monolithic kernel image. Given the best of both worlds, I can't really complain. One of the biggest problems with this idea right now is that the PCI support code isn't set up to 'remember' devices that it's already probed, so if you force a reprobe it attempts to attach drivers for all PCI devices in the system, including those that already have drivers attached. (The other day on a whim I cooked up an LKM that called pci_configure() just to see what it would do. Boy what a mess.) There's one other thing that annoys me a bit, which is that the busdma support which was migrated over from NetBSD seems incomplete. Currently it's only used by disk controller drivers, however it's also necessary for network drivers. We appear to be missing the bus_dmamap_load_mbuf() routine though, which would vastly simplify things for network drivers. Also, there are no man pages. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812050607.BAA13658>