Date: Tue, 13 Apr 1999 01:56:41 +0800 From: Peter Wemm <peter@netplex.com.au> To: current@freebsd.org, committers@freebsd.org Subject: About that 'new-bus' stuff. Message-ID: <19990412175644.7DE5F1F4F@spinner.netplex.com.au>
next in thread | raw e-mail | index | archive | help
As some have become aware, we have created a small sandbox repository alongside (but seperate to) the main FreeBSD sources. I've been asked a few times for info on what it is, so here's a quick summary. First, the background.. The original 386BSD and FreeBSD configuration interface was purely static. ie: you filled in your config(8) file, ran config, compiled the kernel and you were done. It pretty much supported ISA devices only. Back then, that was quite reasonable as the devices stayed put and required a considerable amount of effort to change. But it's not 1992 anymore. That nice cozy picture has changed somewhat. Now, we've got multi-layer busses and all sorts of dynamic stuff that changes on the fly (usb, pccard, cardbus being prime examples). You end up with scsi controllers on parallel ports, parallel printer bridges on usb, etc. As well, nearly all of these devices are self identifying. PCI, PnP, EISA etc all carry identification so the configuration can be determined by asking the device directly. This does not fit well into our nice static config system any more. The average system these days has very few or perhaps even no devices that require configuration "assistance". There was also the problem of duplication of information. Drivers in the kernel were written to attach to specific busses and the exact same information had to be duplicated in the user's config file. Some alternatives (the original config.new, for example) were worse because they added another copy - various Makefiles and rule files needed another set of information to say the same thing again. (As an aside, NetBSD has done wonderful things to config.new, but it wasn't the direction we wanted to go). And then along came the Alpha port. Rather than being a descendent of the old way of doing things, it was done from a different direction as it had no isa-like bus to fight with. It's configuration system is dynamic and "hint" based. The only place that hierarchy is enforced is in the drivers themselves. You don't need to duplicate that info in makefiles or config files. But you *can* be specific about something if you want. For example, if you wanted to wire da2 to a specific LUN on a specific bus on a specific controller, you could. And then along came the in-kernel linker. The old driver mechanism on the i386 cannot cope with this without serious hackery. Various people decided to take a shot at adapting the existing new-bus stuff to the i386. Well, it works very well, but isn't quite complete. Since the people involved were having synchronization problems and having trouble with large patchsets, we decided to set up a shared repository. Since the aim was that the i386 port would use this, it was closely linked with the freebsd repository and shared the same commit messages (the plan was that the developers would need to know about it and that others who were watching could see what was going on too). Anyway, here's the basic objectives: - remove (entirely) the need for static configuration, but still have *explicit* control when and as needed. If the if_de driver only works on a pci bus, then there's no point requiring you to configure it specifically to attach to a pci bus in the kernel config file - the minimum information required is that you want it. :-) Obviously an if_ed ISA driver needs hints about where to probe, but there is no reason why it can't have a built-in set of ports to try if the user chooses not to specify one. Of course, it will use the users settings if they are given. - ultimately, static configuration would be replaced with a boot-time dynamic method. ie: you will be able to specify things like isa IO and irq settings in a config file in /boot. You won't need to recompile to adjust the kernel settings, just edit the config file and reboot. - It may well turn out that even a reboot isn't required and that the resources for isa configuration can be changed at runtime and the device re-probed with the new settings. - userconfig would logically move to a fourth script in /boot, if not then it would merely be a resource editor. - full resource management. There is a single manager for resources like ports, interrupts, memory mappings etc. This replaces the *horrible* kludges that try and figure out what's been used at present. - minimize the disruption and workload for the developers. Backwards compatability shims work quite nicely and old drivers work mostly without modifications and interface with the resource manager via the shims and new mechanisms. (we could implement UDI this way!). No bombshells blowing -current out of the water with major loss of functionality. - *full* loadable module support, for all the busses. (This won't work for linker set based drivers obviously, but with some tinkering, an isa_device style driver could be made loadable, or preloaded via loader(8) at least.) - drastically reduce the role for config(8) or some replacement. Ideally, once static configuration is loadable, it's sole role will be for managing a build of a choice of components with given compile options, both as a unified kernel and as loadable modules. (A build of the kernel should do both the kernel and the kld's at the same time so they are in sync) - the opportunity for other interface shims to be written. It might be possible to write a netbsd-style newconfig interface shim like the existing old-style isa and pci shims. This would go part of the way to being able to use their drivers with less hassles. (There will be enough fun due to differences in bus_space and bus_dma, but that's another issue) - I'm sure there's a million things I've forgotten.. Right now, the core functionality is operating nicely, but there are a few key missing bits. Specifically, wd.c doesn't (and can't) build, it needs changes like the fd.c driver. The ISA PnP and EISA code hasn't been updated to use the new interfaces. (Soren's new ata driver works). The pccard etc driver compiles but has not been updated yet. The direction the pccard stuff will go in isn't clear yet. Hopefully Doug won't shoot me for misrepresenting something. :-) Cheers, -Peter 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?19990412175644.7DE5F1F4F>