Newconfig: A Dynamic Configuration Framework for FreeBSD

Transcription

1 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION The following paper was originally published in the Proceedings of the FREENIX Track: 1999 USENIX Annual Technical Conference Monterey, California, USA, June 6 11, 1999 Newconfig: A Dynamic Configuration Framework for FreeBSD Atsushi Furuta Software Research Associates, Inc by The USENIX Association All Rights Reserved Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. For more about the USENIX Association: Phone: FAX: office@usenix.org WWW:

2 Newcong: a dynamic-conguration framework for FreeBSD Overview What is newcong? Motivations Atsushi Furuta Software Research Associates, Inc. <furuta@sra.co.jp> Jun-ichiro Hagino Research Laboratory, Internet Initiative Japan Inc. <itojun@itojun.org> June 9, 1999 Design Implementation Future work New-bus vs. newcong Conclusion What is newcong? Motivations PAO development Originnaly developed by Chris Torek in 4.4BSD. CardBus support (hybrid of PCM- CIA and PCI) NetBSD, OpenBSD, BSD/OS There is no IRQ abstraction. Weport this framework to FreeBSDcurrent There is no way to give conguration hint to PCI devices. (such as PCIC on PCI bus)

3 Design A target is to merge to FreeBSDcurrent ) develop based on FreeBSD-current To implement dynamic conguraition. ) add feature to handle kernel device driver tree dynamically. Support any drivers and any buses. To remove old cong 111 Old auto-conguration mechanism appeared in 4.1BSD. cong(8) is bus/machine dependent cong(8) knows bus structure Conguration hint and Plug-and-play bus To support separation bus-dependent part No need conguration hint on PnP bus. 111 if every devices keep the PnP spec. Many rotten devices (or BIOSes). foo.c foo_isa.c foo_pci.c foo driver core foo driver ISA dependent part foo driver PCI dependent part Device framework should provide "overriding" conguration hint. 111 or driver writers tend to "hard coding" Experience AMD 53C974 PCscsi controller. ) 3-days by a beginner of driver programming.

4 Our idea of auto-conguration requirements: Implementation 1. Conguration hint to device drivers cong.new(8) reads 2 group of les 2. Bus/device hierarchy 3. Inter-module dependency! generate conguration data! statically linked to kernel 4. Device name! object le name mapping Newcong handles all them, but static way. Implementation (continued) Future work 1. "les" le /usr/src/sys/conf/files.newconf Dynamic conguration for newcon- g /usr/src/sys/i386/conf/files.i386.newconf provided by programmer 2. CONFIG le /usr/src/sys/i386/conf/newconf provided by user like "GENERIC", or "LINT" When are device conguration given? Compile time (static) Boot time (a.k.a. UserCong) Run time (dynamic) The weakest point of the current implementation of newcong.

5 Future work (continued) New-bus vs. newcong Implementation of dynamic cong New-bus A utility that parse "les" le for dynamic module. 1. Conguration hint to device drivers A module loader with parsed "les" le and cong hint. Kernel codes that handles loaded cong and registers new bus/device hierarchy. 2. Bus/device hierarchy 3. Inter-module dependency 4. Device name! object le name mapping Conclusion References Static vs. dynamic: both cong required newcong To provide the way of overriding PnP presentation draft Explicit syntax of conguration data are useful