From owner-freebsd-config Sun Jan 26 02:26:19 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA01074 for config-outgoing; Sun, 26 Jan 1997 02:26:19 -0800 (PST) Received: from lenlen.mt.cs.keio.ac.jp (lenlen.mt.cs.keio.ac.jp [131.113.32.126]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA01054; Sun, 26 Jan 1997 02:26:05 -0800 (PST) Received: (from hosokawa@localhost) by lenlen.mt.cs.keio.ac.jp (8.8.4/8.8.2) id TAA12626; Sun, 26 Jan 1997 19:25:07 +0900 (JST) Date: Sun, 26 Jan 1997 19:25:07 +0900 (JST) Message-Id: <199701261025.TAA12626@lenlen.mt.cs.keio.ac.jp> To: jkh@time.cdrom.com Cc: msmith@atrad.adelaide.edu.au, keithl@wakko.gil.net, chat@freebsd.org, config@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: Cursing the sky (was: Commerical applications ...) In-Reply-To: Your message of Fri, 24 Jan 1997 02:25:30 -0800. <18310.854101530@time.cdrom.com> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <18310.854101530@time.cdrom.com> jkh@time.cdrom.com writes: >> I like it! Who's gonna write the yacc specification! :-) I'm writing it now.... -- HOSOKAWA, Tatsumi hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org From owner-freebsd-config Sun Jan 26 23:45:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA24455 for config-outgoing; Sun, 26 Jan 1997 23:45:17 -0800 (PST) Received: from lenlen.mt.cs.keio.ac.jp (mobile3.rad.cc.keio.ac.jp [131.113.11.83]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA24445 for ; Sun, 26 Jan 1997 23:45:00 -0800 (PST) Received: (from hosokawa@localhost) by lenlen.mt.cs.keio.ac.jp (8.8.4/8.8.2) id QAA15364; Mon, 27 Jan 1997 16:44:28 +0900 (JST) Date: Mon, 27 Jan 1997 16:44:28 +0900 (JST) Message-Id: <199701270744.QAA15364@lenlen.mt.cs.keio.ac.jp> To: config@freebsd.org Subject: kerenl config language (pseudo code sample) From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I wrote a basic idea of new kernel config language. yacc spec (not tested), and sample config (part of LINT) follows. Please make comments: yacc spec --------------------------------------------------------------BEGIN /* * pseudo-yacc code for FreeBSD kernel configuration language * Tatsumi Hosokawa */ config.list : config.list config | config ; config : config.group | config.select | machine | options | pseudodevice | device | controller ; config.group : 'group' string.list '{' group '}' ';' ; group : /* empty */ | description | config.list ; /* * "select" can be expressed as "exclude" options, but it forces tree * structure for dependency graph. If the dependency graph can't * be mapped onto tree structure, please use "exclude" option. */ config.select : 'select' string.list '{' select '}' ';' ; select : /* empty */ | description | config.list ; machine : 'machine' '{' machine.decl.list '}' ; machine.decl.list : machine.decl.list machine.decl | machine.decl ; machine.decl : cpu.decl | maxusers.decl | appearance | description | kernel ; cpu.decl : 'cpu' string.list cpu.option ';' ; cpu.options : /* empty */ | '{' cpu.option.list '}' ; cpu.option.list : cpu.option.list cpu.option ; cpu.option : /* empty */ | description | appearance ; maxusers.decl : 'maxusers' numeric.variable maxuser.options ';' ; maxuser.options : /* empty */ | '{' maxuser.option.list '}' ; maxuser.option.list : maxuser.option.list maxuser.option | maxuser.option ; maxuser.option : /* empty */ | description ; kernel : 'config' kernel.name kernel.options ; kernel.options : /* empty */ | '{' kernel.option.list '}' ; kernel.option.list : kernel.option.list kernel.option | kernel.option ; kernel.option : /* empty */ | root.on | dumps.on | description | appearance ; root.on : 'rooton' variable root.on.options ';' ; root.on.options : /* empty */ | '{' root.on.option.list '}' ; root.on.option.list : root.on.option.list root.on.option | root.on.option ; root.on.option : /* empty */ | description ; dumps.on : 'dumpson' variable dumps.on.options ';' ; dumps.on.options : /* empty */ | '{' dumps.on.option.list '}' ; dumps.on.option.list : dumps.on.option.list dumps.on.option | dumps.on.option ; dumps.on.option : /* empty */ | description ; options : 'options' string.list options.options ';' ; options.options | /* empty */ : '{' options.option.list '}' ; options.option.list : options.option.list options.option | options.option ; options.option : /* empty */ | description | dependency | headers | files | manref | options.value | appearance | section ; dependency : requires | excludes ; requires : 'requires' '{' conditional.list '}' ';' | 'requires' conditional ';' ; excludes : 'excludes' '{' conditional.list '}' | 'excludes' conditional ';' ; conditional.list : conditional conditional.list | conditional ; conditional : option.conditioal | pseudodevice.conditional | device.conditional | controller.conditional | machine.conditional | cpu.conditional ; option.conditional : 'option' string.list ';' ; pseudodevice.conditional : 'pseudodevice' string.list ';' ; device.conditional : 'device' string.list ';' ; controller.conditional : 'controller' string.list ';' ; machine.conditional : 'machine' string.list ';' ; cpu.conditional : 'cpu' string.list ';' ; pseudodevice : 'pseudodevice" string.list pseudodevice.options ';' ; pseudodevice.options : /* empty */ | '{' pseudodevice.option.list '}' ; pseudodevice.option.list : pseudodevice.option.list pseudodevice.option | pseudodevice.option ; pseudodevice.option : /* empty */ | pseudodevice.number | description | section ; pseudodevice.number : 'number' number ';' ; device : 'device' string.list device.options ';' ; device.options : /* empty */ | '{' device.option.list '}' ; device.option.list : device.option.list device.option | device.option ; device.option : /* empty */ | description | files | headers | manref | device.flag | device.vector | device.bus | device.iosize | device.priority | section | device.instance ; device.flag : 'flag' '{' device.flag.option.list '}' ';' ; device.flag.option.list : device.flag.option.list device.flag.option | device.flag.option ; device.flag.option : device.flag.mask | device.flag.value | description ; device.flag.mask : 'mask' number ';' ; device.flag.value : 'value' variable ';' ; device.vector : 'vector' string.list ';' ; device.bus : 'bus' string.list ';' ; device.iosize : 'iosize' number ';' ; device.priority : 'priority' device.priority.unix ';' ; device.priority.unix : 'tty' | 'bio' | 'net' ; device.instance : 'instance' '(' device.instance.arg.list ')' device.instance.values ';' ; device.instance.arg.list : device.instance.arg.list ',' device.instance.arg | device.instance.arg ; device.instance.arg : 'ioaddr' | 'irq' | 'flags' | 'disabled' ; device.instance.values : /* empty */ | '{' device.instance.value.list '}' ; device.instance.value.list : device.instance.value.list device.instance.vaule | device.instance.value ; device.instance.value : device.instance.condition device.instance.number device.instance.value.elements ; device.instance.condition : 'default' | 'in' appearance.condition ; device.instance.number : /* empty */ | number ; device.instance.value.elements : device.instance.value.element | '{' device.instance.value.element.list '}' ; device.instance.value.element.list : device.instance.value.element.list device.instance.value.element | device.instance.value.element ; device.instance.value.element : '(' device.instance.value.element.arg.list ')' ; device.instance.value.element.arg.list : device.instance.value.element.arg.list ',' device.instance.value.element.arg | device.instance.value.element.arg ; device.instance.value.element.arg : number | string.list ; description : 'description' string.list ';' ; files : 'files' string.list ';' ; headers : 'headers' string.list ';' ; manref : 'manref' string.list ';' ; options.value : 'value' variable ';' ; appearance : 'appear' appearance.condition appear.as.comment ';' ; appearance.condition : 'generic' | 'lint' /* if lint == default */ | string.list ; appear.as.comment : /* empty */ | 'comment' ; section : 'section' string.list ';' ; string.list : string.list string | string ; variable : condition.variable | '{' variable.list '}' variable.list : variable.list condition.variable | condition.variable ; condition.variable : /* empty: default = 1 */ | 'default' variable.value ';' | 'in' appearance.condition variable.value ';' ; variable.value : string.list | number | 'disappear' ; string : /* definition of ".......string........" */ ; number : /* decimal, octal, hexadecimal */ ; constant.number : /* definition of constant term (ex.: (128*1024)) */ ; yacc spec ----------------------------------------------------------------END sample config ---------------------------------------------------------BEGIN /* * sample definition file for FreeBSD kernel configuration language * Tatsumi Hosokawa */ #include #include #include #define DISABLED 1 /* i386 PC architecuture */ machine "i386" { description "This directive is mandatory; it defines the" "architecture to be configured for; in this case, the" "386 family. You must also specify at least one CPU" "(the one you intend to run on); deleting the" "specification for CPUs you don't need to use may make" "parts of the system run faster. This is especially" "true removing I386_CPU."; appear generic; /* i386 family */ cpu "I386_CPU" { appear generic; }; cpu "I486_CPU" { appear generic; }; cpu "I586_CPU" { appear generic; description "aka Pentium(tm)"; }; cpu "I686_CPU" { appear generic; description "aka Pentium Pro(tm)"; }; /* maxuser definition */ maxusers default "10" { description "The `maxusers' parameter controls the static" "sizing of a number of internal system tables" "by a complicated formula defined in param.c."; }; }; options "CHILD_MAX" { description "Under some circumstances it is convenient to increase" "the defaults for the maximum number of processes per" "user and the maximum number of open files files per" "user. E.g., (1) in a large news server, user `news'" "may need more than 100 concurrent processes. (2) a" "user may need lots of windows under X. In both cases," "it may be inconvenient to start all the processes from" "a parent whose soft rlimit on the number of processes" "is large enough. The following options work by" "changing the soft rlimits for init."; value default 128; section "PARAMS"; }; options "OPEN_MAX" { description "Under some circumstances it is convenient to increase" "the defaults for the maximum number of processes per" "user and the maximum number of open files files per" "user. E.g., (1) in a large news server, user `news'" "may need more than 100 concurrent processes. (2) a" "user may need lots of windows under X. In both cases," "it may be inconvenient to start all the processes from" "a parent whose soft rlimit on the number of processes" "is large enough. The following options work by" "changing the soft rlimits for init."; value default 128; section "PARAMS"; }; options "MAXDSIZ" { description "Certain applications can grow to be larger than the" "128M limit that FreeBSD initially imposes. Below are" "some options to allow that limit to grow to 256MB, and" "can be increased further with changing the parameters." "MAXDSIZ is the maximum that the limit can be set to," "and the DFLDSIZ is the default value for the limit." "You might want to set the default lower than the max," "and explicitly set the maximum with a shell command" "for processes that regularly exceed the limit like" "INND."; value default "(256*1024*1024)"; section "PARAMS"; }; options "DFLDSIZ" { description "Certain applications can grow to be larger than the" "128M limit that FreeBSD initially imposes. Below are" "some options to allow that limit to grow to 256MB, and" "can be increased further with changing the parameters." "MAXDSIZ is the maximum that the limit can be set to," "and the DFLDSIZ is the default value for the limit." "You might want to set the default lower than the max," "and explicitly set the maximum with a shell command" "for processes that regularly exceed the limit like" "INND."; value default "(256*1024*1024)"; section "PARAMS"; }; options "EXTRAVNODES" { description "Under some circumstances it is useful to have an extra" "number of vnode data structures allocated at boot" "time. In particular, usenet news servers can benefit" "if there are enough vnodes to cache the busiest" "newsgroup and overview directories. Beware that this" "is an expensive option, it consumes physical" "non-pageable ram. A busy news server may benefit from" "10,000 extra vnodes or so."; value default 1; section "PARAMS"; }; /* FPU emulators */ select "FPU_EMULATORS" { description "A math emulator is mandatory if you wish to run on" "hardware which does not have a floating-point" "processor. Pick either the original, bogus (but" "freely-distributable) math emulator, or a much more" "fully-featured but GPL-licensed emulator taken from Linux."; options "MATH_EMULATE" { appear generic; description "Support for x87 emulation"; #ifdef notyet headers "...."; files "...."; #endif } options "GPL_MATH_EMULATE" { appear generic comment; description "Support for x87 emulation via new math emulator"; #ifdef notyet headers "...."; files "...."; #endif }; section "FPUEMUL"; }; options "FAILSAFE" { description "When this is set, be extra conservative in various" "parts of the kernel and choose functionality over" "speed (on the widest variety of systems)."; appear generic; #ifdef notyet headers "...."; files "...."; #endif section "PARAMS"; }; config "kernel" { rooton { default "wd0"; }; dumpson { in lint "wd0"; default disappear; }; }; options "COMPAT_43" { description "Implement system calls compatible with 4.3BSD and" "older versions of FreeBSD. You probably do NOT want" "to remove this as much current code still relies on" "the 4.3 emulation."; appear generic; section "COMPAT"; }; options "USER_LDT" { description "Allow user-mode programs to manipulate their local" "descriptor tables. This option is required for the" "WINE Windows(tm) emulator, and is not used by anything" "else (that we know of)."; #ifdef notyet headers "...."; files "...."; #endif requires machine "i386"; section "I386"; }; group "MIT_SHM" { description "These three options provide support for System V" "Interface Definition-style interprocess communication," "in the form of shared memory, semaphores, and message" "queues, respectively."; options "SYSVSHM" { #ifdef notyet headers "...."; files "...."; #endif }; options "SYSVSEM" { #ifdef notyet headers "...."; files "...."; #endif }; options "SYSVMSG" { #ifdef notyet headers "...."; files "...."; #endif }; appear generic; section "COMPAT"; }; options "DDB" { description "Enable the kernel debugger."; manref "ddb(4)"; #ifdef notyet headers "...."; files "...."; #endif section "DEVEL"; }; options "DDB_UNATTENDED" { description "Don't drop into DDB for a panic. Intended for" "unattended operation where you may want to drop to DDB" "from the console, but still want the machine to" "recover from a panic "; requires options "DDB"; #ifdef notyet headers "...."; files "...."; #endif section "DEVEL"; }; options "KTRACE" { description "KTRACE enables the system-call tracing facility ktrace(2)"; manref "ktrace(2)"; #ifdef notyet headers "...."; files "...."; #endif section "DEVEL"; }; options "DIAGNOSTIC" { description "The DIAGNOSTIC option is used in a number of source" "files to enable extra sanity checking of internal" "structures. This support is not enabled by default" "because of the extra time it would take to check for" "these conditions, which can only occur as a result of" "programming errors."; section "DEVEL"; }; options "PERFMON" { description "PERFMON causes the driver for Pentium/Pentium Pro" "performance counters to be compiled. See perfmon(4)" "for more information. "; manref "perfmon(4)"; section "DEVEL"; }; options "UCONSOLE" { description "Allow ordinary users to take the console - this is" "useful for X."; section "PARAMS"; }; /* userconfig options */ options "USERCONFIG" { description "boot -c editor"; appear generic; section "CONFIG"; }; options "USERCONFIG_BOOT" { description "imply -c and parse info area"; requires options "USERCONFIG"; section "CONFIG"; }; options "VISUAL_USERCONFIG" { description "visual boot -c editor"; requires options "USERCONFIG"; appear generic; section "CONFIG"; }; /* networking options */ options "INET" { description "Internet communications protocols"; appear generic; section "NETOPT"; }; options "IPX" { description "IPX/SPX communications protocols"; section "NETOPT"; }; options "IPXIP" { description "IPX in IP encapsulation (not available)"; requires { options "INET"; options "IPX"; }; section "NETOPT"; }; options "IPTUNNEL" { description "IP in IPX encapsulation (not available)"; requires { options "INET"; options "IPX"; }; section "NETOPT"; }; options "IPXPRINTFS" { description "IPX/SPX Console Debugging Information"; requires { options "IPX"; }; value default 0; section "NETOPT"; }; options "IPXERRPRINTFS" { description "IPX/SPX Console Debugging Information"; requires { options "IPX"; }; value default 0; section "NETOPT"; }; options "NETATALK" { description "Appletalk communications protocols"; section "NETOPT"; }; group "NET_BROKEN" { description "These are currently broken but are shipped due to interest."; options "NS" { description "Xerox NS protocols"; }; section "NETOPT"; }; group "NET_BROKEN_NOINTEREST" { description "These are currently broken and are no longer shipped" "due to lack of interest."; options "CCITT" { description "X.25 network layer"; } options "ISO"; options "TPIP" { description "ISO TP class 4 over IP"; requires options "ISO"; } options "TPCONS" { description "ISO TP class 0 over X.25"; requires options "ISO"; } options "LLC" { description "X.25 link layer for Ethernets"; } options "HDLC" { description "X.25 link layer for serial lines"; } options "EON" { description "ISO CLNP over IP"; requires { options "INET"; options "ISO"; } } options "NSIP" { description "XNS over IP"; requires { options "INET"; options "NS"; } } appear lint comment; section "NETOPT"; }; /* network interfaces */ pseudodevice "ether" { description "Generic Ethernet"; appear generic; section "NETOPT"; }; pseudodevice "fddi" { description "Generic FDDI"; section "NETOPT"; }; pseudodevice "sppp" { description "Generic Synchronous PPP"; section "NETOPT"; }; pseudodevice "loop" { description "Network loopback device"; section "NETOPT"; }; pseudodevice "sl" { description "Serial Line IP"; number 2; requires options "INET"; appear generic; section "NETOPT"; }; pseudodevice "ppp" { description "Point-to-point protocol"; number 2; appear generic; section "NETOPT"; }; pseudodevice "bpfilter" { description "Berkeley packet filter"; number 4; section "NETOPT"; }; pseudodevice "disc" { description "Discard device"; section "NETOPT"; }; pseudodevice "tun" { description "Tunnel driver(user process ppp)"; number 1; appear generic; section "NETOPT"; }; /* Internet family options*/ options "TCP_COMPAT_42" { description "emulate 4.2BSD TCP bugs"; requires options "INET"; section "INETOPT"; }; options "MROUTING" { description "Multicast routing"; requires options "INET"; section "INETOPT"; }; options "IPFIREWALL" { description "firewall"; requires options "INET"; section "INETOPT"; }; options "IPFIREWALL_VERBOSE" { description "print information about dropped packets"; requires options "IPFIREWALL"; section "INETOPT"; }; options "IPFIREWALL_VERBOSE_LIMIT" { description "limit verbosity"; requires options "IPFIREWALL_VERBOSE"; value default 100; section "INETOPT"; }; options "IPDIVERT" { description "divert socket"; requires options "IPFIREWALL"; section "INETOPT"; }; device "sio" { description "Serial driver for 8250/16x50 UARTs"; #ifdef notyet files i386/isa/sio.c; headers i386/isa/sioreg.h; headers i386/isa/ic/ns16550.h; headers i386/isa/ic/esp.h; #endif manref "sio(4)"; flag { mask 0x0001; value default 0; description "enable shared IRQ"; }; flag { mask 0x0002; value default 0; description "disable FIFO"; }; flag { mask 0x0004; value default 0; description "has AST/4 compatible IRQ control register"; }; flag { mask 0x0008; value default 0; description "fast recovery from lost output interrupts"; }; flag { mask 0x0080; value default 0; description "enable probe diagnostics"; }; flag { mask 0xff00; value default 0x00; description "device number of master port"; }; vector "siointr"; bus "isa"; iosize 8; priority tty; section "SERIAL"; instance (ioaddr, irq, flags, disabled) { in generic 4 { (IO_COM1, 4), (IO_COM2, 3), (IO_COM3, 5, 0, DISABLED), (IO_COM4, 9, 0, DISABLED), }; in lint (IO_COM1, 4); }; }; options "COMCONSOLE" { description "prefer serial console to video console"; requires device "sio"; section "SERIAL"; section "CONFIG"; }; options "COM_ESP" { description "code for Hayes ESP"; requires device "sio"; section "SERIAL"; }; options "COM_MULTIPORT" { description "code for DSI Softmodems"; requires device "sio"; section "SERIAL"; }; options "BREAK_TO_DEBUGGER" { description "a BREAK on a comconsole goes to DDB, if available"; requires { device "sio"; options "COMCONSOLE"; options "DDB"; } section "SERIAL"; }; sample config -----------------------------------------------------------END -- HOSOKAWA, Tatsumi hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org From owner-freebsd-config Mon Jan 27 01:51:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA28376 for config-outgoing; Mon, 27 Jan 1997 01:51:44 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA28368 for ; Mon, 27 Jan 1997 01:51:40 -0800 (PST) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 3210 on Mon, 27 Jan 1997 10:49:22 +0100; id KAA03210 efrom: marc@nietzsche.bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by nietzsche.bowtie.nl (8.8.2/8.7.3) with ESMTP id KAA25722; Mon, 27 Jan 1997 10:52:44 +0100 (MET) Message-Id: <199701270952.KAA25722@nietzsche.bowtie.nl> X-Mailer: exmh version 1.6.7 5/3/96 To: "Sean J. Schluntz" cc: Warner Losh , config@freebsd.org Subject: Re: Commerical applications In-reply-to: schluntz's message of Wed, 22 Jan 1997 13:57:17 -0500. Date: Mon, 27 Jan 1997 10:52:43 +0100 From: Marc van Kempen Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > In message <25086.853962835@time.cdrom.com> "Jordan K. Hubbard" writes: > > : However, we still suffer from a bad case of "tools gap", where there > > : is really no reasonable framework for allowing the UI people to easily > > : practice their craft. Since we can't count on an X server being > > : present (either due to configuration hassles, non-support for a given > > : card or other hardware issues), > > > > The SVGA or VGA drivers will run on almost all hardware. Maybe not > > optimally, or at 1600x1200, but the X server can be made to run in > > that small a footprint. > > "on almost all hardware". It won't work on my Firewall or on my mailserver. > Neither have a monitor that can handle anything but text or CGA (Maybe). > I'm sorry to drop in late, but I was gone last week. Aren't we talking about offering a nice sysinstall program for the *not* so advanced users. Wouldn't it be so that people that want to install FreeBSD on machines with obscure monochrome adapters or serial consoles already know enough about installing/configuring FreeBSD that they don't care about such a config utility. They could propably do with a very much trimmed down version of the install program that would just get the system installed. Using the cli tools described earlier one could build such an installprogram rather easily (or am I being overly naief here?? (Jordan?)) or perhaps a trimmed down version of the current sysinstall with minimal functionality, which would only have to be maintaned, not developed. If the above is a reasonable assumption, we would also not have to care about the CUI interface anymore and finally get this thing going. Marc. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- From owner-freebsd-config Mon Jan 27 19:26:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA13140 for config-outgoing; Mon, 27 Jan 1997 19:26:46 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA13134; Mon, 27 Jan 1997 19:26:38 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id NAA06408; Tue, 28 Jan 1997 13:55:12 +1030 (CST) From: Michael Smith Message-Id: <199701280325.NAA06408@genesis.atrad.adelaide.edu.au> Subject: Kernel config metasyntax In-Reply-To: <18310.854101530@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 24, 97 02:25:30 am" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 28 Jan 1997 13:55:11 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, hosokawa@mt.cs.keio.ac.jp, keithl@wakko.gil.net, chat@freebsd.org, config@freebsd.org 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 Jordan K. Hubbard stands accused of saying: > > I really don't like that much. How about : > > > > # file : kern_options.kci > > > > option "DDB" { > > description "Enables the kernel debugger" > > manref "ddb(4)" > > } > > [ Other examples elided ] > > I like it! Who's gonna write the yacc specification! :-) Uhh, why do we want a yacc parser for this? What's wrong with : proc option {name attrib} { global Options; lappend Options(list) $name; foreach attrp $attrib { set aname [lindex $attrp 0]; set aval [lrange $attrp 1 end]; set Options($name:$aname) $aval; } } proc config_read {dir} { set cfiles [glob -nocomplain $dir/*.kci]; foreach f $cfiles { source $f; } } (note error/range checking elided for clarity) > Jordan -- ]] 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 [[ From owner-freebsd-config Mon Jan 27 19:40:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA14216 for config-outgoing; Mon, 27 Jan 1997 19:40:10 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id TAA14125; Mon, 27 Jan 1997 19:40:00 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vp4Oi-00037g-00; Mon, 27 Jan 1997 20:39:48 -0700 To: Michael Smith Subject: Re: Kernel config metasyntax Cc: chat@freebsd.org, config@freebsd.org In-reply-to: Your message of "Tue, 28 Jan 1997 13:55:11 +1030." <199701280325.NAA06408@genesis.atrad.adelaide.edu.au> References: <199701280325.NAA06408@genesis.atrad.adelaide.edu.au> Date: Mon, 27 Jan 1997 20:39:48 -0700 From: Warner Losh Message-Id: Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199701280325.NAA06408@genesis.atrad.adelaide.edu.au> Michael Smith writes: : What's wrong with : I don't want to write TCL to add options to the kernel :-) TCL has its time and place, but as a meta language to describe something it falls down. I've seen projects that have tried to do this go down in flames. TCL is cool, but it isn't always right tool. Warner From owner-freebsd-config Mon Jan 27 20:17:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA15889 for config-outgoing; Mon, 27 Jan 1997 20:17:11 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA15881; Mon, 27 Jan 1997 20:17:06 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id OAA06928; Tue, 28 Jan 1997 14:46:54 +1030 (CST) From: Michael Smith Message-Id: <199701280416.OAA06928@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: from Warner Losh at "Jan 27, 97 08:39:48 pm" To: imp@village.org (Warner Losh) Date: Tue, 28 Jan 1997 14:46:53 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, chat@freebsd.org, config@freebsd.org 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 Warner Losh stands accused of saying: > In message <199701280325.NAA06408@genesis.atrad.adelaide.edu.au> Michael Smith writes: > : What's wrong with : > > I don't want to write TCL to add options to the kernel :-) Argh! You don't _have_ to! Please don't muddy the waters like this. We are talking about a _metaconfiguration_ spec, for a tool which produces, as its end result, a traditional config(8) input file. You are not being asked to write the tool. To add an option, you would write an option definition in the metaconfiguration language. The example I provided _explicitly_ parses the metaconfiguration language samples that I posted earlier; it simply takes advange of the braced syntax and the Tcl parser to avoid reinventing the wheel. If you want to parse the syntax in another language, it's still easy. -- ]] 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 [[ From owner-freebsd-config Mon Jan 27 20:23:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA16173 for config-outgoing; Mon, 27 Jan 1997 20:23:24 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA16151; Mon, 27 Jan 1997 20:23:17 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id OAA07019; Tue, 28 Jan 1997 14:53:14 +1030 (CST) From: Michael Smith Message-Id: <199701280423.OAA07019@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: <199701280416.OAA06928@genesis.atrad.adelaide.edu.au> from Michael Smith at "Jan 28, 97 02:46:53 pm" To: msmith@genesis.atrad.adelaide.edu.au (Michael Smith) Date: Tue, 28 Jan 1997 14:53:14 +1030 (CST) Cc: config@freebsd.org, chat@freebsd.org 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 Michael Smith stands accused of saying: > > To add an option, you would write an option definition in the > metaconfiguration language. The example I provided _explicitly_ > parses the metaconfiguration language samples that I posted earlier; > it simply takes advange of the braced syntax and the Tcl parser to > avoid reinventing the wheel. If you want to parse the syntax in > another language, it's still easy. I haven't commented on Tatsumi's post yet (still too busy 8) but one thing that I should observe : Using a rigid syntax (eg. a Yacc syntax) is a Very Bad Idea, as it closes the definition of the language. The whole idea behind the attribute name/value pairing is that attribute-dependent functions should be triggered by the presence of the attribute, and it should be possible to add attributes to an option/whatever definition without having to tell the parser about it. (ie. if you eyeball the Tcl parser I posted, you'll notice that all it does is register the existence of the option, and pile all of the attributes supplied with it into the array. Later, anything that cares about options can access all of this and make up its own mind; the parser should not need to know or care what the attributes and their valus are.) -- ]] 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 [[ From owner-freebsd-config Mon Jan 27 20:29:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA16480 for config-outgoing; Mon, 27 Jan 1997 20:29:57 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA16460; Mon, 27 Jan 1997 20:29:52 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vp5B1-0003Cu-00; Mon, 27 Jan 1997 21:29:43 -0700 To: Michael Smith Subject: Re: Kernel config metasyntax Cc: chat@freebsd.org, config@freebsd.org In-reply-to: Your message of "Tue, 28 Jan 1997 14:46:53 +1030." <199701280416.OAA06928@genesis.atrad.adelaide.edu.au> References: <199701280416.OAA06928@genesis.atrad.adelaide.edu.au> Date: Mon, 27 Jan 1997 21:29:43 -0700 From: Warner Losh Message-Id: Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199701280416.OAA06928@genesis.atrad.adelaide.edu.au> Michael Smith writes: : Argh! You don't _have_ to! Please don't muddy the waters like this. : : We are talking about a _metaconfiguration_ spec, for a tool which : produces, as its end result, a traditional config(8) input file. Yes, but to add options to that tool, I'd have to write TCL. I suppose cut and paste isn't so bad for doing that. I don't know TCL very well, and it is hard enough to gork the config file config files right now that any more would seem a burdon. However, that said, if TCL can be made to be unobstrusive enough to hide most of the langauge and it would be a simple matter of cut and past to add most things, then I'd have no problems with that.... : it simply takes advange of the braced syntax and the Tcl parser to : avoid reinventing the wheel. Hmmm, same could be said for a lispish (option 'DDB :description "blah" :type 'boolean) (option 'DDB_PANIC_REBOOT :description "blah blah" :type 'boolean :depends-on 'DDB) which would be just a simple eval in lisp :-) However, no matter what the language, I'm all for doing things as easily as possible, and if that is TCL, then go for it. As you may guess, I've been left with a bad taste in my mouth for TCL over the years, so I tend to react negatively to it. If others thing that it is the way to go, and they are the ones writing the config tools, then my likes and dislikes really don't matter. Warner From owner-freebsd-config Mon Jan 27 20:56:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA17616 for config-outgoing; Mon, 27 Jan 1997 20:56:38 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA17604; Mon, 27 Jan 1997 20:56:26 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id PAA07513; Tue, 28 Jan 1997 15:26:17 +1030 (CST) From: Michael Smith Message-Id: <199701280456.PAA07513@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: from Warner Losh at "Jan 27, 97 09:29:43 pm" To: imp@village.org (Warner Losh) Date: Tue, 28 Jan 1997 15:26:17 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, chat@freebsd.org, config@freebsd.org 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 Warner Losh stands accused of saying: > : > : We are talking about a _metaconfiguration_ spec, for a tool which > : produces, as its end result, a traditional config(8) input file. > > Yes, but to add options to that tool, I'd have to write TCL. I > suppose cut and paste isn't so bad for doing that. I don't know TCL > very well, and it is hard enough to gork the config file config files > right now that any more would seem a burdon. In most cases, modifying the tool would not be required; the presence of the option and its attributes would provide the tool with all the information it needed to handle it intelligently. It would only be in the rare case that you had an option/driver/whatever that required abnormal treatment that Tcl-munging would be required. > However, that said, if TCL can be made to be unobstrusive enough to > hide most of the langauge and it would be a simple matter of cut and > past to add most things, then I'd have no problems with that.... That's the desired goal. > (option 'DDB :description "blah" :type 'boolean) > (option 'DDB_PANIC_REBOOT :description "blah blah" :type 'boolean > :depends-on 'DDB) > > which would be just a simple eval in lisp :-) Yup, but perhaps somewhat tougher to parse with 'normal' languages 8) > However, no matter what the language, I'm all for doing things as > easily as possible, and if that is TCL, then go for it. I've tried to make my stance on this clear; I use Tcl, and I would chose it if I were implementing this. (I may yet, depending on whether I can manage everything else 8( ) However, if someone else decides to implement in another language, that's not going to kill me. What _is_ important is that the syntax we chose is simple to parse in most languages, and it is open to simple extension without having to rewrite the parser. > As you may guess, I've been left with a bad taste in my mouth for > TCL over the years, so I tend to react negatively to it. I can appreciate this. Personally, I'd like to help you get over your aversion because I think you're missing out, and because I value your input, and having it coloured by a reflexive reaction is unhelpful. You point about the implementor's right stands however; if someone's there with code in their hands to do this stuff, I'm not going to dispute their language choice 8) > Warner -- ]] 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 [[ From owner-freebsd-config Mon Jan 27 21:04:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA18190 for config-outgoing; Mon, 27 Jan 1997 21:04:00 -0800 (PST) Received: from lenlen.mt.cs.keio.ac.jp (lenlen.mt.cs.keio.ac.jp [131.113.32.126]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA18176; Mon, 27 Jan 1997 21:03:20 -0800 (PST) Received: (from hosokawa@localhost) by lenlen.mt.cs.keio.ac.jp (8.8.4/8.8.2) id OAA16760; Tue, 28 Jan 1997 14:01:38 +0900 (JST) Date: Tue, 28 Jan 1997 14:01:38 +0900 (JST) Message-Id: <199701280501.OAA16760@lenlen.mt.cs.keio.ac.jp> To: msmith@atrad.adelaide.edu.au Cc: config@freebsd.org, chat@freebsd.org, hosokawa@mt.cs.keio.ac.jp Subject: Re: Kernel config metasyntax In-Reply-To: Your message of Tue, 28 Jan 1997 14:53:14 +1030 (CST). <199701280423.OAA07019@genesis.atrad.adelaide.edu.au> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I don't want to flame about metaconfiguration base language because the only thing I want is megtaconfiguration language :-). The reason why I used yacc (but the list I send can't be compiled because I haven't defined "controller" yet and it has a few syntax errors...), is yacc is traditional, well-defined, and of coourse most popular tool in designing languages on UNIX system. And I've wrote a programming language translator and configuration file parser in Perl, I felt that writing parser in Perl is easy, but I felt the syntax is ambiguous and I doubt that there still remains very simple errors in parser, and if I give the other files than I wrote as samples, it will crash with unknown problems. If many people says it's my fault and others do not, or it's Perl's weakness and TCL is not, and writing parser in TCL is the better way, I'll agree with writing parser in TCL of course. I personally think that writing parser in yacc is not difficult, and I wrote yesterday's example only in a few hours. I also posted this example in local hacker's mailing list and I got some advices. I'm fixing the problems and extending the syntax to incorporate requested features. -- HOSOKAWA, Tatsumi hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org From owner-freebsd-config Mon Jan 27 22:03:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id WAA21886 for config-outgoing; Mon, 27 Jan 1997 22:03:55 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA21861; Mon, 27 Jan 1997 22:03:45 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id QAA07873; Tue, 28 Jan 1997 16:31:50 +1030 (CST) From: Michael Smith Message-Id: <199701280601.QAA07873@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: <199701280501.OAA16760@lenlen.mt.cs.keio.ac.jp> from HOSOKAWA Tatsumi at "Jan 28, 97 02:01:38 pm" To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Date: Tue, 28 Jan 1997 16:31:49 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org, chat@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 don't want to flame about metaconfiguration base language because > the only thing I want is megtaconfiguration language :-). Ooh, you mean a megaconfiguration language? I agree 100% 8) > I personally think that writing parser in yacc is not difficult, and I > wrote yesterday's example only in a few hours. I also posted this > example in local hacker's mailing list and I got some advices. I'm > fixing the problems and extending the syntax to incorporate requested > features. My basic problem with using a yacc parser is that it sets not only the syntax but the content of the language in stone. The syntax I proposed basically boils down to : line : ->-(type)-(name)-[attribute-list]->- attribute-list : ->-'{'-+-[attribute]-+-'}'->- | | +-----<-------+ attribute : ->-'{'-(attribute-name)-+-(attribute-value)-+-'}'->- | | +---------<---------+ Where the parser _explicitly_ knows nothing about (type), (name), (attribute-name) or (attribute-value). I realise that in a B&D language like C, this abstraction is a little more complex to manage, but that is more an argument for a better choice of implementation language than a slur on the syntax. > HOSOKAWA, Tatsumi -- ]] 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 [[ From owner-freebsd-config Tue Jan 28 02:26:52 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA04632 for config-outgoing; Tue, 28 Jan 1997 02:26:52 -0800 (PST) Received: from narcissus.ml.org (root@brosenga.st.pitzer.edu [134.173.120.201]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA04614; Tue, 28 Jan 1997 02:26:44 -0800 (PST) Received: (from ben@localhost) by narcissus.ml.org (8.7.5/8.7.3) id CAA25927; Tue, 28 Jan 1997 02:26:41 -0800 (PST) Date: Tue, 28 Jan 1997 02:26:41 -0800 (PST) From: Snob Art Genre To: Warner Losh cc: Michael Smith , chat@freebsd.org, config@freebsd.org Subject: Re: Kernel config metasyntax In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 27 Jan 1997, Warner Losh wrote: > > However, no matter what the language, I'm all for doing things as > easily as possible, and if that is TCL, then go for it. As you may > guess, I've been left with a bad taste in my mouth for TCL over the > years, so I tend to react negatively to it. If others thing that it > is the way to go, and they are the ones writing the config tools, then > my likes and dislikes really don't matter. You people are making the flame war as genteel as afternoon tea. This has gotta stop. :) > > Warner > Ben The views expressed above are not those of the Worker's Compensation Board of Queensland, Australia. From owner-freebsd-config Tue Jan 28 02:41:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA05172 for config-outgoing; Tue, 28 Jan 1997 02:41:32 -0800 (PST) Received: from lenlen.mt.cs.keio.ac.jp (lenlen.mt.cs.keio.ac.jp [131.113.32.126]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA05147; Tue, 28 Jan 1997 02:40:04 -0800 (PST) Received: (from hosokawa@localhost) by lenlen.mt.cs.keio.ac.jp (8.8.4/8.8.2) id RAA18619; Tue, 28 Jan 1997 17:36:44 +0900 (JST) Date: Tue, 28 Jan 1997 17:36:44 +0900 (JST) Message-Id: <199701280836.RAA18619@lenlen.mt.cs.keio.ac.jp> To: msmith@atrad.adelaide.edu.au, config@freebsd.org, chat@freebsd.org Cc: hosokawa@mt.cs.keio.ac.jp Subject: Re: Kernel config metasyntax In-Reply-To: Your message of Tue, 28 Jan 1997 14:01:38 +0900 (JST). <199701280501.OAA16760@lenlen.mt.cs.keio.ac.jp> From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.19PL2] 1996-01/26(Fri) Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199701280501.OAA16760@lenlen.mt.cs.keio.ac.jp> writes: >> I personally think that writing parser in yacc is not difficult, and I >> wrote yesterday's example only in a few hours. I also posted this >> example in local hacker's mailing list and I got some advices. I'm >> fixing the problems and extending the syntax to incorporate requested >> features. FYI: requested features I want to introduce. 1. The abilty to describe "why A depends on B, or why A can't coexist with B". 2. PnP support. -- HOSOKAWA, Tatsumi hosokawa@mt.cs.keio.ac.jp hosokawa@jp.FreeBSD.org From owner-freebsd-config Tue Jan 28 05:01:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA12916 for config-outgoing; Tue, 28 Jan 1997 05:01:24 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA12893; Tue, 28 Jan 1997 05:01:16 -0800 (PST) Received: (from uucp@localhost) by perki0.connect.com.au id AAA06605 (8.7.6h/IDA-1.6); Wed, 29 Jan 1997 00:01:10 +1100 (EST) >Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id XAA15463; Tue, 28 Jan 1997 23:53:33 +1100 (EST) Message-Id: <199701281253.XAA15463@nemeton.com.au> To: Michael Smith cc: msmith@genesis.atrad.adelaide.edu.au (Michael Smith), config@freebsd.org, chat@freebsd.org Subject: Re: Kernel config metasyntax In-reply-to: <199701280423.OAA07019@genesis.atrad.adelaide.edu.au> Date: Tue, 28 Jan 1997 23:53:33 +1100 From: Giles Lean Content-Type: text Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Jan 1997 14:53:14 +1030 (CST) Michael Smith wrote: > Later, anything that cares about options can access all of this and > make up its own mind; the parser should not need to know or care > what the attributes and their valus are.) In practice with tools implemented this way there is usually little semantic checking, so typos such as incorrectly spelt attributes are not detected and the Wrong Thing happens. Tools with more integrated semantic checks (typical with yacc :) don't have this problem. If you use TCL, please validate input carefully. Giles From owner-freebsd-config Tue Jan 28 05:37:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA14308 for config-outgoing; Tue, 28 Jan 1997 05:37:53 -0800 (PST) Received: from chai.plexuscom.com (chai.plexuscom.com [207.87.46.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA14302; Tue, 28 Jan 1997 05:37:50 -0800 (PST) Received: from chai.plexuscom.com (localhost [127.0.0.1]) by chai.plexuscom.com (8.8.4/8.6.12) with ESMTP id IAA11782; Tue, 28 Jan 1997 08:38:38 -0500 (EST) Message-Id: <199701281338.IAA11782@chai.plexuscom.com> To: Warner Losh Cc: Michael Smith , chat@freebsd.org, config@freebsd.org Subject: Re: Kernel config metasyntax In-reply-to: Your message of "Mon, 27 Jan 1997 21:29:43 MST." Date: Tue, 28 Jan 1997 08:38:37 -0500 From: Bakul Shah Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (option 'DDB :description "blah" :type 'boolean) > (option 'DDB_PANIC_REBOOT :description "blah blah" :type 'boolean > :depends-on 'DDB) > which would be just a simple eval in lisp :-) (-: :-) > However, no matter what the language, I'm all for doing things as > easily as possible, and if that is TCL, then go for it. As you may > guess, I've been left with a bad taste in my mouth for TCL over the > years, so I tend to react negatively to it. If others thing that it > is the way to go, and they are the ones writing the config tools, then > my likes and dislikes really don't matter. I am with Warner on this one. Syntax of a language is the least of one's worries (except when it gets in the way). The hard part is pinning down consistent semantics. Also, languages tend to grow and its uses evolve. Someone else may have to extend it later. For all these reasons, whether one uses YACC+C or TCL or Lisp or Prolog, it would make sense to first define the semantics: - What do you want the config language to be? - What objects and relationships should it describe? (e.g. busses, IO-devices, drivers, parameters, subsystems ...) - Can the language describe the *complete* set of objects and relationships for existing configurations? - Can you come up with rules that future configurations are *likely* to fit in? For example, rather than enumerating all the possible objects of interest, can you come up with a `type' object and ways to define new types? - Do you need to embed bits of C code (e.g. for generating param.c, config.c, ioconf.c) or do you need to use some `magic' rules? - Can the language be `declarative' as opposed to `algorithmic'? The former is easier to use, the latter easier to implement. - Can you make do with a smaller language? Can an existing language be used as a starting point or base? One doesn't have to be formal/anal about this process but it helps to be aware of it. At the very least I would start with defining config objects of interest and their relationships if I were doing this. BTW, Prolog may make a pretty good fit for a configuration language (or a model for it) since it can compactly describe relationships. My 2 cents -- bakul From owner-freebsd-config Tue Jan 28 06:09:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA15479 for config-outgoing; Tue, 28 Jan 1997 06:09:14 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA15453; Tue, 28 Jan 1997 06:09:04 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vpEDU-0003ig-00; Tue, 28 Jan 1997 07:08:52 -0700 To: Snob Art Genre Subject: Re: Kernel config metasyntax Cc: Michael Smith , chat@freebsd.org, config@freebsd.org In-reply-to: Your message of "Tue, 28 Jan 1997 02:26:41 PST." References: Date: Tue, 28 Jan 1997 07:08:52 -0700 From: Warner Losh Message-Id: Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Snob Art Genre writes: : You people are making the flame war as genteel as afternoon tea. : This has gotta stop. :) Hey. Don't tell us how to have a flame war, you blarg of a narled graftnict! :-) Warner From owner-freebsd-config Tue Jan 28 06:32:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA16583 for config-outgoing; Tue, 28 Jan 1997 06:32:34 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16566; Tue, 28 Jan 1997 06:32:29 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id BAA12099; Wed, 29 Jan 1997 01:02:24 +1030 (CST) From: Michael Smith Message-Id: <199701281432.BAA12099@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: <199701281253.XAA15463@nemeton.com.au> from Giles Lean at "Jan 28, 97 11:53:33 pm" To: giles@nemeton.com.au (Giles Lean) Date: Wed, 29 Jan 1997 01:02:23 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org, chat@freebsd.org 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 Giles Lean stands accused of saying: > > > Later, anything that cares about options can access all of this and > > make up its own mind; the parser should not need to know or care > > what the attributes and their valus are.) > > In practice with tools implemented this way there is usually little > semantic checking, so typos such as incorrectly spelt attributes are > not detected and the Wrong Thing happens. Er, you don't mean semantic checking, you mean content checking, correct? As I've already observed, the parser should not know anything about the _content_ of the attributes it parses, and thus cannot possibly attempt to validate them. > Tools with more integrated semantic checks (typical with yacc :) don't > have this problem. They also have rigid and untrivially-extensible syntaxen. > If you use TCL, please validate input carefully. Insofar as is possible, sure. I don't think, however, that the sort of checking that you describe is feasible, desirable or even necessary, given that the input isn't going to be user-supplied. > Giles -- ]] 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 [[ From owner-freebsd-config Tue Jan 28 09:21:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA24975 for config-outgoing; Tue, 28 Jan 1997 09:21:39 -0800 (PST) Received: from dns.pinpt.com (dns.pinpt.com [205.179.195.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA24966 for ; Tue, 28 Jan 1997 09:21:36 -0800 (PST) Received: from journeyman (gatemaster.pinpt.com [205.179.195.65]) by dns.pinpt.com (8.6.12/8.6.12) with SMTP id JAA20180; Tue, 28 Jan 1997 09:20:43 -0800 Date: Tue, 28 Jan 97 09:16:53 Pacific Standard Time From: "Sean J. Schluntz" Subject: Re: Commerical applications To: "Sean J. Schluntz" , Marc van Kempen Cc: config@freebsd.org, Warner Losh X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199701270952.KAA25722@nietzsche.bowtie.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > : However, we still suffer from a bad case of "tools gap", where there > > > : is really no reasonable framework for allowing the UI people to easily > > > : practice their craft. Since we can't count on an X server being > > > : present (either due to configuration hassles, non-support for a given > > > : card or other hardware issues), > > > > > > The SVGA or VGA drivers will run on almost all hardware. Maybe not > > > optimally, or at 1600x1200, but the X server can be made to run in > > > that small a footprint. > > > > "on almost all hardware". It won't work on my Firewall or on my mailserver. > > Neither have a monitor that can handle anything but text or CGA (Maybe). > > > > I'm sorry to drop in late, but I was gone last week. No worries! > Aren't we talking about offering a nice sysinstall program for the > *not* so advanced users. Wouldn't it be so that people that want to > install FreeBSD on machines with obscure monochrome adapters or > serial consoles already know enough about installing/configuring > FreeBSD that they don't care about such a config utility. > They could propably do with a very much trimmed down version > of the install program that would just get the system installed. There are exceptions to everything. I was introduced to BSDLite (I think, BSD something.) v0.0 as an alternative to Minix some years ago when I took an intro course to Unix at my school (I wanted to be able to administer, and the Netcom shell account wouldn't let me ;( Not wanting to tie up my main system I threw together a 386 with some ram and a monochrome card and monitor (Because, Unix is text based right?). I think there will still be people doing that now. I have a friend who used to piece together computers for people who couldn't afford to get them, and he wanted to put a Unix on the ones that people wanted to learn on. -Sean ---------------------------------------------------------------------- Sean J. Schluntz Manager, Support Services ph. 408.997.6900 x222 PinPoint Software Corporation fx. 408.323.2300 6155 Almaden Expressway, Suite 100 San Jose, CA. 95120 http://www.pinpt.com/ Local Time Sent: 01/28/97 09:16:54 ---------------------------------------------------------------------- From owner-freebsd-config Tue Jan 28 13:07:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA10136 for config-outgoing; Tue, 28 Jan 1997 13:07:04 -0800 (PST) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10116; Tue, 28 Jan 1997 13:06:55 -0800 (PST) Received: (from Unemeton@localhost) by perki0.connect.com.au id IAA14933 (8.7.6h/IDA-1.6); Wed, 29 Jan 1997 08:06:52 +1100 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f >Received: from localhost.nemeton.com.au (localhost.nemeton.com.au [127.0.0.1]) by nemeton.com.au (8.8.5/8.8.5) with SMTP id IAA25280; Wed, 29 Jan 1997 08:00:09 +1100 (EST) Message-Id: <199701282100.IAA25280@nemeton.com.au> To: Michael Smith cc: config@freebsd.org, chat@freebsd.org Subject: Re: Kernel config metasyntax In-reply-to: <199701281432.BAA12099@genesis.atrad.adelaide.edu.au> Date: Wed, 29 Jan 1997 08:00:09 +1100 From: Giles Lean Content-Type: text Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 29 Jan 1997 01:02:23 +1030 (CST) Michael Smith wrote: > Er, you don't mean semantic checking, you mean content checking, > correct? Content checking is minimum (catch those typos) but semantic checking for inconsistent options is useful as well. > Insofar as is possible, sure. I don't think, however, that the sort > of checking that you describe is feasible, desirable or even > necessary, given that the input isn't going to be user-supplied. I don't mind you arguing 'desirable' or 'necessary' but feasible is precisely what I am concerned about. I dislike tools that don't validate their inputs, and to build one that cannot validate seems unwise. (In fact checking is feasible with a tool such as you describe, but would have to be a separate stage to parsing.) The current design of 'config' where options are passed through as C #defines is less than wonderful. I took a support call once at HP for someone who had set MAXDSIZ to be greater than 2^32. Interesting things happened but config should have caught it. :-( Giles From owner-freebsd-config Wed Jan 29 03:55:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA25833 for config-outgoing; Wed, 29 Jan 1997 03:55:32 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA25828 for ; Wed, 29 Jan 1997 03:55:29 -0800 (PST) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 29966 on Wed, 29 Jan 1997 12:03:59 +0100; id MAA29966 efrom: marc@nietzsche.bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by nietzsche.bowtie.nl (8.8.2/8.7.3) with ESMTP id MAA02713; Wed, 29 Jan 1997 12:08:34 +0100 (MET) Message-Id: <199701291108.MAA02713@nietzsche.bowtie.nl> X-Mailer: exmh version 1.6.7 5/3/96 To: "Sean J. Schluntz" Cc: config@freebsd.org, imp@village.org Subject: Re: Commerical applications In-reply-to: schluntz's message of Tue, 28 Jan 1997 09:16:53 -0500. Date: Wed, 29 Jan 1997 12:08:33 +0100 From: Marc van Kempen Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [snip] > > Aren't we talking about offering a nice sysinstall program for the > > *not* so advanced users. Wouldn't it be so that people that want to > > install FreeBSD on machines with obscure monochrome adapters or > > serial consoles already know enough about installing/configuring > > FreeBSD that they don't care about such a config utility. > > They could propably do with a very much trimmed down version > > of the install program that would just get the system installed. > > There are exceptions to everything. I was introduced to BSDLite (I think, BSD > something.) v0.0 as an alternative to Minix some years ago when I took an > intro course to Unix at my school (I wanted to be able to administer, and the > Netcom shell account wouldn't let me ;( > > Not wanting to tie up my main system I threw together a 386 with some ram and > a monochrome card and monitor (Because, Unix is text based right?). I think > there will still be people doing that now. I have a friend who used to piece > together computers for people who couldn't afford to get them, and he wanted > to put a Unix on the ones that people wanted to learn on. > I'm not trying to say that there shouldn't be an install program for people that want to use FreeBSD in text mode, just that the install program in this particular case would not have to be so sophisticated (and thus would take a lot of time to maintain and keep up to date). My assumption here is that people that want to do this will be more knowledgeable about Unix and computers than people that expect a GUI install program. If this assumption is true then we can drop the character interface program and make the install program run in a 16 color Xserver with a nice GUI interface. Perhaps a summary would be nice... What I have seen discussed in the past few weeks is the following: (correct me if I'm wrong) 1 - Use a client server model a la Romeo and Juliet. This doesn't affect the choice of userinterface but just provides a mechanism for standardized communication about configuration options. 2 - Use HTML-browsers as the client userinterface, disadvantage seems to be that there is no interactivity on a page itself, but only by sending a new page (unless one uses java(script), but this is only possible by using netscape as a client and this would require a running Xserver). Advantage of this approach is that you can also configure (administer) your FreeBSD machine from any station in your network that has a browser. 3 - Use non-existing CUI objects to do the job on the textscreens and tcl/tk for graphical screens. Option 2 can only be used if we can accept the disadvantage of direct interactivity (for the time being, I'm sure technology will catch up with us). We could even provide both, put javascript in the pages to do input checking and such, then if someone uses Netscape they will have interative pages. If they use another browser they won't notice it. Option 3 can only be used if either someone writes the CUI components that are required, or if the above mentioned assumption is true (more or less). Judging by the progress in that area I don't think that the CUI components are going to get written any time soon, so it's either: a) Use option 2 and provide interactivity with javascript as one sees fit. b) Use option 3, but drop CUI support and provide a minimal text install program that uses libdialog. Comments?? Marc. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- From owner-freebsd-config Wed Jan 29 12:04:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA18225 for config-outgoing; Wed, 29 Jan 1997 12:04:54 -0800 (PST) Received: from dns.pinpt.com (dns.pinpt.com [205.179.195.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA18218 for ; Wed, 29 Jan 1997 12:04:49 -0800 (PST) Received: from journeyman (gatemaster.pinpt.com [205.179.195.65]) by dns.pinpt.com (8.6.12/8.6.12) with SMTP id MAA27731; Wed, 29 Jan 1997 12:03:18 -0800 Date: Wed, 29 Jan 97 11:53:19 Pacific Standard Time From: "Sean J. Schluntz" Subject: Re: Commerical applications To: Marc van Kempen Cc: config@FreeBSD.ORG, imp@village.org X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199701291108.MAA02713@nietzsche.bowtie.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I'm not trying to say that there shouldn't be an install program for > people that want to use FreeBSD in text mode, just that the install > program in this particular case would not have to be so sophisticated > (and thus would take a lot of time to maintain and keep up to date). > > My assumption here is that people that want to do this will be more > knowledgeable about Unix and computers than people that expect a GUI > install program. > > If this assumption is true then we can drop the character interface > program and make the install program run in a 16 color Xserver with > a nice GUI interface. > Comments?? > > Marc. Greetings Mark, how about if I suggest something like this (This may have already been suggested and dismissed or something.) Using one of the wonderful existing languages (I don't want to start a war on this one.) you create a text and a graphical shell that would both read from one main script file to tell it what to do. You could have two main boot disks, both with the same script (for ease of maintanence) but one would have the graphic interface and one would have the text interface. This would require a little more work because you would: A: Have to create an 'Interperater Shell' to read the script in both text and graphical mode. B: You would have to have two seperate boot disks. -Sean ---------------------------------------------------------------------- Sean J. Schluntz Manager, Support Services ph. 408.997.6900 x222 PinPoint Software Corporation fx. 408.323.2300 6155 Almaden Expressway, Suite 100 San Jose, CA. 95120 http://www.pinpt.com/ Local Time Sent: 01/29/97 11:53:19 ---------------------------------------------------------------------- From owner-freebsd-config Wed Jan 29 12:26:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA19279 for config-outgoing; Wed, 29 Jan 1997 12:26:36 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA19274 for ; Wed, 29 Jan 1997 12:26:34 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id MAA00432; Wed, 29 Jan 1997 12:26:08 -0800 (PST) To: "Sean J. Schluntz" cc: Marc van Kempen , config@FreeBSD.ORG, imp@village.org Subject: Re: Commerical applications In-reply-to: Your message of "Wed, 29 Jan 1997 11:53:19 EST." Date: Wed, 29 Jan 1997 12:26:08 -0800 Message-ID: <428.854569568@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Using one of the wonderful existing languages (I don't want to start a war on > this one.) you create a text and a graphical shell that would both read from > one main script file to tell it what to do. You could have two main boot > disks, both with the same script (for ease of maintanence) but one would have Ah, and he says it with such casualness.. :-) That business of "creating a text and a graphical shell that would ..." is the work of many months, unless you've got one you've been hiding from us all this time. :-) Jordan From owner-freebsd-config Wed Jan 29 13:30:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22560 for config-outgoing; Wed, 29 Jan 1997 13:30:04 -0800 (PST) Received: from dns.pinpt.com (dns.pinpt.com [205.179.195.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA22525 for ; Wed, 29 Jan 1997 13:30:00 -0800 (PST) Received: from journeyman (gatemaster.pinpt.com [205.179.195.65]) by dns.pinpt.com (8.6.12/8.6.12) with SMTP id NAA28319; Wed, 29 Jan 1997 13:29:05 -0800 Date: Wed, 29 Jan 97 13:25:01 Pacific Standard Time From: "Sean J. Schluntz" Subject: Re: Commerical applications To: "Jordan K. Hubbard" Cc: config@freebsd.org, imp@village.org, Marc van Kempen X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <428.854569568@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Using one of the wonderful existing languages (I don't want to start a war on > > this one.) you create a text and a graphical shell that would both read from > > one main script file to tell it what to do. You could have two main boot > > disks, both with the same script (for ease of maintanence) but one would have > > Ah, and he says it with such casualness.. :-) When I was little I used to turn to my parents and say "Can you get me that teletype? It's _only_ $600." ;) > That business of "creating a text and a graphical shell that would ..." > is the work of many months, unless you've got one you've been hiding from > us all this time. :-) True, but after many months of work you would have an amazing install interfact that _could_ (if done well) blow away any other system. You could make it one of the new nifty things in 3.0-R. I don't have such a thing, don't I wish. But depenging on what language it was written in I could help with some of the it. -Sean ---------------------------------------------------------------------- Sean J. Schluntz Manager, Support Services ph. 408.997.6900 x222 PinPoint Software Corporation fx. 408.323.2300 6155 Almaden Expressway, Suite 100 San Jose, CA. 95120 http://www.pinpt.com/ Local Time Sent: 01/29/97 13:25:02 ---------------------------------------------------------------------- From owner-freebsd-config Wed Jan 29 13:32:41 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA22924 for config-outgoing; Wed, 29 Jan 1997 13:32:41 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA22907 for ; Wed, 29 Jan 1997 13:32:37 -0800 (PST) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id NAA01837; Wed, 29 Jan 1997 13:32:31 -0800 (PST) To: "Sean J. Schluntz" cc: config@freebsd.org, imp@village.org, Marc van Kempen Subject: Re: Commerical applications In-reply-to: Your message of "Wed, 29 Jan 1997 13:25:01 EST." Date: Wed, 29 Jan 1997 13:32:31 -0800 Message-ID: <1831.854573551@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > True, but after many months of work you would have an amazing install > interfact that _could_ (if done well) blow away any other system. You could > make it one of the new nifty things in 3.0-R. I can think of at least a hundred things which fit that description. Now I just need to have myself cloned a dozen or so times. :-) I think we'll probably end up going the HTML route if only because there are a lot more CGI hackers around than there are amazing-install-interface hackers. Jordan From owner-freebsd-config Wed Jan 29 17:08:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA06483 for config-outgoing; Wed, 29 Jan 1997 17:08:06 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA06405; Wed, 29 Jan 1997 17:07:58 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA23907; Thu, 30 Jan 1997 11:37:06 +1030 (CST) From: Michael Smith Message-Id: <199701300107.LAA23907@genesis.atrad.adelaide.edu.au> Subject: Re: Kernel config metasyntax In-Reply-To: <199701280836.RAA18619@lenlen.mt.cs.keio.ac.jp> from HOSOKAWA Tatsumi at "Jan 28, 97 05:36:44 pm" To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Date: Thu, 30 Jan 1997 11:37:05 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, config@freebsd.org, chat@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: > In article <199701280501.OAA16760@lenlen.mt.cs.keio.ac.jp> > writes: > > >> I personally think that writing parser in yacc is not difficult, and I > >> wrote yesterday's example only in a few hours. I also posted this > >> example in local hacker's mailing list and I got some advices. I'm > >> fixing the problems and extending the syntax to incorporate requested > >> features. > > FYI: requested features I want to introduce. > > 1. The abilty to describe "why A depends on B, or why A can't coexist > with B". That's easy, an "excludes" attribute, eg. : option "FOO" { ... excludes {option BAR} excludes {device barbar} ... } > 2. PnP support. Er.? How does PnP support figure here? > HOSOKAWA, Tatsumi -- ]] 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 [[ From owner-freebsd-config Thu Jan 30 01:22:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA00206 for config-outgoing; Thu, 30 Jan 1997 01:22:59 -0800 (PST) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA00196 for ; Thu, 30 Jan 1997 01:22:55 -0800 (PST) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 28720 on Thu, 30 Jan 1997 10:13:53 +0100; id KAA28720 efrom: marc@nietzsche.bowtie.nl; eto: UNKNOWN Received: from localhost (localhost [127.0.0.1]) by nietzsche.bowtie.nl (8.8.2/8.7.3) with ESMTP id KAA19558; Thu, 30 Jan 1997 10:19:15 +0100 (MET) Message-Id: <199701300919.KAA19558@nietzsche.bowtie.nl> X-Mailer: exmh version 1.6.7 5/3/96 To: "Jordan K. Hubbard" cc: "Sean J. Schluntz" , config@freebsd.org, imp@village.org, Marc van Kempen Subject: Re: Commerical applications In-reply-to: jkh's message of Wed, 29 Jan 1997 13:32:31 -0800. <1831.854573551@time.cdrom.com> Date: Thu, 30 Jan 1997 10:19:15 +0100 From: Marc van Kempen Sender: owner-freebsd-config@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > True, but after many months of work you would have an amazing install > > interfact that _could_ (if done well) blow away any other system. You could > > make it one of the new nifty things in 3.0-R. > > I can think of at least a hundred things which fit that description. > Now I just need to have myself cloned a dozen or so times. :-) > > I think we'll probably end up going the HTML route if only because > there are a lot more CGI hackers around than there are > amazing-install-interface hackers. > Could we please take a vote (or whatever it takes) to decide which route to take. If it's going to be HTML let's announce it so that we can focus this discussion and (finally, I've been following these discussions too for the last year and a half), get something done, or at least have a direction in which to go (I feel lost :). Marc. PS no snipe intended to anyone at all! ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ----------------------------------------------------