Mailing List Archive

alan@lxorguk.ukuu.org.uk said:
> The BSD setup is not end user friendly. There is actually only one
> fundamental end user problem with our current setup. When a user says
> 'I want XYZ' it should turn on everything needed to get XYZ.
> If I hit my capture card option it should turn on i2c,
> video4linux,procfs, etc
The way the Nemesis 'make xconfig' does this is quite nice.
--
dwmw2
-
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 Tue, May 30, 2000 at 03:56:10PM +0100, David Woodhouse wrote:
>
> alan@lxorguk.ukuu.org.uk said:
> > The BSD setup is not end user friendly. There is actually only one
> > fundamental end user problem with our current setup. When a user says
> > 'I want XYZ' it should turn on everything needed to get XYZ.
>
> > If I hit my capture card option it should turn on i2c,
> > video4linux,procfs, etc
>
> The way the Nemesis 'make xconfig' does this is quite nice.
I'm not sure that this is the right way to do it. I prefer a more
profile-based approach -- I should be able to just select `IBM' then
`Thinkpad 600E' and then go and select my expansion cards. If someone
self-builds a machine, then they could start out with `Generic PCI-based
x86' and go from there; if they built the machine they should know what's
in it.
--
The Sex Pistols were revolutionaries. The Bay City Rollers weren't.
-
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:
> Yes. The existing CML2 code does this automatically. If you say
>
> cmlconfigure -DARM
>
> options for X86, SPARC, etc won't even be queried for. CML2 freezes
> the other architecture symbols at N and uses a little theorem prover
> to deduces from those what questions should not be asked.
hmmm, this is completely different from the current system. The current
system "knows" what architecture you are configuring. Users shouldn't
have to specify a -D to get this behavior..
Jeff
P.S. Can you package cml to extract into something other than the
current directory? ie. extract the tarball into cml-x.y.z/*
--
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/

Jeff Garzik <jgarzik@mandrakesoft.com>:
> "Eric S. Raymond" wrote:
> > Yes. The existing CML2 code does this automatically. If you say
> >
> > cmlconfigure -DARM
> >
> > options for X86, SPARC, etc won't even be queried for. CML2 freezes
> > the other architecture symbols at N and uses a little theorem prover
> > to deduces from those what questions should not be asked.
>
> hmmm, this is completely different from the current system. The current
> system "knows" what architecture you are configuring. Users shouldn't
> have to specify a -D to get this behavior..
There's no magic there. The current system only knows because the
Makefile sets an ARCH symbol to one of the following:
alpha i386 m68k mips64 s390 sparc arm ia64 mips ppc sh sparc64
The Makefile then uses that to generate the name of the top-level config file
So this is not "completely different"; the only question is how and where to
do the following mapping:
alpha -DALPHA
i386 -DX86
m68k -DM68K
mips64 -DMIPS64
s390 -DS390
sparc -DSPARC32
arm -DARM
ia64 -DIA64
mips -DMIPS32
ppc -DPPC
sh -DSUPERH
sparc64 -DSPARC64
The following line does it...
PREDEF := -D$(shell uname -m | sed \
-e s/i.86/x86/ \
-e s/sun4u/sparc64/ \
-e s/arm.*/arm/ \
-e s/sa110/arm/ \
-e s/sparc$$/sparc64/ \
-e s/mips$$/mips64/ \
-e s/sh$$/superh64/ \
| tr "[a-z]" "[A-Z]")
> P.S. Can you package cml to extract into something other than the
> current directory? ie. extract the tarball into cml-x.y.z/*
Gak! I just violated my own practice guidelines! :-)
I'll fix.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Faith may be defined briefly as an illogical belief in the occurrence
of the improbable...A man full of faith is simply one who has lost (or
never had) the capacity for clear and realistic thought. He is not a
mere ass: he is actually ill.
-- H. L. Mencken
-
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 Fri, May 26, 2000 at 09:22:18PM -0400, Eric S. Raymond wrote:
> CML2 is aimed at this. It will never be perfect -- perfection would require
> a full theorem prover -- but it's already good enough to handle normal
> ancestry relationships.
Perhaps a CML2 engine should be written in ML to solve this problem?
;-)
--Chris
-
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/

Christopher Smith <x@xman.org>:
>On Fri, May 26, 2000 at 09:22:18PM -0400, Eric S. Raymond wrote:
>> CML2 is aimed at this. It will never be perfect -- perfection would require
>> a full theorem prover -- but it's already good enough to handle normal
>> ancestry relationships.
>
> Perhaps a CML2 engine should be written in ML to solve this problem?
> ;-)
Not necessary. CML2 0.2.0 actually includes a theorem prover that does
substitution and algebraic reduction on the constraints and then forces
variables based on the resulting relational assertions.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Americans have the right and advantage of being armed - unlike the citizens
of other countries whose governments are afraid to trust the people with arms.
-- James Madison, The Federalist Papers
-
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/

-----BEGIN PGP SIGNED MESSAGE-----
Yes, but its nice to be able to override that behavior for
cross compiling. Linus seems to assume people want to compile
the kernel on the same type of box as the kernel will be running
on; this is sometimes a pain in the butt.
Eric: teaching ones grandmother to suck eggs is rather extreme;
my reference to lex and yacc had more to do with the fact you aren't
as familiar with the mores and society of the kernel group as you could
be; if you were you would have known what a storm of protest the use
of python would have raised, which using lex and yacc would have
avoided almost altogether.
--sig--
It isn't true unless it makes you laugh, but you don't
really understand it till it makes you cry.
On Wed, 31 May 2000, Jeff Garzik wrote:
> > cmlconfigure -DARM
> > options for X86, SPARC, etc won't even be queried for. CML2 freezes
> > the other architecture symbols at N and uses a little theorem prover
> > to deduces from those what questions should not be asked.
>
> hmmm, this is completely different from the current system. The current
> system "knows" what architecture you are configuring. Users shouldn't
> have to specify a -D to get this behavior..
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOTh7ZMK9HT/YfGeBAQE+mAP9FWMsgRkFHirb0gXcT4mML+irNNIMR7ZC
aqkp4W8OVFbeDHEbp7tjJnErfqjXUYwG23ct31tdY9mRM7uqME98I3OgwqDqtJC+
auv1C1mkVlsFar3IHrGQ1Uwi5lZ40rWZaHBKriT5mMbkTsrLEPdbTY2ka+GtEDQk
HPCbE5DtDP4=
=TLtm
-----END PGP SIGNATURE-----
-
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/

Jonathan Walther <krooger@debian.org>:
> Eric: teaching ones grandmother to suck eggs is rather extreme;
> my reference to lex and yacc had more to do with the fact you aren't
> as familiar with the mores and society of the kernel group as you could
> be; if you were you would have known what a storm of protest the use
> of python would have raised, which using lex and yacc would have
> avoided almost altogether.
I'd have proposed it anyway. because the first law of this crowd is
"Laugh in the face of danger!".
Uh, no, actually it's "the Right Thing is more important than the
amount of flamage you need to go through to get there". And Python is
the Right Thing for this job.
Don't believe me? Fine. Keep an eye on the various gentlemen who are
promising C-CML2 implementations. Their intentions are good. Their
skills are, I have no doubt, quite sharp. It will be ... interesting ...
to see how far they get.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
The spirit of resistance to government is so valuable on certain
occasions, that I wish it always to be kept alive. It will often be
exercised when wrong, but better so than not to be exercised at all.
I like a little rebellion now and then. It is like a storm in the
Atmosphere.
-- Thomas Jefferson, letter to Abigail Adams, 1787
-
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/

-----BEGIN PGP SIGNED MESSAGE-----
Using Python isn't the kind of "laughing in the face of danger" they
admire. After all, Python is a wimpy fru-fru Object Oriented language;
no self respecting kernel he-man would lower himself to rely on
one of THOSE to compile his kernel. No sirree bob, its gotta be
C and gmake all the way, with possibly a bit of bash and tcl
thrown in. Although it should soon (I give it 2 years) Python has
not yet entered the pantheon of "installed on every Unix box"
tools and utilities. Good luck getting CML2 into the kernel.
--sig--
It isn't true unless it makes you laugh, but you don't
really understand it till it makes you cry.
On Fri, 2 Jun 2000, Eric S. Raymond wrote:
> > be; if you were you would have known what a storm of protest the use
> > of python would have raised, which using lex and yacc would have
> > avoided almost altogether.
> I'd have proposed it anyway. because the first law of this crowd is
> "Laugh in the face of danger!".
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOTiItMK9HT/YfGeBAQHjOQP7BC3s05+P4IjXpOKVtq9BUWxEl7zW9W9P
/35q4JHwyUnJEzXJmpzxRYCb0Gk4TJyVDpkI6eHrjUJtrC9tH6LOZ+RBG9l/mVpN
cleJ1/L6q5qbqW7MzhjLu1ZrC06jqsIbzVlcUI8KlijcHO//Z2tdKzxfZGneHKDI
eLL1xat/K6s=
=dDHc
-----END PGP SIGNATURE-----
-
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/

* Jonathan Walther (krooger@debian.org) wrote:
> Using Python isn't the kind of "laughing in the face of danger" they
> admire. After all, Python is a wimpy fru-fru Object Oriented language;
> no self respecting kernel he-man would lower himself to rely on
> one of THOSE to compile his kernel. No sirree bob, its gotta be
> C and gmake all the way, with possibly a bit of bash and tcl
> thrown in.
Urm. Since when was the philosophy of this group "use an inappropriate
tool for the job because that's what Real Men Do"?
The reasons for choosing languages are many, but "because it puts hair
on your chest" should never be among them.
Wimpy fru-fru? Heh. How about "ideally suited to task", or "the fastest
way to a good stable implementation"?
> Although it should soon (I give it 2 years) Python has
> not yet entered the pantheon of "installed on every Unix box"
> tools and utilities.
Well, there's one way to accelerate *that* process, isn't there?
> Good luck getting CML2 into the kernel.
I agree.
Tom.
--
.------------------------------------------------------.
.^. | Tom Gilbert, England | http://www.linuxbrit.co.uk |
/V\ |----------------------| gilbertt@linuxbrit.co.uk |
// \\ | Sites I recommend: `-------------------------------|
/( )\ | www.freshmeat.net www.enlightenment.org slashdot.org |
^^-^^ `------------------------------------ vim: set tw=72: -'
-
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/

In article <linux.kernel.20000603154538.B28004@ummagumma>,
Tom Gilbert <gilbertt@linuxbrit.co.uk> wrote:
>* Jonathan Walther (krooger@debian.org) wrote:
>> Using Python isn't the kind of "laughing in the face of danger" they
>> admire. After all, Python is a wimpy fru-fru Object Oriented language;
>> no self respecting kernel he-man would lower himself to rely on
>> one of THOSE to compile his kernel. No sirree bob, its gotta be
>> C and gmake all the way, with possibly a bit of bash and tcl
>> thrown in.
>
>Urm. Since when was the philosophy of this group "use an inappropriate
>tool for the job because that's what Real Men Do"?
It depends on what the job is.
If the job is ``wedge Python into the kernel so it can be used as
advertising against Perl'', then, yes, Python is the ideal tool
for the job.
If the job is ``clean up the kernel configuration process'', then
it's not so clear that Python is appropriate. I am using (and
hacking as needed) a variant of mec's mconfig tool, and it is *very*
good about properly reporting bugs in the kernel configuration
scripts, and it has the decided advantages that it's written in C, it
doesn't use anything fancier than ncurses (which is already used by
menuconfig, and it's _very_ likely that you'll find ncurses as a
standard component on a Linux distribution), and it doesn't break
the entire universe and replace it with a new one that has the
reference implementation in some horrid little scripting language.
____
david parsons \bi/ I suspect that mconfig would work with real curses,
\/ but, alas, I don't have many copies of that around.

-
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 Fri, Jun 02, 2000 at 09:25:23PM -0700, Jonathan Walther wrote:
> Using Python isn't the kind of "laughing in the face of danger" they
> admire. After all, Python is a wimpy fru-fru Object Oriented language;
> no self respecting kernel he-man would lower himself to rely on
> one of THOSE to compile his kernel. No sirree bob, its gotta be
This thread is ridiculous. We're talking about the tool used to
configure the kernel, not *run* the kernel. Python may be "wimpy and
fru-fru", but IMHO it's no worse than make or bash (with similar
benefits). Sure, it may not be installed on every system, but that's
largely because there hasn't been a compelling reason to have it
installed rather than there being a compelling reason to NOT install
it. "make menuconfig" requires curses, "make xconfig" requires Tk &
Tcl. Big deal. Amazingly, to build the kernel you have to include this
HUGE application that opens up large opportunities for security
compromises called "gcc".
It's trivial to edit a config file with your choice of editor (I'm
sure a CML2-mode will be out for emacs shortly ;-), it's trivial to
compile a kernel on one machine to install on another. Ergo: you don't
need Python on ever Linux box to build your kernel. Eric chose Python
for a lot of reasons, and I think it has some clear benefits
(transparency of scripts is certainly beneficial, as is ease of
implementation).
Give up on this thread, or fork it off on to a debate about why the
kernel shouldn't be written in C because it's too much of a "wimpy and
fru-fru procedural language" which isn't as pervasively installed out
there as /bin/sh.
--Chris
-
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/