Mailing List Archive

On Wed, May 24, 2000 at 09:25:18PM -0600, Neil Schemenauer wrote:
> On Wed, May 24, 2000 at 09:27:57PM -0500, Peter Samuelson wrote:
> > It bloats Linus's tarballs, bloats Linus's patches, and (depending on
> > whether Linus wants to take responsibility for generating the freeze
> > files) could bloat people's patches to Linus.
>
> Especially since freeze requires the entire source for the Python
> interpreter (unless freeze has been significantly since I last
> looked at it).
This is a critical point. How big is this stuff frozen?
Austin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Larry McVoy <lm@bitmover.com>:
> I'd just like to welcome Eric back to programming. I personally think that
> you lead by example, and what better way to lead a bunch of programmers than
> by programming? Welcome back, Eric, it's good to see you doing what you do
> so well.
The truth is that I never stopped coding. But I guess this list can't
be expected to be au courant on SNG or pnglib or the other stuff I've
been up to in the last year.
I wrote a lot of CML2 on my VAIO in hotel rooms and on plane flights.
Coding is how I stay sane amidst the suits and journalists.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
You know why there's a Second Amendment? In case the government fails to
follow the first one.
-- Rush Limbaugh, in a moment of unaccustomed profundity 17 Aug 1993
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Eric S. Raymond wrote:
> I'm willing to make this effort. How do I go from a symbol to identifying
> the relevant maintainer?
Maybe we should start maintaining a file that has this relationship?
CONFIG_SPECIALIX R.E.Wolff@BitWizard.nl
CONFIG_SX R.E.Wolff@BitWizard.nl
CONFIG_RIO R.E.Wolff@BitWizard.nl
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Rogier Wolff wrote:
> Eric S. Raymond wrote:
> > I'm willing to make this effort. How do I go from a symbol to identifying
> > the relevant maintainer?
Unfortunately right now you must manually make the association, by first
looking at MAINTAINERS, then looking the source itself, for a relevant
e-mail address. If all else fails, search lkml archives for likely
suspects :)
> Maybe we should start maintaining a file that has this relationship?
>
> CONFIG_SPECIALIX R.E.Wolff@BitWizard.nl
> CONFIG_SX R.E.Wolff@BitWizard.nl
> CONFIG_RIO R.E.Wolff@BitWizard.nl
It could go in Configure.help if nowhere else...
Jeff
--
Jeff Garzik | Liberty is always dangerous, but
Building 1024 | it is the safest thing we have.
MandrakeSoft, Inc. | -- Harry Emerson Fosdick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 24 May 2000, Eric S. Raymond wrote:
> Alexander Viro <viro@math.psu.edu>:
> > Not only. Dependency on Python is definitely a problem - not everyone uses
> > 'everything and a kitchen sink' type of userland.
>
> I'm aware of the problem :-). Python programs can be compiled to
> portable C sources using the `freeze' tool. The translation is
> inelegant (it embeds a Python byte-code interpreter in the generated
> C) but it works. So a working CML2 configurator can be shipped for an
> environment without Python.
>
> Even if this weren't true, we'd be trading dependencies and not adding
> one. The Perl stuff in the scripts directory will go away shortly
> (that is, assuming that Linus approves the CML1->CML2 change). This
> would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
perlcc?
Personally, I've got both perl and python on my machine. On the other
hand, there are machines out there without tools like "make" and "cc" - do
you want to support them, as well - bundle a copy of GCC etc. with the
kernel?
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

James Sutherland <jas88@cam.ac.uk>:
> > Even if this weren't true, we'd be trading dependencies and not adding
> > one. The Perl stuff in the scripts directory will go away shortly
> > (that is, assuming that Linus approves the CML1->CML2 change). This
> > would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
>
> perlcc?
Is, I'm told, a kluge much like the freeze tool. You can compile away
control structure but you end up carrying around most of Perl as
runtime support.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Strict gun laws are about as effective as strict drug laws...It pains
me to say this, but the NRA seems to be right: The cities and states
that have the toughest gun laws have the most murder and mayhem.
-- Mike Royko, Chicago Tribune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 25 May 2000, Eric S. Raymond wrote:
> James Sutherland <jas88@cam.ac.uk>:
> > > Even if this weren't true, we'd be trading dependencies and not adding
> > > one. The Perl stuff in the scripts directory will go away shortly
> > > (that is, assuming that Linus approves the CML1->CML2 change). This
> > > would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
> >
> > perlcc?
>
> Is, I'm told, a kluge much like the freeze tool. You can compile away
> control structure but you end up carrying around most of Perl as
> runtime support.
Personally, I wouldn't recommend using either. Just adding Python to the
list of requirements for configuration seems fair, IMHO; while the kernel
is USED on heavily cut-down systems, it doesn't need to be buildable on
them.
I don't want to see another holy war starting - the "GPL for libraries"
debate was quite enough for one lifetime - but I don't like the idea of
"getting rid of" the Perl scripts. If it works, use it, if not, fix it or
report it as a bug. Perl, python, make, gcc etc. are all common enough
(and free enough!) to have as requirements, I think.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, May 24, 2000 at 06:05:18PM -0500, Ed Carp wrote:
> Alexander Viro (viro@math.psu.edu) writes:
>
> > Al, -><- close to getting PO'd enough to actually implement One
> > True Editor as ldisc - insmod vi.o and there we go...
>
<Political correctness>
> I think we ought to be celebrating the fact that we *have* more than one editor
> to choose from, instead of fighting over which is the One True Editor, an
> argument which is foolish on its face. My office mate uses Emacs, he loves
> it, and more power to him. I use vi. I'm just glad that I'm not forced to
> use Emacs, and he's not forced to use vi, and that's what this whole thing
> is all about, isn't it?
</Political correctness>
Everyone should simply be forced to use the One Editor until they like
it. Electric shock/aversion therapy could easily be used to ensure
the correct salivation or revulsion response depending on what editor
is running.
Afterall its not enough to just use the One Editor ourselves.
Everyone else should use it too, and they should be forced to enjoy
it.
Sean
P.S. I use both editors
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 24 May 2000, Peter Samuelson wrote:
>
> [Ed Carp <erc@pobox.com>]
> > That's *stupid*. What about all those cool
> > linux-router-in-a-box-boot-off-a-folppy sort of distributions? They
> > sure can't use Debian...
>
> Sure, they just have to recompile packages. Debian was never meant to
> be one-size-fits-all, and recompiling isn't all that hard.
>
> I actually ran into this problem once. I had an old Debian install on
> a laptop and it was nowhere near an Internet connection or a Debian CD,
> and the install was somewhat broken, and xlib was nowhere to be found,
> and I wanted to run Emacs. I ended up compiling a lib full of stubs
> and relying on Emacs not to try calling them. It worked.
>
> This approach could be taken by the router-on-a-floppy types. Debian
> already has a "svgalib-dummy" package similar to what I did above, so
> that you can run svgalib-capable packages like ghostscript without
> needing svgalib. I've often wondered what has prevented any Debian
> developers for doing the same with xlib.
Of course, virtually everything you need is either
a.) Non-xlib dependent (in fact, the only package that did depend on
xlib on my PS/2 56slc2 was mtools... NO, don't ask me why. It's a
long story based on idiocy.)
b.) Exists in a non-xlib version (that is, VIM, for instance.)
I ran Debian a looooooong time before installing xlib; in fact, the only
reason I installed it was because of mtools. And mtools could easily
be repackaged not to require xlib by removing one, non-core, program
from the package.
/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Sean Hunter wrote:
> Everyone should simply be forced to use the One Editor until they like
> it. Electric shock/aversion therapy could easily be used to ensure
> the correct salivation or revulsion response depending on what editor
> is running.
"Ed is the standard editor."
(I'm an "ex" troglodyte myself, but I could live with "ed" if I had to.)
--
Schlingt dreifach einen Kreis um dies! || John Cowan <jcowan@reutershealth.com>
Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com
Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

"Eric S. Raymond" <esr@thyrsus.com>:
> Alexander Viro <viro@math.psu.edu>:
> > > Even if this weren't true, we'd be trading dependencies and not adding
> > > one. The Perl stuff in the scripts directory will go away shortly
> > > (that is, assuming that Linus approves the CML1->CML2 change). This
> > > would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
> >
> > Yeah, but you don't have to use these Perl scripts to configure and build
> > a fresh tree - they are debugging/sanity checking tools. Heck, there is
> > some Tk stuff in the tree - it doesn't mean an absolute dependency on the
> > bloody mess...
>
> Still, the Python stuff can be frozen to straight C, eliminating the
> dependency. I'll test and supply the machinery for this as soon as I
> see an actual (as opposed to theoretical, it-would-be-nice-if)
> requirement. In the meantime, I have a Tk front end to write.
>
> (Ideally, I'd like to turf both Perl and Tk out of the kernel tree
> entirely. They're kludges, and they promote kludging. Python plus
> a GTK++ binding could make Tk unnecessary. Would GTK++ be a greater
> or lesser requirement than Tk?)
Equivalent. As long as the new configuration tool can itself be configured
to omit X and dependancies on X during the build, I don't see a problem.
Right now, I have a firewall/router/.... (multiple functions for the time
being) that I configure via SSH. Right now, the X libraries (none of them)
are available. X is not available. I may add libX, and libXaw so that I
can run an xterm over SSH. There won't be any development libraries beyond
the minimum for a kernel compile.
I could compile the kernel on my PPro, but that then assumes enough
separation from the PPro development and kernel distribution that the
resulting kernel is valid for the 486, and doesn't disturb the PPro. It
also means that I have to complete the kernel install (and modules) separately
when I take the distribution back to the 486. (I know, I know - the 486 system
could be build using a chroot environment... but what a pain.)
I just find it simpler to keep the 486 kernel configure/build on the 486; and
the PPro on the PPro.
As long as it will still work with a minimum development environment (no
TCL, TK, perl, or X). I still have to think whether I put lex/yacc on the 486,
I just don't remember...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Thus spake Eric Raymond (esr@snark.thyrsus.com):
> The 7049 lines of CML1 in the 2.3.99-pre9 kernel translate to a hair
> less than 2400 lines of CML2, a reduction by a factor of about three.
> The CML2 compiler and prototype interpreter are the same factor of
> three smaller than the nearly 10,000 lines of code in the CML1
> interpreters and tools. Where CML1 is a complex mixture of C, shell,
> Tcl/Tk, and Makefiles, CML2 is all be written in a single language
> (Python).
I'd rather have 10 layers of brittle shell, awk, sed and
self-manipulating Makefiles, and a little C or C++ than one layer of
Python.
I will not install python to be able to compile my kernel.
And bloating the kernel by several hundred K to link in some python byte
code interpreter is just as bad.
Rewrite it in portable C or forget it.
> 6. Internationalization
> CML2 query prompts and menu banners are separated from the symbol
> dependency declarations. Thus CML2 system definitions can be
> internationalized and localized.
Argh! More bloat and confusion!
Right now it is difficult enough to direct a naive user to some obscure
kernel option that I want him to set.
Experiences with SuSE have shown that internationalization makes bug
reports much more difficult and causes a great deal of confusion.
Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> As long as it will still work with a minimum development environment (no
> TCL, TK, perl, or X). I still have to think whether I put lex/yacc on the 486,
> I just don't remember...
Python does dynamic binding with a lot of stuff. That means its relatively
easy to try and load gtk, fail, try and load tk, fail and go back to command
line
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> I will not install python to be able to compile my kernel.
> And bloating the kernel by several hundred K to link in some python byte
> code interpreter is just as bad.
What on earth are you smoking. Python is used to configure the kernel not
compiled into it.
> Right now it is difficult enough to direct a naive user to some obscure
> kernel option that I want him to set.
You give the CONFIG_ name. That is constant across the various string sets
> Experiences with SuSE have shown that internationalization makes bug
> reports much more difficult and causes a great deal of confusion.
And had SuSE stuck to German only nobody would have heard of them. You can't
expect everyone to be happy in English. Deal with it. Make sure the CONFIG_
names are constant across translation and visible and the rest can be dealt
with.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Felix von Leitner <felix@convergence.de>:
> And bloating the kernel by several hundred K to link in some python byte
> code interpreter is just as bad.
Get a grip, Felix. Nobody has proposed linking Python into the kernel.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
"Experience should teach us to be most on our guard to protect liberty
when the government's purposes are beneficient... The greatest dangers
to liberty lurk in insidious encroachment by men of zeal, well meaning
but without understanding."
-- Supreme Court Justice Louis Brandeis
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > As long as it will still work with a minimum development environment (no
> > TCL, TK, perl, or X). I still have to think whether I put lex/yacc on the 486,
> > I just don't remember...
>
> Python does dynamic binding with a lot of stuff. That means its relatively
> easy to try and load gtk, fail, try and load tk, fail and go back to command
> line
Easy and working, as the 0.1.2 beta of CML2 demonstrates.
It's possible to do this in other scripting languages, but only just --
you'd have to go through strange contortions with dynamically-generated
import statements.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
The direct use of physical force is so poor a solution to the problem of
limited resources that it is commonly employed only by small children and
great nations.
-- David Friedman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> > I will not install python to be able to compile my kernel.
> > And bloating the kernel by several hundred K to link in some python byte
> > code interpreter is just as bad.
> What on earth are you smoking. Python is used to configure the kernel not
> compiled into it.
I was talking about the kernel source tree.
> > Right now it is difficult enough to direct a naive user to some obscure
> > kernel option that I want him to set.
> You give the CONFIG_ name. That is constant across the various string sets
Have you ever tried to direct an NT admin over the phone how to compile
a kernel? It is difficult enough without having to tell him how to use
vi.
> > Experiences with SuSE have shown that internationalization makes bug
> > reports much more difficult and causes a great deal of confusion.
> And had SuSE stuck to German only nobody would have heard of them. You can't
> expect everyone to be happy in English. Deal with it. Make sure the CONFIG_
> names are constant across translation and visible and the rest can be dealt
> with.
Well, they aren't visible.
Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

> - -----------------------------------------------------------------------------
> There is what appears to be an error in the M68K configuration sequence.
> Inside a PARPORT guard, the question 'Q40 Parallel port' sets PARPORT again.
> I created a PARPORT_Q40 symbol and set it from this question.
ooops, that question somehow survived a merge. PARPORT_Q40 is unneeded,
PARPORT + PARPORT_PC is sufficient for Q40 hardware.
I agree that the old stuff needs a cleanup :)
Bye
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Jeff Garzik <jgarzik@mandrakesoft.com> writes:
> IMNSHO this attitude is wrong. If building the kernel is tough for
> newbies, make a userland utility with all these policy questions and
> features. We are talking about an interface on the KERNEL DEVELOPER
> side of the line.
Kernel configuration is a userland.
I think users should be able to configure the kernel using the same
environment as developers. I think any "user" config utils exist only
because make menuconfig might be a little too hard for beginners.
Of course, there is still expert mode.
> > This just can't be done with the existing kbuild system. The existing
> > config-language programs are hard to read and modify,
>
> huh? compared to what ? It is simple to read, simple to modify. The
> major nasty issue right now is dependencies not readability.
If you just mean Config.in files, then yes - they are quite simple.
Combined with Makefiles - I think it could be simpler.
> > There are a couple of preparation steps that can fruitfully begin now
> > and should happen before 2.4 in order to minimize backporting hassles
> > later.
>
> All this can be done post 2.4. Let's break _less_ not more
> configurations now.
I take it that steps don't break anything now.
> * It would be nice to be drop to add a new kernel module to the build
> without patching a single file. For example, instead of adding
> drivers/char/foo.c and patching drivers/char/{Config.in,Makefile}, the
> patch to Linus would simply add drivers/char/foo.c and
> drivers/char/foo.module. foo.module would contain configuration and
> build information normally found in Config.in and Makefile. Doing this
> implies some sort of collection step occurring, before the configuration
> and before the build.
I don't like this idea - number of files in drivers directory would
be doubled.
It may be better to include this info, say, near beginning or end
of file.c, like with Emacs formatting info.
Or continue to use one file per directory.
--
Krzysztof Halasa
Network Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

"Eric S. Raymond" wrote:
>
> James Sutherland <jas88@cam.ac.uk>:
> > > Even if this weren't true, we'd be trading dependencies and not adding
> > > one. The Perl stuff in the scripts directory will go away shortly
> > > (that is, assuming that Linus approves the CML1->CML2 change). This
> > > would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
> >
> > perlcc?
>
> Is, I'm told, a kluge much like the freeze tool. You can compile away
> control structure but you end up carrying around most of Perl as
> runtime support.
It statically links in libperl.a and behaves similar to writing a C
program that desires to use Perl's features. The down side is that if
you rely on Perl modules, you need to include them with the binary as
they are not compiled in. And why would you want to compile it away
anyways? I can't even think of a Linux distribution that doesn't include
it, and many require it.
But I have to ask, what's wrong with Perl for this? It's a well known,
fast, and flexible tool that allows rapid development and change. Seems
quite appropriate for this sort of effort.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Wed, 24 May 2000, Ed Carp wrote:
>George (greerga@nidhogg.ham.muohio.edu) writes:
>
>> >I've got an old 486/50 laptop that's got a couple of PCMCIA network cards in
>> >it, doing routing/NAT stuff between my home LAN and an ADSL line, and it works
>> >perfectly. It all boots off of floppies, and I'm working on getting it to
>> >boot off of one. It would be impossible if all my stuff were linked against
>> >xlib.
>>
>> Do you build kernels on your router?
>>
>> If not, then your point is moot.
>
>That statement is insane. Whether or not I build kernels on my router has
>absolutely nothing to do with the issue. And if you can't see the point,
>what are you doing here?
Since when do you link your kernel with Xlib?
The point is, you don't need Python to boot the kernel. Only the kernel
build configuration system would link with Xlib, optionally most likely.
Since you wouldn't compile kernels on your disk-booted router, you would
not need the kernel build stuff. Thusly, you would not need Python or
Xlib on the router floppy.
Hence, my point stands.
I don't see the huge argument against Python. Can people really not afford
6 MB of disk space for Python when the kernel compile itself can top 90 MB
for even non-kitchen-sink compilations?
Edit .config yourself with emacs/vi if you're that anal about 6 MB.
-George Greer
(Must we be so rude?)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

John Cavan <john.cavan@sympatico.ca>:
> But I have to ask, what's wrong with Perl for this? It's a well known,
> fast, and flexible tool that allows rapid development and change. Seems
> quite appropriate for this sort of effort.
Start with the absence of object serialization in Perl. Python's
pickle/unpickle was critical to the design.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Every Communist must grasp the truth, 'Political power grows out of
the barrel of a gun.'
-- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Thu, May 25, 2000 at 11:34:53PM -0400, Eric S. Raymond wrote:
> John Cavan <john.cavan@sympatico.ca>:
> > But I have to ask, what's wrong with Perl for this? It's a well known,
> > fast, and flexible tool that allows rapid development and change. Seems
> > quite appropriate for this sort of effort.
>
> Start with the absence of object serialization in Perl. Python's
> pickle/unpickle was critical to the design.
Let's keep the language wars off the kernel list, please?
Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 25 May 2000, John Cavan wrote:
> "Eric S. Raymond" wrote:
> >
> > James Sutherland <jas88@cam.ac.uk>:
> > > > Even if this weren't true, we'd be trading dependencies and not adding
> > > > one. The Perl stuff in the scripts directory will go away shortly
> > > > (that is, assuming that Linus approves the CML1->CML2 change). This
> > > > would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
> > >
> > > perlcc?
> >
> > Is, I'm told, a kluge much like the freeze tool. You can compile away
> > control structure but you end up carrying around most of Perl as
> > runtime support.
>
> It statically links in libperl.a and behaves similar to writing a C
> program that desires to use Perl's features. The down side is that if
> you rely on Perl modules, you need to include them with the binary as
> they are not compiled in. And why would you want to compile it away
> anyways? I can't even think of a Linux distribution that doesn't include
> it, and many require it.
>
> But I have to ask, what's wrong with Perl for this? It's a well known,
> fast, and flexible tool that allows rapid development and change. Seems
> quite appropriate for this sort of effort.
I agree that Perl is fine. However, someone was suggesting getting rid of
the Perl scripts, apparently on the basis that Python can be "compiled"
with freeze; I pointed out that Perl can do the same.
Basically, I don't think trying to support compiling the kernel on a PC XT
using only MASM is a good idea - if you want to develop software, you need
some software tools.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Sorry, but why don't you simply use mconfig?
cml1 is much more intuitive than your cml2 with
its ugly functional-programming-like syntax and
braind-damaged separation of the cml-files.
You add yet another tool (python) to the requirements for a linux
kernel build. That's bad. Plain C is much better.
But your cml2 has also it's good sides:
- one parser with different frontends, same as mconfig.
- only one cml-tree, but this could be done with cml1 too.
(I'll write a simple patch for this today)
This wekk I started some hacking on mconfig, my version
(http://www.rks.harz.ni.schule.de/~c0hellwi/mconfig-0.18-C1.diff)
contains follwing new features:
- implements dep_mbool
- adds some new keys for the menu interface
- adds an line-oriented interface (not yet ready)
- removes the "operator '!' not compatible with old interpreters" warning,
because now every interpreters understands it.
WARNING: the mode-line code is not finished, some parts
don't work and some are not implemented ...
you need the following patch for 2.4.0-test1 to let mconfig parse the cml1
tree: http://www.rks.harz.ni.schule.de/~c0hellwi/mconfig-0.18-C1.diff
Christoph
--
Always remember that you are unique. Just like everyone else.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/