Date: Wed, 22 Jan 1997 12:21:34 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Cc: jkh@time.cdrom.com, keithl@wakko.gil.net, chat@freebsd.org, config@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: Cursing the sky (was: Commerical applications ...) Message-ID: <199701220151.MAA11082@genesis.atrad.adelaide.edu.au> In-Reply-To: <199701211802.DAA22042@lenlen.mt.cs.keio.ac.jp> from HOSOKAWA Tatsumi at "Jan 22, 97 03:02:57 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
> <OPTIONS>DDB
> <COM>
> Enable the kernel debugger.
> </COM>
> </OPTIONS>
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701220151.MAA11082>