Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!amdcad!BitBlocks.com!bvs From: bvs@BitBlocks.com (Bakul Shah) Subject: Device & Kernel Configuration Message-ID: <C45Mwu.n0t@BitBlocks.com> Organization: Bit Blocks, Inc. Date: Fri, 19 Mar 1993 21:12:29 GMT Lines: 155 May I suggest a comprehensive scheme for managing device drivers and /dev entries that does not require a special type of device filesystem and is fairly simple? Ages ago, in a commercial Unix system far far away, we quite happily used a scheme that was similar to parts of the scheme I am about to describe. BTW, I have read other articles on driver interface and configuration. This article is my response to the points raised in them. The code to implement this scheme should be on the order of a couple of hundred lines in the kernel (yes, I know, famous last words!). Anyone can easily hack this up in short order but my purpose in presenting this scheme here is to ask you for your comments, criticisms & improvements. Flames are okay too; but do try to be coherent! The problem: === ======= What I want is a scheme that will allow me to 1. run the same kernel binary on a large number of 386/486 based machines that may be using a wide variety of io controllers. 2. run different kernel binaries on the same machine without having to manually change /dev/ entries. 3. change device configuration without having to mess with /dev or recompile the kernel. 4. compile in different drivers for the *same* hardware in the *same* binary 5. change the number of pseudo devices 6. change default settings 7. change things like IO addresses and such 8. continue using older drivers that do not follow this scheme At this stage I am not interested in loadable drivers. A *very brief* discussion: = ===== ====== ========== Point 1. above suggests that most common device drivers must be built-in (or have the kernel access them `somehow'). One possibility is to assume a standard minimum configuration. Additional device drivers are picked up from a configuration table. Point 1. & 2. suggest that we do not want to hardwire any sort of device name to <major,minor> mapping. This can be done by having the kernel generates the device tables upon startup. Note that if certain device drivers are to be built in every kernel and the corresponding devices are assumed be present in every machine, their <major,minor> pairs can be hardwired. Point 3. suggests some sort of configuration table and a standalone program that deals with just that table. Point 4. suggests that which device drivers are to be `activated' is *NOT* upto the drivers; that control must be outside a driver or else both drivers will fight for the same hardware. By now the trend should be clear to you. Rest of the points simply add more details to the same scheme. Sketch of the solution: ====== == === ======== All of these things point to a configuration table that the kernel reads at startup time to decide which devices to activate. The table is loaded in memory along with the kernel and, by default, from the same device. Some details of the scheme follow. 1. The boot program loads the kernel & a configuration table from the same device. The configuration table can be separate or be made part of the kernel binary (i.e. be part of the data segment). My preference is that it be a separate file. 2. A separate standalone program can be used to manipulate the configuration table. The table can be stored in a simple ascii file so that even vi or edlin can be used to edit it! 3. The table contains one entry per line. Each entry contains information about one device. Typically, this is device name, whether the device is to be activated, device type, IO and memory addresses, DMA and interrupt numbers, parent device driver if any, device specific information etc. The table is open ended so that you can add more device names at will. The same table will work with *any* kernel that follows this scheme. If in future we get loadable drivers, adding a new drivers should require nothing more than adding an entry in this table. 4. Upon startup the kernel `probe()'s built-in devices and devices that are marked active in the configuration table. It then builds a cdevsw and a bdevsw table (and initializes the device names). At some later stage the kernel can reclaim the space allocated to the config table. 5. Parent and child device drivers are connected together by the kernel (i.e. *NOT* by a device driver) but the device drivers themselves must check that only valid connections are made. The idea here is that *HOW* a device is to be used is ultimately a user decision and a device driver should not preempt that decision. 6. After the kernel is up and running, a user process queries the kernel and updates the /dev directory. This can be done either by updating changed entries in /dev in the root file system or creating /dev in a memory filesystem (MFS) and mounting it over the /dev on the root filesystem. The original /dev dir. on the root filesystem contains only the standard minmal set of devicenames. Device names used in /dev come from the kernel via a system call and kernel has picked them up from the configuration table. [Use of MFS and how to initialize /dev requires some more thought] 7. This scheme can be expanded to allow enabling/disabling of drivers during regular use. Benefits: ======== - I like this scheme because it does everything I want (:-) without introducing a lot of complexity. - Editing the config table by hand is a lot easier than messing with /sys/i386/conf/FOOBAR and /sys/i386/i386/conf.c. - If you make a mistake you just edit this table and reboot! - You can disable a buggy device driver. Makes it easy to test new drivers. - The code to parse this table is fairly straight forward (you don't need yacc for that). - If you need help in configuring or chasing some bug, you can describe the configuration fairly succintly to others who can then quickly diagnose configuration related problems. - We can even create a publicly available table of configurations to allow new users to configure their system. - The new scheme can be added without changing any of the old drivers. You may not benefit from the new scheme but atleast you don't break existing scheme while you are experimenting with it. It is also possible that we can make many of the old drivers work with the new scheme with no changes or very minor changes. - No need to change any existing programs. Beyond storing device config info. in the table I would also like to store tunable parameters in it. Bakul Shah <bvs@BitBlocks.com>