linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* CML2 1.0.0 release announcement
@ 2001-04-10 10:47 Eric S. Raymond
  2001-04-10 12:14 ` Russell King
                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: Eric S. Raymond @ 2001-04-10 10:47 UTC (permalink / raw)
  To: linux-kernel, kbuild-devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6963 bytes --]

After 11 months of painstaking work and testing, CML2 1.0.0 is ready for use,
and ready to replace the current kernel-configuration system.  You'll
find it at <http://www.tuxedo.org/~esr/cml2/>.  I've made a transition
guide available at <http://www.tuxedo.org/~esr/cml2/transition.html>.

(Why this project at all?  For those of you who don't remember, it all
started when I realized that building kernels is way too hard.  I
wanted to simplify the configuration task enough to make configuration
accessible to non-gurus.  It needs to have more policy options.
Rather than hundreds of questions like "Include FOOBAR2317 driver?",
the novice should see stuff like "Compile in all modular drivers as
modules without prompting?")

On 30 March 2001 at the Kernel Summit, Keith Owens and I worked out a
transition schedule with Linus.  Keith's rewrite of the makefile system and
my configurator tools are officially slated to replace the present system in
the 2.5.1 to 2.5.2 timeframe.  That, of course, is contingent on us not
screwing up :-).

(For those of you who grumbled about adding Python to the build-tools set,
Linus has uttered a ukase: CML2's reliance on Python is not an issue.  I have
promised that once CML2 is incorporated I will actually *reduce* the kernel
tree's net dependence on external tools, and I know exactly how to deliver on
that promise.)

Linus opted for a sharp cutover rather than a gradual transition -- when the
new stuff goes into the tree, CML1 will drop dead immediately.  Configuration
maintainers should be prepared!  Right now, any errors in my translation of
the CML1 rules are my problem -- but after Der Tag, they will swiftly become
*your* problem.  We'll all be happier if you have flamed my butt and helped
me fix any problems well in advance of the cutover.

The rules files in this release have been re-checked against the 2.4.3
tree.  While I can't guarantee they are completely correct (that's
your job), they at least cover every CML1 symbol.  I have written coverage
tools to check this.  There is still a problem with the  CRIS port symbols
that lack a CONFIG_ prefix, but the CRIS people say they'll fix that in their
next update.

The stock CML2 distribution contains an installation script which will drop
CML2 in place on a current kernel tree.  At most one existing file (your
top-level Makefile) will be touched, with new versions of the
config/oldconfig/menuconfig/xconfig productions edited in.  (The old ones
will be kept under variant names, so you can still invoke CML1 if you
want.)

I've learned, the hard way, that kernel developers are a conservative
bunch.  So, to help you all feel better about the change, here are
some of the improvements CML2 offers over the existing CML1
configuration system:

Maintainability:

* Where CML1 had three different interpreters, none perfectly compatible with
  any of the others, CML2 has *one* rule compiler and *one* rulebase-
  interpreter front end.  This will be good for consistency and economy.

* As of CML2 1.0.0 and CML1 2.4.3, the combined code and data size in lines
  of the system (a good indicator of its maintainability) shrank by 38%.  For
  code alone the figure was 43%.  Furthermore, where CML1 was written in a
  weird mix of three languages, CML2 uses exactly one.

* CML2 decouples the configuration language from the configuration user
  interface (they communicate with each other only through the compiled
  rulebase).  This means that it will be relatively easy to improve the
  UI and the language separately.

* CML2 has a track record.  It is already being used in other projects,
  including most notably the Embedded Debian Project.  Adam Lock at Netscape
  is using it to construct a tool for configuring Mozilla builds.

Programmer Friendliness:

* The rather spiky and cluttered shell-like syntax of CML1 is replaced
  with a much simpler and more regular format resembling that of .netrc or
  .fetchmailrc.  More importantly, the semantics of the language are
  declarative rather than imperative -- a better match for the problem
  domain, and thus more expressive and easier to code in.

* CML2 will eliminate (or at least drastically reduce) skew between port
  configurations.  The fact that the top-level CML1 files of the fifteen
  ports in the kernel tree are separate means there have been plenty of
  opportunities for the common code in them to drift apart; CML2's design
  and compilation rules should effectively prevent future bugs of this kind.

* CML2 query prompts and menu banners are separated from the symbol
  dependency declarations.  Thus CML2 system definitions can be 
  internationalized and localized.

* CML2 has a complete, explicit description.  Syntax, language semantics,
  and user-interface options are all discussed in detail.  

User Experience:

* In CML2 it is impossible to generate a configuration that is
  invalid according to the rules file(s).  You'll get a popup complaining
  about the constraint that was violated if you try.  (This is effect #1
  of having a theorem prover in the configurator.)

* Whenever CML2 can deduce from a symbol tweak that other changes are
  required, it does them.  And if the change is reversed, so are all
  those side effects. (This is effect #2 of having a theorem prover
  in the configurator.)  The user interfaces tell you what the side effects
  are.

* All three interfaces do progressive disclosure -- the user only sees
  questions he/she needs to answer (no more hundreds of greyed-out menu
  entries for irrelevant drivers!).

* The declarative semantics of CML2 makes it much easier to set up
  and check options for policy-based configuration.  I have done only 
  enough of this in the CML1 translation for demonstration purposes (there
  are new symbols TUNING, EXPERT and WIZARD that change some visibilities).
  Once CML2 is in place, it should be a relatively small effort to
  give the user a rich set of policy and don't-bother-me options.

* The line-oriented mode of the new configurator is much more powerful
  than the original Configure. It's possible to move backward or jump
  around in the configuration sequence.

* The new curses mode, unlike the old menuconfig code, has full access
  to the help texts.

* All URLs in the Tkinter version's help windows are now live; if you
  click on them they'll launch a browser.

* Curses and Tk interfaces now use color as a navigational aid -- both in the
  same way so the user interface is consistent.

* And a cool penguin logo when we iconify the X version! :-)

Many linux-kernel regulars have helped develop, test, and debug CML2,
including Giacomo Catenazzi, David Kamholz, Robert Wittams, Randy
Dunlap, Urban Widmark, André Dahlqvist, Drago Goricanec, William
Stearns, and Gary Lawrence Murphy.





-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The common argument that crime is caused by poverty is a kind of
slander on the poor.
	-- H. L. Mencken

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-10 10:47 CML2 1.0.0 release announcement Eric S. Raymond
@ 2001-04-10 12:14 ` Russell King
  2001-04-11 19:43 ` davej
  2001-04-12  7:09 ` Albert D. Cahalan
  2 siblings, 0 replies; 26+ messages in thread
From: Russell King @ 2001-04-10 12:14 UTC (permalink / raw)
  To: Eric S. Raymond; +Cc: linux-kernel, kbuild-devel

On Tue, Apr 10, 2001 at 06:47:00AM -0400, Eric S. Raymond wrote:
> On 30 March 2001 at the Kernel Summit, Keith Owens and I worked out a
> transition schedule with Linus.  Keith's rewrite of the makefile system and
> my configurator tools are officially slated to replace the present system in
> the 2.5.1 to 2.5.2 timeframe.  That, of course, is contingent on us not
> screwing up :-).

Assuming that Keiths makefiles can do everything that architecture
maintainers need it to do.

Currently, one of the many things I'm doing is trying to sort out a
working kbuild-2.5 for the ARM tree.  I have some stuff done, but there
are several things that I'm definitely not happy with, and there is
currently a whole scoop of stuff which I haven't yet found a way for
kbuild-2.5 to handle.  Its looking like the ARM trees use of kbuild-2.5
will be even more messy than its use of the current build system.

(We have around 60 machines, which key both which files get built, the
text and data address of the running kernel image, the text and data
address of the decompressor, and which vmlinux.lds.in file we use to
link the kernel.  This is currently my biggest problem that kbuild-2.5
doesn't seem to be able to handle at present.  Note that it is not
acceptable that users should have to type in 5 or so apparantly
meaningless hex addresses when they configure the kernel.)

I've yet to hear back from Keith on the issues I have with kbuild-2.5,
but I'm hopeful that he has some good suggestions...

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-10 10:47 CML2 1.0.0 release announcement Eric S. Raymond
  2001-04-10 12:14 ` Russell King
@ 2001-04-11 19:43 ` davej
  2001-04-11 20:04   ` Christoph Hellwig
  2001-04-11 22:20   ` esr
  2001-04-12  7:09 ` Albert D. Cahalan
  2 siblings, 2 replies; 26+ messages in thread
From: davej @ 2001-04-11 19:43 UTC (permalink / raw)
  To: Eric S. Raymond; +Cc: linux-kernel, kbuild-devel

On Tue, 10 Apr 2001, Eric S. Raymond wrote:

> After 11 months of painstaking work and testing, CML2 1.0.0 is ready for use,
> and ready to replace the current kernel-configuration system.  You'll
> find it at <http://www.tuxedo.org/~esr/cml2/>.  I've made a transition
> guide available at <http://www.tuxedo.org/~esr/cml2/transition.html>.

Hi Eric,

 Out of curiosity, I decided to give CML2 a try this evening.
Some feedback:

One of the first things I noticed was it seems noticably slower
than CML1. A make menuconfig in CML1 takes me into the menu
in under a second. (On an already compiled tree).
CML2 takes around 15 seconds before I get that far.
This is on an Athlon 800 w/512MB. I dread to think how this
responds on a 486.

Scrolling the cursor bar in menuconfig causes a lot of flickering
as the entire screen seems to be redrawn. This is becomes unusable
after a few minutes usage. Scrolling under CML1's menuconfig doesn't
show this behaviour.

The various colours used to show submenus that have been visited
seems confusing, and unnecessary. Their meaning also seems undocumented.

Reporting of changing certain features seems to be excessive.
For example, changing CPU target from Pentium Pro to Athlon
tells me that "M686=n (deduced from MK7)"
Another confusing thing on this menu, happens when you select
CRUSOE, and then 386.
"MK7=n (deduced from M386) MCRUSOE=n (deduced from M386)"
Not sure why selecting Crusoe enables MK7.

Top level menu seems to have gained a few items.
For example, the `SCSI support' item has disappeared,
making `SCSI disk support' and `SCSI low-level drivers'
both appear on the top level menu.

For some reason, the kernel hacking menu doesn't show
4/5 of the options that it used to. Instead it replaces
them with one new one (Disable VHPT). Which it seems to
picking up from the IA64 tree. Most strange.

Finally, quitting the program (q twice) gives me this..
python2 -O scripts/configtrans.py -h include/linux/autoconf.h -s .config
config.out
Traceback (most recent call last):
  File "scripts/configtrans.py", line 104, in ?
    sys.stderr.write(args[0]);
TypeError: read-only character buffer, int
make: *** [menuconfig] Error 1


All the above was using an 2.4.3-ac4 tree, with CML2-1.0.0

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 19:43 ` davej
@ 2001-04-11 20:04   ` Christoph Hellwig
  2001-04-11 20:16     ` Dave Jones
  2001-04-11 22:20   ` esr
  1 sibling, 1 reply; 26+ messages in thread
From: Christoph Hellwig @ 2001-04-11 20:04 UTC (permalink / raw)
  To: davej; +Cc: linux-kernel, kbuild-devel, Eric S. Raymond

In article <Pine.LNX.4.31.0104112013010.25121-100000@athlon> you wrote:
> One of the first things I noticed was it seems noticably slower
> than CML1. A make menuconfig in CML1 takes me into the menu
> in under a second. (On an already compiled tree).
> CML2 takes around 15 seconds before I get that far.
> This is on an Athlon 800 w/512MB. I dread to think how this
> responds on a 486.

If you look for something _even_ faster try mconfig.  For everyone who is
interested, I've put my latests half-way stable version is on ftp.  It's at

  ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz

Props for all the hard work go to Michael Elizabeth Chastain!

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 20:04   ` Christoph Hellwig
@ 2001-04-11 20:16     ` Dave Jones
  2001-04-11 20:27       ` Christoph Hellwig
  0 siblings, 1 reply; 26+ messages in thread
From: Dave Jones @ 2001-04-11 20:16 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel, kbuild-devel, Eric S. Raymond

On Wed, 11 Apr 2001, Christoph Hellwig wrote:

> > CML2 takes around 15 seconds before I get that far.
> > This is on an Athlon 800 w/512MB. I dread to think how this
> > responds on a 486.
>
> If you look for something _even_ faster try mconfig.  For everyone who is
> interested, I've put my latests half-way stable version is on ftp.  It's at
>   ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
> Props for all the hard work go to Michael Elizabeth Chastain!

This is the first I've heard of mconfig. (I don't track the kbuild list)
Does it solve all the problems that Eric's solution proposes?
It's certainly fast (CML1 menuconfig speed at least).

regards,

Dave.


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 20:16     ` Dave Jones
@ 2001-04-11 20:27       ` Christoph Hellwig
  2001-04-11 22:23         ` Alan Cox
  0 siblings, 1 reply; 26+ messages in thread
From: Christoph Hellwig @ 2001-04-11 20:27 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-kernel, kbuild-devel, Eric S. Raymond

On Wed, Apr 11, 2001 at 10:16:36PM +0200, Dave Jones wrote:
> On Wed, 11 Apr 2001, Christoph Hellwig wrote:
> 
> > > CML2 takes around 15 seconds before I get that far.
> > > This is on an Athlon 800 w/512MB. I dread to think how this
> > > responds on a 486.
> >
> > If you look for something _even_ faster try mconfig.  For everyone who is
> > interested, I've put my latests half-way stable version is on ftp.  It's at
> >   ftp.openlinux.org:/pub/people/hch/mconfig/mconfig-0.19-pre1.tar.gz
> > Props for all the hard work go to Michael Elizabeth Chastain!
> 
> This is the first I've heard of mconfig. (I don't track the kbuild list)
> Does it solve all the problems that Eric's solution proposes?
> It's certainly fast (CML1 menuconfig speed at least).

Not all (yet).
o It is one programm with multiple frontends:
	old,
	text,
	ncurses,
	random,
	maximum,
	minimum,
	syntax checking
	(X is still missing as my brain is not made for GUI programming)

o An 'show me all options and handle the rest' mode is still missing -
  my devel tree has something like that in the works, but I'll probably
  never finish it now that CML2 is official.

o it still has multiple top-level config.in.  Again that is easily fixable
  and in fact I did a patch for it (including {old,menu,x}config support
  in 2.3 times but never submitted it.

Something missing?

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 19:43 ` davej
  2001-04-11 20:04   ` Christoph Hellwig
@ 2001-04-11 22:20   ` esr
  1 sibling, 0 replies; 26+ messages in thread
From: esr @ 2001-04-11 22:20 UTC (permalink / raw)
  To: davej; +Cc: Eric S. Raymond, linux-kernel, kbuild-devel

davej@suse.de <davej@suse.de>:
> One of the first things I noticed was it seems noticably slower
> than CML1. A make menuconfig in CML1 takes me into the menu
> in under a second. (On an already compiled tree).
> CML2 takes around 15 seconds before I get that far.
> This is on an Athlon 800 w/512MB. I dread to think how this
> responds on a 486.

Yes, I know I have some speed-tuning to do.

> Scrolling the cursor bar in menuconfig causes a lot of flickering
> as the entire screen seems to be redrawn. This is becomes unusable
> after a few minutes usage. Scrolling under CML1's menuconfig doesn't
> show this behaviour.

That's odd.  I see no screen flicker at all when I scroll my menu bar.
I wonder what's different about your environment.  You're running under
SuSE, I presume -- perhaps you have an older ncurses version?

> The various colours used to show submenus that have been visited
> seems confusing, and unnecessary. Their meaning also seems undocumented.

I'll document them.  They're intended to help you track what portions
of the configuration you've already done.
 
> Top level menu seems to have gained a few items.
> For example, the `SCSI support' item has disappeared,
> making `SCSI disk support' and `SCSI low-level drivers'
> both appear on the top level menu.

The SCSI support flag is in the buses menu.  You see these two menus because
the defconfig sets it on.
 
> For some reason, the kernel hacking menu doesn't show
> 4/5 of the options that it used to. Instead it replaces
> them with one new one (Disable VHPT). Which it seems to
> picking up from the IA64 tree. Most strange.

Ah.  That's because I didn't have an `unless ia64 suppress DISABLE_VHPT'
I've added that.

A lot of the stuff that used to be under that menu moved to archihacks,
I think.
 
> Finally, quitting the program (q twice) gives me this..
> python2 -O scripts/configtrans.py -h include/linux/autoconf.h -s .config
> config.out
> Traceback (most recent call last):
>   File "scripts/configtrans.py", line 104, in ?
>     sys.stderr.write(args[0]);
> TypeError: read-only character buffer, int
> make: *** [menuconfig] Error 1

I can't reproduce this.  Do you get the same behavior under 1.0.3?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Such are a well regulated militia, composed of the freeholders,
citizen and husbandman, who take up arms to preserve their property,
as individuals, and their rights as freemen.
        -- "M.T. Cicero", in a newspaper letter of 1788 touching the "militia" 
            referred to in the Second Amendment to the Constitution.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 20:27       ` Christoph Hellwig
@ 2001-04-11 22:23         ` Alan Cox
  2001-04-11 23:19           ` esr
  0 siblings, 1 reply; 26+ messages in thread
From: Alan Cox @ 2001-04-11 22:23 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Dave Jones, linux-kernel, kbuild-devel, Eric S. Raymond

> o it still has multiple top-level config.in.  Again that is easily fixable
>   and in fact I did a patch for it (including {old,menu,x}config support
>   in 2.3 times but never submitted it.

Multiple layers of Config.in is a feature


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 22:23         ` Alan Cox
@ 2001-04-11 23:19           ` esr
  2001-04-11 23:30             ` Alan Cox
  2001-04-11 23:33             ` Alan Cox
  0 siblings, 2 replies; 26+ messages in thread
From: esr @ 2001-04-11 23:19 UTC (permalink / raw)
  To: Alan Cox
  Cc: Christoph Hellwig, Dave Jones, linux-kernel, kbuild-devel,
	Eric S. Raymond

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Multiple layers of Config.in is a feature

I disagree, because I've seen what happens when we go to a single-apex tree.
But you could persuade me otherwise.  What's your reason for believing this?

The problem with having multiple apices of the configuration tree (as I see
it) is that we often ended up duplicating configuration code for things that
aren't actually port-dependent but rather depend on other things such as
supported bus types (ISA, PCA, PCMCIA, etc.).  This is a particularly big
issue with network cards and disk controllers.

The duplicated code then starts to skew.  You end up with lots of features
(especially drivers) that could be supported across architectures but aren't,
simply because port maintainers are focused on their own trees and don't look
at what's going on in the others.

A multiple-apex tree also tends to pull the configuration questions downwards
from policy (e.g "Parallel-port support?") towards hardware-specific,
platform-specific questions ("Atari parallel-port hardware?")  By designing
the configuration rules for CML2 as a single-apex tree, I'm trying to
move the questions upwards and have derivations in the rules file handle
distributing that information to a lower level.

For example, instead of a bunch of parallel questions like this in a 
multiple-apex tree:

PARPORT			'Parallel port support'
PARPORT_PC		'PC-style hardware'
PARPORT_PC_PCMCIA	'Support for PCMCIA management for PC-style ports'
PARPORT_ARC		'Archimedes hardware'
PARPORT_AMIGA		'Amiga builtin port'
PARPORT_MFC3		'Multiface III parallel port'
PARPORT_ATARI		'Atari hardware'
PARPORT_SUNBPP		'Sparc hardware'

I'm trying to move us towards having *one* question and a bunch of
well-hidden intelligence about what it implies:

PARPORT			'Parallel port support'
derive PARPORT_PC from PARPORT and X86
derive PARPORT_ARC from PARPORT and ARC
derive PARPORT_AMIGA from PARPORT and AMIGA
derive PARPORT_SUNBPP from PARPORT and SUN
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Government is actually the worst failure of civilized man. There has
never been a really good one, and even those that are most tolerable
are arbitrary, cruel, grasping and unintelligent.
	-- H. L. Mencken 

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 23:19           ` esr
@ 2001-04-11 23:30             ` Alan Cox
  2001-04-11 23:33             ` Alan Cox
  1 sibling, 0 replies; 26+ messages in thread
From: Alan Cox @ 2001-04-11 23:30 UTC (permalink / raw)
  To: esr
  Cc: Alan Cox, Christoph Hellwig, Dave Jones, linux-kernel,
	kbuild-devel, Eric S. Raymond

> PARPORT			'Parallel port support'
> derive PARPORT_PC from PARPORT and X86

PARPORT_PC is found on almost all architectures btw. Its also implied by PCI
bus ISA bus and random silicon all over the place





^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 23:19           ` esr
  2001-04-11 23:30             ` Alan Cox
@ 2001-04-11 23:33             ` Alan Cox
  2001-04-12  0:45               ` esr
  1 sibling, 1 reply; 26+ messages in thread
From: Alan Cox @ 2001-04-11 23:33 UTC (permalink / raw)
  To: esr
  Cc: Alan Cox, Christoph Hellwig, Dave Jones, linux-kernel,
	kbuild-devel, Eric S. Raymond

> A multiple-apex tree also tends to pull the configuration questions downwards
> from policy (e.g "Parallel-port support?") towards hardware-specific,
> platform-specific questions ("Atari parallel-port hardware?")  By designing
> the configuration rules for CML2 as a single-apex tree, I'm trying to
> move the questions upwards and have derivations in the rules file handle
> distributing that information to a lower level.

Ok I see where you are going with that argument. However when you parse all
the existing Config.in files into a tree you can see those properties by 
looking from any node back to its dependancies


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-11 23:33             ` Alan Cox
@ 2001-04-12  0:45               ` esr
       [not found]                 ` <3AD4FC54.C86AACBE@mandrakesoft.com>
                                   ` (2 more replies)
  0 siblings, 3 replies; 26+ messages in thread
From: esr @ 2001-04-12  0:45 UTC (permalink / raw)
  To: Alan Cox
  Cc: Christoph Hellwig, Dave Jones, linux-kernel, kbuild-devel,
	Eric S. Raymond

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> Ok I see where you are going with that argument. However when you parse all
> the existing Config.in files into a tree you can see those properties by 
> looking from any node back to its dependancies

Granted.  If, that is, the representation you generate supports that kind
of backtracking.  This turns out to be very hard if you're starting from
an imperative representation rather than a declarative one.  

But, as a separate issue, the CML2 design *could* be reworked to support
a multiple-apex tree, if there were any advantage to doing so.  I don't
see one.  Do you?
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
	-- Daniel Webster

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
       [not found]                 ` <3AD4FC54.C86AACBE@mandrakesoft.com>
@ 2001-04-12  1:28                   ` esr
  0 siblings, 0 replies; 26+ messages in thread
From: esr @ 2001-04-12  1:28 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: Alan Cox, linux-kernel, kbuild-devel, Eric S. Raymond

Jeff Garzik <jgarzik@mandrakesoft.com>:
> esr@thyrsus.com wrote:
> > But, as a separate issue, the CML2 design *could* be reworked to support
> > a multiple-apex tree, if there were any advantage to doing so.  I don't
> > see one.  Do you?
> 
> Yes, because the current system is directed not by a central file, but
> by an architecture-specific config.in.  Compartmentalized Config.in
> files are easy to include and even easier to exclude selectively.  It's
> pretty pointless for S/390 arch to parse a ton of driver config entries
> it will never present to the user; that wastes memory and slows down the
> configuration system.

The low-level answer is that the configurator doesn't pay the
parse-time cost; the CML2 compiler does all that and presents the
configurator with a rulebase object that is not large enough for the
incremental I/O or memory cost of the "useless" information to be
significant.  (I'm not handwaving here, I've actually profiled this;
the rulebase object for 2.4.3 is only 342K on disk and less than that
in core.)

BTW, CML2 only has a "central file" in a rather trivial sense.  Here's
what the code to include the port-specific rules looks like:

source "arch/i386/rules.cml"
source "arch/alpha/rules.cml"
source "arch/sparc/rules.cml"
source "arch/mips/rules.cml"
source "arch/ppc/rules.cml"
source "arch/m68k/rules.cml"
source "arch/arm/rules.cml"
source "arch/sh/rules.cml"
source "arch/ia64/rules.cml"
source "arch/parisc/rules.cml"
source "arch/s390/rules.cml"
source "arch/cris/rules.cml"

The real issue isn't that they're "centralized", it's that they're 
siblings under a top-level architecture menu (which most users won't
see because normal invocations of the configurator supply that answer
from the command line, just as in CML1).  Which brings me neatly 
to my next point...

The higher-level answer is that you're confusing an implementation
issue with a design issue.  Beware of such premature optimization, for
as the hierophant Knuth hath revealed unto us, it is the root of all
evil.  To persuade me to go back to a multiple-apex tree you'd have to
show that there is a *design* or complexity-control advantage to
compartmentalizing the configuration information in that way.  Maybe
there is one, but nobody's shown it to me yet.

(In truth I don't dismiss implementation concerns quite as cavalierly
as it might sound from the above.  But buying a linear speedup wouldn't
be good enough to make me change the design.  A quadratic speedup might
be, but none of CML2's algorithms are quadratic in the number of symbols
in the rulebase.)
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The men and women who founded our country knew, by experience, that there
are times when the free person's answer to oppressive government has to be
delivered with a bullet.  Thus, the right to bear arms is not just *a*
freedom; it's the mother of all freedoms.  Don't let them disarm you!

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-12  0:45               ` esr
       [not found]                 ` <3AD4FC54.C86AACBE@mandrakesoft.com>
@ 2001-04-12  1:43                 ` jeff millar
  2001-04-12  2:50                   ` esr
  2001-04-12 10:45                 ` CML2 1.0.0 release announcement Alan Cox
  2 siblings, 1 reply; 26+ messages in thread
From: jeff millar @ 2001-04-12  1:43 UTC (permalink / raw)
  To: esr; +Cc: linux-kernel, kbuild-devel, Eric S. Raymond

I'm confused.  Downloaded cml2-1.0.0 installed ran it....appear to work but
it doesn't remember my changes.  Just now, I updated to 1.0.3 and it
reported cleaning up existing files.  Ran "make config" and it popped up
menu under X.  Then I changed the "config policy options" to "expert,
wizard, tuning" and exited with "save and exit".

Then re-opened with make config and nothing changed...expert, wizard and
tuning not set.  Maybe the program _knows_ I'm not a wizard but it should at
least let me _tune_.  (joke)

By the way "make editconfig" shows the changes made under "make config" and
allows me to make more changes..

The READ.ME says that "make config" will run configtrans to generate
.config.  But that doesn't explain why "make config"  doesn't remember
changes made to config.out.

ideas?

jeff


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-12  5:35                     ` jeff millar
@ 2001-04-12  2:06                       ` esr
  2001-04-12 21:20                         ` Ingo Oeser
  0 siblings, 1 reply; 26+ messages in thread
From: esr @ 2001-04-12  2:06 UTC (permalink / raw)
  To: jeff millar; +Cc: esr, linux-kernel, kbuild-devel

jeff millar <jeff@wa1hco.mv.com>:
> From what's in the various documentation and reading about 1% of the cml2
> traffic...  cml2's  various "make *config" invocations use config.out as a
> database for remembering configuration, and then on exit they all generate a
> fresh copy of .config.

Actually CML2's behavior is a bit more orthogonal than that.  It normally
reads nothing and writes to config.out.  You can give it -i and -I options
telling it to read in files at startup, or a -o option to issue output to
a different filename. 

Now here's where it gets a little tricky.  The config.out format is different
from a CML1 .config in that it sores FOO=n settings explicitly, rather than in
the form of "# FOO is not set" comments.  The reason for this is so we can pass
around partial configurations (a particular set of APM options, say) with 
explicit no values in them.  

Eventually (like, when Keith's Makefile stuff goes in) the CML1
.config format will go away.  In the meantime, after each configurator
run, a shim script called "configtrans.py" takes the config.out and
generates both .config and include/kernel/autoconf.h from it.

>     Apparently it's too hard to read the existing
> .config to generate an initial config.out, 

Actually it's easy.  I can feed .configs to cmlconfigure with a -i option and
they'll be read in just fine.  

>                                      so I think "make *config" the
> first time, starts with some default and then on exit _should_ write that to
> config.out.  Then any other invocationn of *make *config". needs to use
> config.out.  "make xconfig", "make config" and "make editconfig" need to
> operate the same way.  I've never use anything but "make xconfig",  "make
> menuconfig" and "make oldconfig" and they currently all operate on the same
> information.  I've never used editconfig and don't know what it's for.

Editconfig was a mistake.  OK, I think I understand the rules now.  Is it:

(1) First, try to read from .config
(2) If .config doesn't exist, read from $(ARCH)/defconfig

?

> 1.0.3 feels faster, btw.

That's because it is.  I am continuing to tune.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

You need only reflect that one of the best ways to get yourself 
a reputation as a dangerous citizen these days is to go about 
repeating the very phrases which our founding fathers used in the 
great struggle for independence.
	-- Attributed to Charles Austin Beard (1874-1948)

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-12  1:43                 ` CML2 1.0.0 doesn't remember configuration changes jeff millar
@ 2001-04-12  2:50                   ` esr
  2001-04-12  5:35                     ` jeff millar
  0 siblings, 1 reply; 26+ messages in thread
From: esr @ 2001-04-12  2:50 UTC (permalink / raw)
  To: jeff millar; +Cc: linux-kernel, kbuild-devel, Eric S. Raymond

jeff millar <jeff@wa1hco.mv.com>:
> I'm confused.  Downloaded cml2-1.0.0 installed ran it....appear to work but
> it doesn't remember my changes.  Just now, I updated to 1.0.3 and it
> reported cleaning up existing files.  Ran "make config" and it popped up
> menu under X.  Then I changed the "config policy options" to "expert,
> wizard, tuning" and exited with "save and exit".
> 
> Then re-opened with make config and nothing changed...expert, wizard and
> tuning not set.  Maybe the program _knows_ I'm not a wizard but it should at
> least let me _tune_.  (joke)
> 
> By the way "make editconfig" shows the changes made under "make config" and
> allows me to make more changes..
> 
> The READ.ME says that "make config" will run configtrans to generate
> .config.  But that doesn't explain why "make config"  doesn't remember
> changes made to config.out.
> 
> ideas?
> 
> jeff

I think it's because I misunderstood how the standard productions are supposed
to work.  If you'll tell me what files you expect them to read on startup,
and in what order, I can emulate that behavior.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
        -- Jeff Snyder

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-12  2:50                   ` esr
@ 2001-04-12  5:35                     ` jeff millar
  2001-04-12  2:06                       ` esr
  0 siblings, 1 reply; 26+ messages in thread
From: jeff millar @ 2001-04-12  5:35 UTC (permalink / raw)
  To: esr; +Cc: linux-kernel, kbuild-devel, Eric S. Raymond


----- Original Message -----
From: <esr@thyrsus.com>
To: jeff millar <jeff@wa1hco.mv.com>
Cc: <linux-kernel@vger.kernel.org>; <kbuild-devel@lists.sourceforge.net>;
Eric S. Raymond <esr@snark.thyrsus.com>
Sent: Wednesday, April 11, 2001 10:50 PM
Subject: Re: CML2 1.0.0 doesn't remember configuration changes
.................

> >
> > The READ.ME says that "make config" will run configtrans to generate
> > .config.  But that doesn't explain why "make config"  doesn't remember
> > changes made to config.out.
> >
> > ideas?
> >
> > jeff
>
> I think it's because I misunderstood how the standard productions are
supposed
> to work.  If you'll tell me what files you expect them to read on startup,
> and in what order, I can emulate that behavior.

I'm probably one of least qualified persons to answer that question.  But
maybe saying something wrong will create the usual flood of corrections.

>From what's in the various documentation and reading about 1% of the cml2
traffic...  cml2's  various "make *config" invocations use config.out as a
database for remembering configuration, and then on exit they all generate a
fresh copy of .config.  Apparently it's too hard to read the existing
.config to generate an initial config.out,  so I think "make *config" the
first time, starts with some default and then on exit _should_ write that to
config.out.  Then any other invocationn of *make *config". needs to use
config.out.  "make xconfig", "make config" and "make editconfig" need to
operate the same way.  I've never use anything but "make xconfig",  "make
menuconfig" and "make oldconfig" and they currently all operate on the same
information.  I've never used editconfig and don't know what it's for.

1.0.3 feels faster, btw.




^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-10 10:47 CML2 1.0.0 release announcement Eric S. Raymond
  2001-04-10 12:14 ` Russell King
  2001-04-11 19:43 ` davej
@ 2001-04-12  7:09 ` Albert D. Cahalan
  2001-04-12  8:57   ` Jamie Lokier
  2001-04-12 10:57   ` esr
  2 siblings, 2 replies; 26+ messages in thread
From: Albert D. Cahalan @ 2001-04-12  7:09 UTC (permalink / raw)
  To: Eric S. Raymond; +Cc: linux-kernel, kbuild-devel

> * All three interfaces do progressive disclosure -- the user only sees
>   questions he/she needs to answer (no more hundreds of greyed-out menu
>   entries for irrelevant drivers!).

Well, that sucks. The greyed-out menu entries were the only good
thing about xconfig. Such entries provide a clue that you need
to enable something else to get the feature you desire. Otherwise
you might figure that the feature is missing, or that you have
overlooked it.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-12  7:09 ` Albert D. Cahalan
@ 2001-04-12  8:57   ` Jamie Lokier
  2001-04-12 10:57   ` esr
  1 sibling, 0 replies; 26+ messages in thread
From: Jamie Lokier @ 2001-04-12  8:57 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: Eric S. Raymond, linux-kernel, kbuild-devel

Albert D. Cahalan wrote:
> > * All three interfaces do progressive disclosure -- the user only sees
> >   questions he/she needs to answer (no more hundreds of greyed-out menu
> >   entries for irrelevant drivers!).
> 
> Well, that sucks. The greyed-out menu entries were the only good
> thing about xconfig. Such entries provide a clue that you need
> to enable something else to get the feature you desire. Otherwise
> you might figure that the feature is missing, or that you have
> overlooked it.

I agree.  I use menuconfig and it's pretty good, but sometimes I miss
the ability to go through all the available options and decide, one by
one, whether I want to enable the option.

Of course if I do not enable some PCI NIC driver, I do not need to see
special options for that driver.  That's good.  On the other hand, if I
am looking to enable RED, I won't realise that I need to enable
traffic shaping first to discover the RED option.

-- Jamie

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-12  0:45               ` esr
       [not found]                 ` <3AD4FC54.C86AACBE@mandrakesoft.com>
  2001-04-12  1:43                 ` CML2 1.0.0 doesn't remember configuration changes jeff millar
@ 2001-04-12 10:45                 ` Alan Cox
  2 siblings, 0 replies; 26+ messages in thread
From: Alan Cox @ 2001-04-12 10:45 UTC (permalink / raw)
  To: esr
  Cc: Alan Cox, Christoph Hellwig, Dave Jones, linux-kernel,
	kbuild-devel, Eric S. Raymond

> But, as a separate issue, the CML2 design *could* be reworked to support
> a multiple-apex tree, if there were any advantage to doing so.  I don't
> see one.  Do you?

Enough to justify the work - no

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
  2001-04-12  7:09 ` Albert D. Cahalan
  2001-04-12  8:57   ` Jamie Lokier
@ 2001-04-12 10:57   ` esr
  1 sibling, 0 replies; 26+ messages in thread
From: esr @ 2001-04-12 10:57 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: Eric S. Raymond, linux-kernel, kbuild-devel

Albert D. Cahalan <acahalan@cs.uml.edu>:
> > * All three interfaces do progressive disclosure -- the user only sees
> >   questions he/she needs to answer (no more hundreds of greyed-out menu
> >   entries for irrelevant drivers!).
> 
> Well, that sucks. The greyed-out menu entries were the only good
> thing about xconfig. Such entries provide a clue that you need
> to enable something else to get the feature you desire. Otherwise
> you might figure that the feature is missing, or that you have
> overlooked it.

You can have this back if you want by clicking the "Unsuppress" item in
one of the pulldowns.

But since the theorem prover automatically turns on such prerequisites for
you, you're very unlikely to need it.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The kind of charity you can force out of people nourishes about as much as
the kind of love you can buy --- and spreads even nastier diseases.

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-12  2:06                       ` esr
@ 2001-04-12 21:20                         ` Ingo Oeser
  2001-04-14  2:11                           ` Eric S. Raymond
  0 siblings, 1 reply; 26+ messages in thread
From: Ingo Oeser @ 2001-04-12 21:20 UTC (permalink / raw)
  To: esr, jeff millar, linux-kernel, kbuild-devel

On Wed, Apr 11, 2001 at 10:06:46PM -0400, esr@thyrsus.com wrote:
> Editconfig was a mistake.  OK, I think I understand the rules now.  Is it:
> 
> (1) First, try to read from .config
> (2) If .config doesn't exist, read from $(ARCH)/defconfig
> 
> ?

Right. But with the following constraints:

   make oldconfig takes _any_ .config from _any_ kernel and builds a
   new one for _this_ kernel asking any remaining questions
   
   make xconfig, make menuconfig, make config take a .config from
   _this_ kernel and configure for _this_ kernel

   if they don't find and .config, then they fall back to
   $(ARCH)/defconfig


Would be nice, if CML2 works like this too, because it's not nice
to go through all the options again, if I install a new kernel or
just want to change my current kernel config add a module.

But your CML2 is sure great work.

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<     been there and had much fun   >>>>>>>>>>>>

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-12 21:20                         ` Ingo Oeser
@ 2001-04-14  2:11                           ` Eric S. Raymond
  2001-04-14  2:29                             ` Jeff Garzik
  0 siblings, 1 reply; 26+ messages in thread
From: Eric S. Raymond @ 2001-04-14  2:11 UTC (permalink / raw)
  To: Ingo Oeser; +Cc: esr, jeff millar, linux-kernel, kbuild-devel

Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>:
> On Wed, Apr 11, 2001 at 10:06:46PM -0400, esr@thyrsus.com wrote:
> > Editconfig was a mistake.  OK, I think I understand the rules now.  Is it:
> > 
> > (1) First, try to read from .config
> > (2) If .config doesn't exist, read from $(ARCH)/defconfig
> 
> Right. But with the following constraints:
> 
>    make oldconfig takes _any_ .config from _any_ kernel and builds a
>    new one for _this_ kernel asking any remaining questions
>    
>    make xconfig, make menuconfig, make config take a .config from
>    _this_ kernel and configure for _this_ kernel
> 
>    if they don't find and .config, then they fall back to
>    $(ARCH)/defconfig
> 
> Would be nice, if CML2 works like this too, because it's not nice
> to go through all the options again, if I install a new kernel or
> just want to change my current kernel config add a module.

OK, 1.1.0 will do these things.  I'm still not certain I have `make
oldconfig' right, but I trust someone will club me gently over the
head if it's still not up to spec.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
	-- Ayn Rand

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-14  2:11                           ` Eric S. Raymond
@ 2001-04-14  2:29                             ` Jeff Garzik
  2001-04-14  4:33                               ` Nicolas Pitre
  0 siblings, 1 reply; 26+ messages in thread
From: Jeff Garzik @ 2001-04-14  2:29 UTC (permalink / raw)
  To: esr; +Cc: linux-kernel, kbuild-devel

"Eric S. Raymond" wrote:
> OK, 1.1.0 will do these things.  I'm still not certain I have `make
> oldconfig' right, but I trust someone will club me gently over the
> head if it's still not up to spec.

Yep :)   'vi .config' + 'make oldconfig' is the most efficient way to
update your kernel config, if you really know what you are doing.

-- 
Jeff Garzik       | Sam: "Mind if I drive?"
Building 1024     | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft      |       and shrieking like a cheerleader."

^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 doesn't remember configuration changes
  2001-04-14  2:29                             ` Jeff Garzik
@ 2001-04-14  4:33                               ` Nicolas Pitre
  0 siblings, 0 replies; 26+ messages in thread
From: Nicolas Pitre @ 2001-04-14  4:33 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: esr, linux-kernel, kbuild-devel



On Fri, 13 Apr 2001, Jeff Garzik wrote:

> "Eric S. Raymond" wrote:
> > OK, 1.1.0 will do these things.  I'm still not certain I have `make
> > oldconfig' right, but I trust someone will club me gently over the
> > head if it's still not up to spec.
>
> Yep :)   'vi .config' + 'make oldconfig' is the most efficient way to
> update your kernel config, if you really know what you are doing.

I thought I was the only one to do that!  =-)


Nicolas


^ permalink raw reply	[flat|nested] 26+ messages in thread

* Re: CML2 1.0.0 release announcement
       [not found] ` <fa.g0offov.1jmmkh9@ifi.uio.no>
@ 2001-04-12  8:50   ` Giacomo Catenazzi
  0 siblings, 0 replies; 26+ messages in thread
From: Giacomo Catenazzi @ 2001-04-12  8:50 UTC (permalink / raw)
  To: Albert D. Cahalan; +Cc: Eric S. Raymond, linux-kernel, kbuild-devel

"Albert D. Cahalan" wrote:
> 
> > * All three interfaces do progressive disclosure -- the user only sees
> >   questions he/she needs to answer (no more hundreds of greyed-out menu
> >   entries for irrelevant drivers!).
> 
> Well, that sucks. The greyed-out menu entries were the only good
> thing about xconfig.

You are one of the few people that use xconfig... Thus xconfig
is not
so worse as people tell me.

> Such entries provide a clue that you need
> to enable something else to get the feature you desire. Otherwise
> you might figure that the feature is missing, or that you have
> overlooked it.

There is an option (check the menu) to show all entries
(grayed)
and now there is also in make menuconfig this option ('S'
command)

On my extensive test, now all the features of the older tools
are
included. But the important feature to read the old .config
file, but
this feature will be included in the next version (check the
previous
esr's mails)


	giacomo

^ permalink raw reply	[flat|nested] 26+ messages in thread

end of thread, other threads:[~2001-04-14  5:50 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-04-10 10:47 CML2 1.0.0 release announcement Eric S. Raymond
2001-04-10 12:14 ` Russell King
2001-04-11 19:43 ` davej
2001-04-11 20:04   ` Christoph Hellwig
2001-04-11 20:16     ` Dave Jones
2001-04-11 20:27       ` Christoph Hellwig
2001-04-11 22:23         ` Alan Cox
2001-04-11 23:19           ` esr
2001-04-11 23:30             ` Alan Cox
2001-04-11 23:33             ` Alan Cox
2001-04-12  0:45               ` esr
     [not found]                 ` <3AD4FC54.C86AACBE@mandrakesoft.com>
2001-04-12  1:28                   ` esr
2001-04-12  1:43                 ` CML2 1.0.0 doesn't remember configuration changes jeff millar
2001-04-12  2:50                   ` esr
2001-04-12  5:35                     ` jeff millar
2001-04-12  2:06                       ` esr
2001-04-12 21:20                         ` Ingo Oeser
2001-04-14  2:11                           ` Eric S. Raymond
2001-04-14  2:29                             ` Jeff Garzik
2001-04-14  4:33                               ` Nicolas Pitre
2001-04-12 10:45                 ` CML2 1.0.0 release announcement Alan Cox
2001-04-11 22:20   ` esr
2001-04-12  7:09 ` Albert D. Cahalan
2001-04-12  8:57   ` Jamie Lokier
2001-04-12 10:57   ` esr
     [not found] <fa.i13tmhv.9kga3t@ifi.uio.no>
     [not found] ` <fa.g0offov.1jmmkh9@ifi.uio.no>
2001-04-12  8:50   ` Giacomo Catenazzi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).