Skip site navigation (1)Skip section navigation (2)
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>