From owner-freebsd-config Tue Jan 21 17:54:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA02211 for config-outgoing; Tue, 21 Jan 1997 17:54:45 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA02205; Tue, 21 Jan 1997 17:54:39 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA11082; Wed, 22 Jan 1997 12:21:37 +1030 (CST) From: Michael Smith Message-Id: <199701220151.MAA11082@genesis.atrad.adelaide.edu.au> Subject: Re: Cursing the sky (was: Commerical applications ...) In-Reply-To: <199701211802.DAA22042@lenlen.mt.cs.keio.ac.jp> from HOSOKAWA Tatsumi at "Jan 22, 97 03:02:57 am" To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Date: Wed, 22 Jan 1997 12:21:34 +1030 (CST) Cc: jkh@time.cdrom.com, keithl@wakko.gil.net, chat@freebsd.org, config@freebsd.org, hosokawa@mt.cs.keio.ac.jp X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk HOSOKAWA Tatsumi stands accused of saying: > > I think FreeBSD's kernel config system is far better than irritating :-) > "make config" of Slackware Linux, but I think it has following > problems, and introducing the formal "metaconfig" file can solve these > problems. I agree entirely with this sentiment; a formal description of the kernel configuration (preferably split across multiple files) is highly desirable. > 1. Users have to learn some rules of config files. Yes, the syntax of > config file is fairly simple, but the semantics is too difficult. > I think if there's an interactive menu system of kernel > configuration utility more smart than Linux's menuconfig and > xconfig, it helps novices much. Agreed. > 2. Dependency and exclusiveness between options, devices, etc. are > only decribed in natural language. Kernel configuration utility > can't use these information. Formal description is needed. Goes without saying really 8) > (note that following samplese are pseudo-code, I've not implemented > the translater yet.) > > Example 1: dependency > > DDB > > Enable the kernel debugger. > > I really don't like that much. How about : # file : kern_options.kci option "DDB" { description "Enables the kernel debugger" manref "ddb(4)" } option "DDB_UNATTENDED" { description "Don't drop into DDB for a panic. Intended for" description "unattended operation where you may want to" description "invoke DDB from the console, but still want" description "the machine to recover from a panic" requires {option DDB} } option "MATH_EMULATE" { description "Support for systems with no math coprocessor" description "(standard version)" excludes {option GPL_MATH_EMULATE} header opt_math_emulate.h } option "GPL_MATH_EMULATE" { description "Support for systems with no math coprocessor" description "(Improved but GPL-licensed version)" excludes {option MATH_EMULATE} header opt_math_emulate.h } I realise that we're arguing for syntaxes friendly to our chosen implementation languages here; I just feel that the SGML-like syntax is a lot harder to work with. > 3. I want to support I18N for kernel config utility, but current > config system can't support these feature. For example, some > hackers in Japan translated comments of 2.2-BETA and 3.0-CURRENT > LINT file into Japanese, but I think such approach is not so smart. That's a real challenge. Short of a message catalog for every option file, I can't see how you could do that. > demands. The definitions of "flags" and "options" of devices > should be described in formal way. Definitely : # file sio_driver.kci driver "sio" { description "Serial driver for 8250/16x50 UARTs" file i386/isa/sio.c file i386/isa/sioreg.h file i386/isa/ic/ns16550.h file i386/isa/ic/esp.h manref "sio(4)" flag { mask 0x001 value 1 description "enable shared IRQ" } flag { mask 0x0002 value 1 description "disable FIFO" } flag { mask 0x0004 value 0 description "has AST/4 compatible IRQ control register" } flag { mask 0x0008 value 1 description "fast recovery from lost output interrupts" } flag { mask 0x0080 value 1 description "enable probe diagnostics" } flag { mask 0xff00 range {0 0xff} description "device number of master port" } vector siointr irq all port *8 iosize 8 } option "COM_ESP" { description "Enable support for Hayes ESP cards" requires {driver sio} associate {driver sio} } (the *8 value for 'port' would mean "multiple of 8") By using multiple files, adding/removing drivers becomes easier. Parsing this sort of configuration file is trivial with Tcl or in C, and I expect that Perl would make quick work of it as well. > HOSOKAWA, Tatsumi Note that this is all pandering to making the status-quo easier, rather than chasing some blue-sky future. Is it the right thing to do? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[