Mailing List Archive

On Thu, 25 May 2000, 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.
Hey, let's not have the language war. Perl can do object serialization
with Data Dumper and several others. You have exactly the same access to
the symbol tables in both languages and walking them is trivial. The two
languages are widely recognized to be roughly equivalent in terms of ease
of development.
Eric, it might be useful for you to try freezing your current code and
tell us if the result a) works b) isn't too ungainly.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
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/

Pick up the current edition of Linux Journal and read the Python
supplement. Young ESR is in there explaining why Perl blows g0ats.
d
On Fri, 26 May 2000, Oliver Xymoron wrote:
> On Thu, 25 May 2000, 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.
>
> Hey, let's not have the language war. Perl can do object serialization
> with Data Dumper and several others. You have exactly the same access to
> the symbol tables in both languages and walking them is trivial. The two
> languages are widely recognized to be roughly equivalent in terms of ease
> of development.
>
> Eric, it might be useful for you to try freezing your current code and
> tell us if the result a) works b) isn't too ungainly.
>
> --
> "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
>
>
> -
> 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/
>
-
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/

> Pick up the current edition of Linux Journal and read the Python
> supplement. Young ESR is in there explaining why Perl blows g0ats.
Can people talk the perl v python thread to the usual places that is
comp.lang.perl cross posted to comp.lang.python, alt.flame, alt.test and
probably alt.syntax.tactical
We don't want it any more than they do 8)
-
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/

Daniel Stone (tamriel@ductape.net) writes:
> Pick up the current edition of Linux Journal and read the Python
> supplement. Young ESR is in there explaining why Perl blows g0ats.
It's no longer the current edition - it's the May edition. June is already
out.
--
Ed Carp, N7EKG erc@pobox.com 940/367-2744 cell phone
http://www.pobox.com/~erc
-
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 <E12vJW9-0001Mx-00@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Pick up the current edition of Linux Journal and read the Python
>> supplement. Young ESR is in there explaining why Perl blows g0ats.
>
>Can people talk the perl v python thread to the usual places that is
>comp.lang.perl cross posted to comp.lang.python, alt.flame, alt.test and
>probably alt.syntax.tactical
Getting into a language war will almost guarantee that CML2 will never be
adopted.
--
__O
Fireplug - a Lineo company _-\<,_
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 (_)/ (_) 88 EC A3 EE 2D 1C 15 68
Stuart Lynne <sl@fireplug.net> www.fireplug.net 604-461-7532
-
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:31:44PM -0400, Eric S. Raymond wrote:
> > > I can in fact generate C programs to compile and interpret CML -- by
> > > applying freeze.py to the Python sources.
> > OK - are you saying that Python will generate C sources?
> Yes, that is exactly what I am saying. There is a Python tool called "freeze"
> that takes a Python program and generates equivalent C sources.
How does that cope with stuff like _tkinter which needs to link with an
external library? Stock Python dlopens a "_tkinter.so", which is linked
against the Tk libraries; is there some kind of hack which allows the frozen
Python program to attempt to dlopen the Tk libraries at runtime?
--
Adam Sampson
azz@gnu.org
-
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/

Adam Sampson <azz@gnu.org>:
> How does that cope with stuff like _tkinter which needs to link with an
> external library? Stock Python dlopens a "_tkinter.so", which is linked
> against the Tk libraries; is there some kind of hack which allows the frozen
> Python program to attempt to dlopen the Tk libraries at runtime?
I don't know. I'll have to experiment and see.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
"Among the many misdeeds of the British rule in India, history will look
upon the act of depriving a whole nation of arms, as the blackest."
-- Mohandas Gandhi
-
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-----
bash-2.03$ python
Python 1.5.2 [GCC 2.95.2 19991024 (release)] on openbsd2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>print "lex and yacc were invented for a reason."
lex and yacc were invented for a reason.
>>>^D
bash-2.03$
--sig--
It isn't true unless it makes you laugh, but you don't
really understand it till it makes you cry.
On Wed, 24 May 2000, Alex Buell wrote:
> On Wed, 24 May 2000, Eric S. Raymond wrote:
>
> > 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.
>
> I'm not entirely convinced that it is desirable to have to install yet
> another scripting language just to run CML2.
>
> Why not write a C program to interpret CML2? - I assume that if you have
> the kernel sources, you already have a C compiler around. That at least,
> is the minimum one should aim for.
>
> Cheers,
> Alex
> --
> The quality of your life will be determined by
> the quality of the people in your life.
>
>
> -
> 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 SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOS8Tn8K9HT/YfGeBAQFkmQP/QnXRsyNlvVwNIPRrEfqy6/zb0GBGp3s/
fsPyMyIEEFlgh+d2N93uKGx1SoZvxMfqp5hqrvg6+79TabXvGpu71xUu4OMe05+L
rx8el2lkbuYIkez93sAnxxEizOC0g2ARh+k54nNaCLgCd1IxH4fPEb5E3YIF4zRl
OV2mApciru4=
=ETDM
-----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/

-----BEGIN PGP SIGNED MESSAGE-----
I agree; why CAN'T we configure the linux kernel more like we do the
BSD ones? Their code and schema is very elegant and simple. And
the source shouldn't be too hard to port over. David Parsons? Oh
thats right, Linus ignores his patches. Oh well.
--sig--
It isn't true unless it makes you laugh, but you don't
really understand it till it makes you cry.
On Wed, 24 May 2000, Dominik Kubla wrote:
> I really don't like the added complexity. IMHO we should ditch our current
> config scheme in favour of the BSD tools if at all: They are written in
> C, they are simple to use and they have a proven track record. What more
> is there to ask?
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOS8XoMK9HT/YfGeBAQE9IQP/QhVL5NSrDp+8AYtGAFROsp+A/pm1fSDa
pF03tUeffM+iudtUv3Z2rzalXqT6QyPUWgO6HKzsuED/5wfeSzfrUBWXW3O1STQd
2x9XiglqA+6oHIG5jGuIOMWisuYrUMLWVtcb1x4Ar88z/AzK7zW//KnNXg8UzPiy
3ZE+QwtiiDQ=
=ruRy
-----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/

> I agree; why CAN'T we configure the linux kernel more like we do the
> BSD ones? Their code and schema is very elegant and simple. And
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
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/

Jonathan Walther <krooger@debian.org>:
> bash-2.03$ python
> Python 1.5.2 [GCC 2.95.2 19991024 (release)] on openbsd2
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>>print "lex and yacc were invented for a reason."
> lex and yacc were invented for a reason.
> >>>^D
> bash-2.03$
Yes, yacc and lex were invented for a reason. Happens I'm quite
familiar with that reason and more than averagely skilled at using
both of them, as you can verify by looking at any of the following
projects of mine: keybind, intercal, cupl, pilot, or fetchmail.
Now, if you actually look at these, you might decide that I'm really
an incompetent fuckup. But if that's the case, then we don't have
much of a conversation -- I'm going to do a poor job whether I
use yacc/lex or Python or anything else.
So, just for the sake of conversation, let's assume that I knew what I
was doing on those five yacc/lex projects (and half a dozen other ones
that haven't been published for this or that reason). You don't have
to consider me a tremendously bright spark to believe that after doing
eleven or so projects with these tools over a period of about fifteen
years I have a pretty fair idea what they're good for.
When I wrote my first yacc/lex application, Bison and flex didn't
*exist* yet. If you're among the younger members of this list, it is
quite possible that you were still in potty-training at the time.
It is also a matter of record that in 1991, nine years ago, I was already
sufficiently intimate with yacc and lex to write the INTERCAL compiler
over a weekend. You are of course free to assume that I've succumbed to
galloping senility rather than actually learning more since then. But
would you consider that conjecture a safe bet?
Assuming that all that experience actually means something leads us to
the next question -- since I know these tools so well, why didn't I
use them for this project?
Could it be that they might have *gasp* limitations? Could it be that
yacc and lex are not the optimal answer to every parsing problem in
the known universe? Might we entertain the possibility, however
remote and unlikely it might seem, that I have one or two clues and
have actually employed same?
I respectfully suggest you meditate on the phrase "teaching your
grandmother to suck eggs" until you achieve enlightenment.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
Love your country, but never trust its government.
-- Robert A. Heinlein.
-
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 Sat, 27 May 2000, Alan Cox wrote:
> > I agree; why CAN'T we configure the linux kernel more like we do the
> > BSD ones? Their code and schema is very elegant and simple. And
>
> 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.
Of course, informing the user that it does so and *WHY* would be a good
idea too. Somewhat like dselect but without all the bugs and hassles
(dselect has a lot of them, hence I use apt-get instead.)
> If I hit my capture card option it should turn on i2c,
> video4linux,procfs, etc
Yup. Agreed... Then again, a thing I'd appreciate is something like
multiple configure universa. Thus, I could either choose a bus-view
(and be present by a hierarchy based on hardware) or a driver-type
(sorted on functionality) or a flat-view (alphabetical, for
instance) or... The possibilities are vast, but the complexities would
probably be overwhelming. I'd gladly be proven wrong here, though.
/David Weinehall
_ _
// 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/

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> 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
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.
One of the purposes of making the CML2 language declarative rather than
imperative is to make all the dependencies explicit, rather than implied
by control structure as in CML1. Because that's so, over time it will
be possible to improve the deductive algoritms in the front end without
having to endure another replacement of the language.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze a new problem,
pitch manure, program a computer, cook a tasty meal, fight efficiently,
die gallantly. Specialization is for insects.
-- Robert A. Heinlein Time Enough for Love
-
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, 26 May 2000, Eric S. Raymond wrote:
> One of the purposes of making the CML2 language declarative rather than
> imperative is to make all the dependencies explicit, rather than implied
> by control structure as in CML1. Because that's so, over time it will
> be possible to improve the deductive algoritms in the front end without
> having to endure another replacement of the language.
Sigh... I suspect that it's the real reason why your approach doesn't make
sense to me - you are developing complex stuff that works for FUBAR domain
instead of getting the domain fixed.
Try to grep the tree for CONFIG_FOO - you'll see that most of the places
that care are in Makefiles. 99% of the rest is not needed - check the
history of fs/filesystems.c for example.
IOW, instead of developing clever ways to handle complex dependencies
we'ld be better off simplifying them and leaving the rest to make(1)...
-
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/

David Weinehall <tao@acc.umu.se>:
> On Sat, 27 May 2000, Alan Cox wrote:
>
> > > I agree; why CAN'T we configure the linux kernel more like we do the
> > > BSD ones? Their code and schema is very elegant and simple. And
> >
> > 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.
>
> Of course, informing the user that it does so and *WHY* would be a good
> idea too. Somewhat like dselect but without all the bugs and hassles
> (dselect has a lot of them, hence I use apt-get instead.)
The tty mode of CML2 gives you this kind of feedback when you hit a
constraint violation. I'm working on making the feedback more informative.
Again, this is the sort of thing that requires an atemporal, declarative
view of the world rather than a temporal, imperative one. Which is why
the change to the CML2 language is really important -- it makes doing
dselect-like things possible.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
We shall not cease from exploration, and the end of all our exploring will be
to arrive where we started and know the place for the first time.
-- T.S. Elliot
-
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/

Hi. I am (obviously ;) not a big kernel developer (although I aspire
someday) but I've saved up a few thoughts on this thread over the last few
days. For what it's worth:
> Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > If I hit my capture card option it should turn on i2c, video4linux,procfs,
> > etc
I really like this (as an option) but one addendum I would like to see is
having it mark all of the dependencies it turns on somehow so that you can
see they are turned on because of something else you turned on rather than
by default.
++complexity;
On Fri, 26 May 2000, 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.
I'd also like to chime in on the side of remembering that even if we hate
ESR's implementation of CML2, we might want to keep the language spec and
implement our own. So let's encourage him to keep on developing it so we
can steal the good parts, rather than just flamewarring over C vs. python
vs. perl vs. flamewars vs. ... :)
-Jacob
-
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/

> 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.
Our relationships are heirarchical so you can build a dependancy graph and
then recursively backtrack to find the dependancies.
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/

Alexander Viro <viro@math.psu.edu>:
> > One of the purposes of making the CML2 language declarative rather than
> > imperative is to make all the dependencies explicit, rather than implied
> > by control structure as in CML1. Because that's so, over time it will
> > be possible to improve the deductive algoritms in the front end without
> > having to endure another replacement of the language.
>
> Sigh... I suspect that it's the real reason why your approach doesn't make
> sense to me - you are developing complex stuff that works for FUBAR domain
> instead of getting the domain fixed.
One war at a time, Alex. If we try to replace the whole Makefile system
at the same time that we clean up the Augean stable that is CML1 it will
create havoc.

> Try to grep the tree for CONFIG_FOO - you'll see that most of the places
> that care are in Makefiles. 99% of the rest is not needed - check the
> history of fs/filesystems.c for example.
You may be right. But CML2 is simpler than what it's replacing by a
large (and readily measurable) factor, so it's a net win to make that
change anyway. *Then* we can go clean up the rest of the build
system.
> IOW, instead of developing clever ways to handle complex dependencies
> we'ld be better off simplifying them and leaving the rest to make(1)...
If that were possible, I have little doubt it would have been done already.
But I tell you what. After phase II, when we fix the rest of the build
system, I promise to seriously re-examine the question of whether CML2
is really needed. If it isn't, we'll throw it away.
I mean that. There are other uses for CML2 -- VA wants me to make it
into a product configurator, among other things -- so the work won't
have been wasted even if we throw away the kernel rulebase.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
False is the idea of utility that sacrifices a thousand real advantages for
one imaginary or trifling inconvenience; that would take fire from men because
it burns, and water because one may drown in it; that has no remedy for evils
except destruction. The laws that forbid the carrying of arms are laws of
such a nature. They disarm only those who are neither inclined nor determined
to commit crimes.
-- Cesare Beccaria, as quoted by Thomas Jefferson's Commonplace book
-
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/

> Yeah, but it's a DAG rather than a tree. There are other things that
> complexify it, too. Like the difference between "suppress dependant"
The backtracking is the same for the DAG except you need to remember
'already visited' nodes so that you don't look finding the solution path.
If you already visited a node then its dependancies are either resolved
or you are resolving them now and they are resolved if you can resolve
without rewalking the path.
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/

On Fri, 26 May 2000, Eric S. Raymond wrote:
> > Sigh... I suspect that it's the real reason why your approach doesn't make
> > sense to me - you are developing complex stuff that works for FUBAR domain
> > instead of getting the domain fixed.
>
> One war at a time, Alex. If we try to replace the whole Makefile system
> at the same time that we clean up the Augean stable that is CML1 it will
> create havoc.
You are missing the real Augean stable - output of
% find /usr/src/linux -type f|xargs grep -n '#ifdef' /dev/null
- that's where the real dung is, problems with configuration complexity
are direct results of it...
> > Try to grep the tree for CONFIG_FOO - you'll see that most of the places
> > that care are in Makefiles. 99% of the rest is not needed - check the
> > history of fs/filesystems.c for example.
>
> You may be right. But CML2 is simpler than what it's replacing by a
> large (and readily measurable) factor, so it's a net win to make that
> change anyway. *Then* we can go clean up the rest of the build
> system.
Oh, that's fine - the fact that new variant is more compact and readable
is a Good Thing(tm), no arguments here.
> > IOW, instead of developing clever ways to handle complex dependencies
> > we'ld be better off simplifying them and leaving the rest to make(1)...
>
> If that were possible, I have little doubt it would have been done already.
It _is_ beeing done. Been there, done some parts of that. Seriously, one
of the goals to keep in mind is <strong> the less #ifdef's the better
</strong>. For a lot of obvious reasons, not the last of them being that
if the majority of config options will affect only the choice of object
files to be linked we will have a chance to get automated testing of the
whole thing - at least on the "does it compile?" level.
BTW, I'ld really recommend to run the search - you'll see the heaploads of
crap and there used to be more of that stuff. Some pieces resemble typical
GNU code - #ifdef on every third 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/

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > 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.
>
> Our relationships are heirarchical so you can build a dependancy graph and
> then recursively backtrack to find the dependancies.
Yeah, but it's a DAG rather than a tree. There are other things that
complexify it, too. Like the difference between "suppress dependant"
and "suppress" -- sometimes ancestor symbols affect the valid range
of a symbol, sometimes they don't.
Consider the case where you fail a contraint while backtracking. It's
not obvious what the right policy is -- I've identified at least four
possibilities and I can think of circumstances where each one is right
and the other three wrong.
I certainly don't have all the answers. But I'm trying to get us to
a place where we can explore the questions without tripping over our
own damn feet.
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
"The bearing of arms is the essential medium through which the
individual asserts both his social power and his participation in
politics as a responsible moral being..."
-- J.G.A. Pocock, describing the beliefs of the founders of the U.S.
-
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.Pine.LNX.3.96.1000526173056.28897B-100000@localhost>,
Jonathan Walther <krooger@debian.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>I agree; why CAN'T we configure the linux kernel more like we do the
>BSD ones? Their code and schema is very elegant and simple. And
>the source shouldn't be too hard to port over. David Parsons? Oh
>thats right, Linus ignores his patches. Oh well.
Well, the latest version of the memory detection code kills a couple
of machines, so it's probably just as well that it isn't in the
mainline kernel but instead crashing a couple of obsolete or
hideously expensive motherboards that I can't find or don't wish to
raid the LART-farm account for.
In any case, there *is* a BSD-style configurator for Linux, though
it hasn't been maintained since 1.2.x -- Scott Telford wrote one for
Linux years ago, and it died when he bailed on Linux in favor of the
*BSDs. It plus mconfig (which is written in C, which wins bigtime
because it's not extra programs that I have to lug around to make a
Mastodon system self-compilable) would make an almost perfect pair,
even if the underlying data structures are a little bit grotty.
The whoops-time-to-fork-the-linux-kernel showstopper for me is that
the reference implementation of this new configuration language is
written in Python, and, given the fluidity of linux kernel
development and the impossibility of getting patches to Linus unless
you're a member of the Core Team, this would probably mean that the
Python implementation would be the only implementation that would
ever work.
____
david parsons \bi/ I can see using perl or python to parse a real BSD
\/ config file (though I'm trying to do it in C), but
the Linux kernel configuration arrangement is fairly
simple and, thanks to MEC, fairly clean.
-
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/

Alexander Viro <viro@math.psu.edu>:
> You are missing the real Augean stable - output of
> % find /usr/src/linux -type f|xargs grep -n '#ifdef' /dev/null
> - that's where the real dung is, problems with configuration complexity
> are direct results of it...
Ghods. You're right, that is pretty nasty. The *next* war...
--
<a href="http://www.tuxedo.org/~esr">Eric S. Raymond
The day will come when the mystical generation of Jesus by the Supreme
Being as his father, in the womb of a virgin, will be classed with the
fable of the generation of Minerva in the brain of Jupiter.
-- Thomas Jefferson, 1823
-
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 Sat, 27 May 2000, Eric S. Raymond wrote:
> Alexander Viro <viro@math.psu.edu>:
> > You are missing the real Augean stable - output of
> > % find /usr/src/linux -type f|xargs grep -n '#ifdef' /dev/null
> > - that's where the real dung is, problems with configuration complexity
> > are direct results of it...
>
> Ghods. You're right, that is pretty nasty. The *next* war...
Feel free to join... Another source of fun: take a random file
from inlude/*/, pick a random prototype defined there, grep the tree for
said beast. Estimate the probability of finding the function in question
a) called by somebody
b) defined somewhere
c) (a) && !(b)
Admittedly, P(c) is pretty low, but non-zero. P(!b) is _far_ from zero.
Now, for _real_ fun grep for LINUX_VERSION_CODE. Pay attention to
advansys.c - there are some real pearls (most of their, erm, analogs in
other SCSI drivers had been flushed in October, hell knows how did these
ones crawl back).
-
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/

Alexander Viro wrote:
> Admittedly, P(c) is pretty low, but non-zero. P(!b) is _far_ from zero.
> Now, for _real_ fun grep for LINUX_VERSION_CODE. Pay attention to
> advansys.c - there are some real pearls (most of their, erm, analogs in
> other SCSI drivers had been flushed in October, hell knows how did these
> ones crawl back).
I sent in a patch to Linus once to clean that that trash up but it was
only partially applied. Advansys.c was the part that wasn't applied. I
can shave off almost 100k from it by dropping stuff for earlier that
2.2.x.
--
Brian Gerst
-
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/