Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
James Bottomley :
> Actually, I think this whole code vs people debate is a straw man and
> inherently inimical to the discussion. In neither code of conduct (old
> or new) is there any statement that allows one to make a value judgment
> of people relative to code, so the very premise you're all arguing on
> doesn't exist.
The author's original version of the new CoC is, however, associated
with (and intended by its author to implement) "The Post-Meritocracy
Manifesto".
https://postmeritocracy.org/
Do you think it's a stretch to see "people > code" in that?
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
signature.asc
Description: PGP signature
Re: [Ksummit-discuss] The linux devs can rescind their license grant.
Bruce Perens :
> The anonymous person is generally thought to have appeared on the net
> previously as MikeeUSA. That entity has a well-recorded history of misogyny
> and other anti-social behaviour. He's also complained to me recently that
> because of "people like me", the law prohibits him from marrying very young
> women. I mean single-digit young. Although he is not at all meritorious of
> your civil behavior, you may not wish to lower yourself to his level.
I strongly doubt it. I've had my own run-in with MikeeUSA; I remember
it vividly and unpleasantly. The prose style doesn't match. MikeeUSA
could barely maintain coherent communication; this guy is using
language that indicates he's at least several degrees brighter.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Eben Moglen : > reputational damage is *specifically* recognized as grounds for relief. > > No. Reputational damage is not mentioned at all, let alone > specifically recognized. I have no difficulty in finding the word "reputation" in the brief in in proximity with the phrase "increasing [the programmer's] recognition in his profession". In fact the brief notes " The Eleventh Circuit has recognized the economic motives inherent in public licenses, *even where profit is not immediate*" (Emphasis mine.) And "The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder *that the law will enforce.*" (Emphasis mine.) You seem to be denying that the brief says what it actually says. It not only qualifies reputational gain as a kind of economic gain - and thus losses as damage - but cites the Eleventh Circuit as a previous authority for the proposition, and affirms that these gains and losses can be a matter for the law. This disinclines me to trust the rest of your analysis or assertions. I think you are advocating for your interest in the perceived irrevocability of the GPL, and where this implies being less than fully forthcoming about the actual risks in *this* situation you are committing something perilously close to suppressio veri. This is not helpful. I've lived with a practising attorney since about the time she was one of the first-line legal reviewers for the original GPL back in the 1980s - we probably still have the draft printout with her scribbled annotations on it somewhere. "Only lawyers can interpret this voodoo" is not a good line to pull on me when it comes to open-source licensing; I don't buy it and she wouldn't either. Here's another sentence from the brief that I had forgotten: "Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material." - a particularly telling sentence in regard to the current controversy, and one I had forgotten. That there could be enough to win the day for the license revokers - they don't actually have to revoke, just assert that control. Pretty much equivalent to what the the Berne Convention's moral-rights provision does in Europe - they could claim that the CoC is a defacement of their work to which they refuse assent and have a case. I am not at all doubtful that the dissidents know these things; some of the language in the broadsides to lkml so indicates. Which is why I'm trying to get the kernel leadership to repair its unnecessarily high-handed behavior before somebody gets pissed off enough to actually drop a bomb. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Al Viro :
> * in case it needs to be spelled out: I am not at all interested
> in that kind of stunts. One of the reasons I thoroughly despise RMS
> and his bunch is the leverage game they tried to play with GPLv3;
> damned if I'm going to lower myself to their level.
Sorry, I did not mean to imply that you are one with the license-revokers.
More like "if even Al Viro thinks you fucked up your process, it would be
unwise to dismiss the opposition to the CoC as mere trolls".
*I* can't dismiss it, because I read my mail. Apparently lots of people think
that it is *my* job to fix this mess, or at least to give it a good hard
try. I doubt they're trolling; what would be the point?
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
NeilBrown : > I think you are blurring two groups here. > Ted describes "anti-CoC dissidents" as people who are advancing an > argument about rescinding their license. This is a smaller groups than > the "ant-CoC camp" who don't really like the CoC. I suspect is it is a > much smaller group when restricting to actual copyright holders. You may be right that these are semi-distinct groups. I don't think the distinction makes a lot of difference to my argument, though. Either way, (a) there's been a process failure by the leadership, and (b) the threat of a massive legal disruption is real. > I am against the CoC as it stands, but rescinding any license is such an > enormous over-reaction, I find the concept laughable. I'm...not sure I do. I was going to agree with you that it's a massive overreaction, but then a simple question occurred to me: what else could *I* do if I thought I had a significant stake (I don't; my kernel contributions are minor and old) and felt my interests were damaged? All this could have been avoided so easily. A felt need for a new Code should not have been followed by the immediate imposition of one, but by a public RFC process and consensus-building - a process in which even those who lost arguments about the construction of the code could know they had been heard. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. signature.asc Description: PGP signature
Re: The linux devs can rescind their license grant.
Theodore Y. Ts'o : > On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote: > > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of > > GPLed software have a specific right to relief (including injunctive > > relief) against misappropriation of their software. That ruling (which > > was the case of first impression on the binding status of the GPL) > > reputational damage is *specifically* recognized as grounds for relief. > > I've read the legal briefs, and I'm pretty sure they don't say what > you are claiming they say. Yes, I'm not a lawyer --- but that's OK > --- neither are you. How much are you willing to gamble on not being wrong? > The *vast* majority of the "anti-CoC dissidents" who have been > advancing this argument, have, as near as I can tell, little or no > copyright ownership in the kernel. I do not have any facts with which to dispute this specific claim. However, I do notice that a significant number of long-time contributors have put themselves in the anti-CoC camp. I note Al Viro as a recent example. Even supposing you are right about most of the anti-Coc people being outsiders, a tiny minority of people with a genuine IP stake could do a lot of damage. I ask again: how much are you willing to gamble on not being wrong? I definitely do not want to see the kind of explosion we could witness. I think you are making it more likely rather than less by appearing high-handed and dismissive. Because, whatever the merits of the CoC itself, there has been a process failure here. It doesn't look good to be defending that failure. A change like the CoC adoption was not a good thing to do without proper public notice, discussion, and consensus-building *beforehand*. This was an unforced error on the part of the leadership group; please, *please* don't compound it by digging in around the error. Do you really think you're going to win hearts and minds among insider dissidents - people with a genuine stake - by dismissing the opposition as a troll job? Instead of declaiming about "trolls", how about we fix the process failure instead? -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: The linux devs can rescind their license grant.
Greg Kroah-Hartman :
> On Thu, Oct 25, 2018 at 07:56:26AM +, visionsofal...@redchan.it wrote:
> > The linux devs can rescind their license grant.
>
> No they can not, please do not keep spreading false information.
I think the confusion about whether applying GPL can be rescinded has
obscured the most serious actual threat vector.
Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
GPLed software have a specific right to relief (including injunctive
relief) against misappropriation of their software. That ruling (which
was the case of first impression on the binding status of the GPL)
reputational damage is *specifically* recognized as grounds for relief.
The anti-CoC dissidents don't have to rescind their license grant to
cause a great deal of trouble. Instead they can invoke the doctrine
established in Jacobsen vs. Katzer, seeking restraining orders. The
line of argument is so simple that I could probably brief it myself,
and I'm not a lawyer - just somebody who had to become a topic
expert in this area to do my job as the founding president of OSI.
For that matter, I don't think the question of whether the GPL can be
rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing
attorney who has also studied the relevant law.
Be very skeptical about what the FSF or SFC tells you about this; they
have a very strong institutional/ideological incentive to affirm
irrevocability regardless of what the law actually says. I, on the
other hand, don't have an ideological stake to defend in that
argument; I'm telling you that the doctrine forbidding perpetual
grants may very well have teeth here. There is, at any rate,
significant risk that a court will see it that way.
Between Jacobsen vs. Katzer and the prohibition against perpetual grants
I think you are incurring a grave risk by assuming the dissidents have
no ammunition.
Better for both sides to climb down from a confrontational position
before real damage gets done.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Greg Kroah-Hartman : > This patch series adds this new document to the kernel tree, as well as > removes a paragraph from the existing Code of Conduct that was > bothersome to many maintainers. I think the changes have improved it. There is still a process issue with how this code was promulgated that is clearly bothering a lot of people, but I hope that problem is well enough understood that we don't need to rehash it. More transparency, more consultation, and more notice of intent to revise would help head off future problems. I do have one content recommendation. In the version at https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst which I presume is current, I see a paragraph that reads as follows: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for everyone, regardless of age, >body >size, disability, ethnicity, sex characteristics, gender identity and >expression, level of experience, education, socio-economic status, nationality, >personal appearance, race, religion, or sexual identity and orientation. I recommend that all the text from "everyone" on be struck as (a) unnecessary, and (b) tending to embroil the project in politico-cultural wars that can do it no good - and replaced by "every individual". That is, the result would read: >In the interest of fostering an open and welcoming environment, we as >contributors and maintainers pledge to making participation in our project and >our community a harassment-free experience for every individual. That is all that needs to be said. Listing all those specific categories of "regardless of" implicitly privileges certain kinds of identity (those listed) and disfavors others (those not listed). Further, some of the phrases used fo categories are political shibboleths that unavoidably drag in American presumptions not appropriate for an international project. Best to leave the whole mess out and just pledge to treat individuals well. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors
Josh Triplett : > > The words removed by this patch are a political statement. > > Choosing not to say those words is a political statement. The situation is not symmetrical. Choosing the protected classes in the CoC is a *change* in its implied politics. It's a change that is, obviously from LKML traffic, very contentious. If this were a tpurely technical matter, it would be described as not backwards-compatible. It's a change that, I submit, should not have been made without a clear consensus *in favor* of the change. Our culture has a process for this. It's called RFCs. If we want to designate protected classes to be called out in conductt guidelines, an RFC should be floated first and the change should be made only if rough consensus has been achieved. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
(I mistakenly sent this with 'r' previously. Please reply to this copy.) Alan Cox : > The wording IMHO just needs tightening up - and that's a useful > discussion that ought to he bad. I tihnk everyone understands the *inent* > of such wording - don't go around doxing people, or posting their home > address on facebook and calling for people to attend with pitchforks. I'm going to, again, avoid normative statements and try to clarify what the questions are here, speaking from my anthropologist/game-theorist head. As a matter of process, there are two different sets of issues about changing the CoC wording. Referring to my previous post on ethos and telos: https://lkml.org/lkml/2018/9/23/212 1. The wording needs to be tweaked to make it clearer what things are against the ethos. For example: we may want Code violations to include hateful speech on the mailing list directed at other LKML members. Does it follow that we want the Code to proscribe "hate speech" directed against third parties, or off-list "hateful" behavior? Perhaps we do, perhaps not; but either way the boundaries need to be clearer. 2. The language needs to be examined with particular care to discover where it implies a change to LKML's telos. I argue no position at this time about whether LKML's telos *should* change, but I note that the rather heated dissent the CoC has provoked comes from a widespread perception that it *is*, in fact, a none-too-covert attempt to alter the telos. I further note that this perception is supported by the CoC Author's "Post-Meritocracy manifesto". https://postmeritocracy.org/ Kernel contributors, understandably, want a clear read on whether the application of the CoC is to be guided by meritocratic or "post-meritocratic" principles. This is a telos issue, not just an ethos issue, and much more fundamental. I endorse a suggestion made elsewhere that a revised CoC would best be developed by an RFC-like process. Because *that is how we do such things*; that is *our* culture's mechanism for achieving and maintaining consensus on difficult issues. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Alan Cox : > The wording IMHO just needs tightening up - and that's a useful > discussion that ought to he bad. I tihnk everyone understands the *inent* > of such wording - don't go around doxing people, or posting their home > address on facebook and calling for people to attend with pitchforks. I'm going to, again, avoid normative statements and try to clarify what the questions are here, speaking from my anthropologist/game-theorist head. As a matter of process, there are two different sets of issues about changing the CoC wording. Referring to my previous post on ethos and telos: https://lkml.org/lkml/2018/9/23/212 1. The wording needs to be tweaked to make it clearer what things are against the ethos. For example: we may want Code violations to include hateful speech on the mailing list directed at other LKML members. Does it follow that we want the Code to proscribe "hate speech" directed against third parties, or off-list "hateful" behavior? Perhaps we do, perhaps not; but either way the boundaries need to be clearer. 2. The language needs to be examined with particular care to discover where it implies a change to LKML's telos. I argue no position at this time about whether LKML's telos *should* change, but I note that the rather heated dissent the CoC has provoked comes from a widespread perception that it *is*, in fact, a none-too-covert attempt to alter the telos. I further note that this perception is supported by the CoC Author's "Post-Meritocracy manifesto". https://postmeritocracy.org/ Kernel contributors, understandably, want a clear read on whether the application of the CoC is to be guided by meritocratic or "post-meritocratic" principles. This is a telos issue, not just an ethos issue, and much more fundamental. I endorse a suggestion made elsewhere that a revised CoC would best be developed by an RFC-like process. Because *that is how we do such things*; that is *our* culture's mechanism for achieving and maintaining consensus on difficult issues. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Licenses and revocability, in a paragraph or less.
freedomfromr...@aaathats3as.com : > As has been stated in easily accessible terms elsewhere: > "Most courts hold that simple, non-exclusive licenses with unspecified > durations that are silent on revocability are revocable at will. This means > that the licensor may terminate the license at any time, with or without > cause." + Furthermore, license revocation is not the only option. In Jacobsen vs. Katzer (535 F.3d 1373 (Fed. Cir. 2008) it was found that open-source developers have an actionable right not to have their software misappropriated even though the resulting damages are only reputational rather than monetary. Under that theory, developers can seek an injunction against a misappropriating party without globally revoking their license. The application of that case law to this situation is left as an easy exercise for the reader. Any competent paralegal could write the brief in an evening. Hell, I could almost do it myself. I do not personally want to see this happen. But that it is possible is a fact all parties must deal with. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Theodore Y. Ts'o :
> There have been those who have characterized the GPL as being more
> than just a license, but also a political statement. And yet, many
> projects, include Linus, use the GPL without necessarily subscribing
> to all of Richard Stallman's positions, political or otherwise.
The case isn't parallel. Every kernel dev knew they were joining a
commons defined by GPL terms when they signed on. Regulation of
soi-disant "hateful" speech and "diversity" objectives, on the other
hand, are a *new* set of claims and norms not entailed in established
practice.
There ought to be much broader consensus before anything like that is done -
and I would say that even about new political claims I myself supported.
Instead, what we have is open revolt from a dissident faction that thinks
the project would be better destroyed than under the CoC.
That should be a clue that imposing the CoC without a lot of public
discussion and preparation was a mistake, and it should be revereted until
at least rough consensus in fovor of some improvement on the old
Code is achieved.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Re: Code of Conduct: Let's revamp it.
Christoph Conrads : > The CoC is a political document: > https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432 And there is no level on which this is anything but bad. The kernel devs are a very large, very diverse, multi-national, multi-cultural group. We have nothing to gain by getting entangled with political culture wars, and everything to lose. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own.
On holy wars, and a plea for peace
y functional glue only for small groups at the margins of society; minority regious groups are the best-studied case. The larger and more varied your group is, the more penalty there is for trying to be too normative. What we have now is a situation in which a subgroup within the Linux kernel's subculture threatens destructive revolt because not only do they think the slider been pushed too high in a normative direction, but because they think the CoC is an attempt to change the group's telos. The first important thing to get is that this revolt is not really about any of the surface issues the CoC was written to address. It would be maximally unhelpful to accuse the anti-CoC people of being pro-sexism, or anti-minority, or whatever. Doing that can only inflame their sense that the group telos is being hijacked. They make it clear; they signed on to participate in a meritocracy with reputation rewards, and they think that is being taken way from them. One way to process this complaint is to assert that the CoC's new concerns are so important that the anti-CoC faction can be and should be fought to the point where they withdraw or surrender. The trouble with this way of responding is that it *is* in fact a hijacking of the group's telos - an assertion that we ought to have new terminal values replacing old ones that the objectors think they're defending. So a really major question here is: what is the telos of this subculture? Does the new CoC express it? Have the objectors expressed it? The question *not* to get hung up on is what any individual's choice in this matter says about their attitude towards, say, historically underepresented minorities. It is perfectly consistent to be pro-tolerance and pro-inclusion while believing *this* subculture ought to be all about producing good code without regard to who is offended by the process. Not every kind of good work has to be done everywhere. Nobody demands that social-justice causes demonstrate their ability to write C. That last paragraph may sound like I have strayed from neutrality into making a value claim, but not really. It's just another way of saying that different groups have different teloi, and different ethoi proceeding from them. Generally speaking (that is, unless it commits actual crimes) you can only judge a group by how it fulfills its own telos, not those of others. So we come back to two questions: 1. What is our telos? 2. Given our telos, do we have the most inclusive (least normative) ethos possible to achieve it? When you have an answer to that question, you will know what we need to do about the CoC and the "killswitch" revolt. -- http://www.catb.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. -- Thomas Jefferson, letter to Abigail Adams, 1787
Re: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse <[EMAIL PROTECTED]>:
> Upon further investigation, it seems I was mistaken. I apologise for my tone.
Accepted. I wish more people had the grace you do, to apologize when you know
you've been mistaken or unfair; it would make this list a better place.
> Momenco Ocelot boot flash device
> CONFIG_MTD_OCELOT
> This enables access routines for the boot flash device and for the
> NVRAM on the Momenco Ocelot board. If you have one of these boards
> and would like access to either of these, say 'Y'.
Incorporated. I have also received mail from someone who can fill in the
new MIPS entries, so initial results from the posting are quite good.
--
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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
Steven J. Hill <[EMAIL PROTECTED]>: > I can fill in the blanks on all of these for you. I won't clutter > up the mailing list with the complete descriptions. That would be excellent. Please do! -- 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. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Cross-reference analysis reveals problems in 2.4.6pre9
David Woodhouse <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] said:
> > According to my cross-reference generator, the following symbols have
> > missing help in 2.4.6-pre9:
>
> Please fix your cross-reference generator as previously discussed before
> posting these lists again.
I put the symbols we discussed previously on my ignore list. What's
your beef this time?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The saddest life is that of a political aspirant under democracy. His
failure is ignominious and his success is disgraceful.
-- H.L. Mencken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cross-reference analysis reveals problems in 2.4.6pre9
According to my cross-reference generator, the following symbols have missing help in 2.4.6-pre9: CONFIG_AU1000_UART CONFIG_BLUEZ_L2CAP CONFIG_DDB5477 CONFIG_EVB_PCI1 CONFIG_FORWARD_KEYBOARD CONFIG_GDB_CONSOLE CONFIG_HD64465_IOBASE CONFIG_IT8172_REVC CONFIG_IT8172_SCR0 CONFIG_IT8172_SCR1 CONFIG_LL_DEBUG CONFIG_MAPLE CONFIG_MAPLE_KEYBOARD CONFIG_MAPLE_MOUSE CONFIG_MIDI_VIA82CXXX CONFIG_MIPS_EV64120 CONFIG_MIPS_EV96100 CONFIG_MIPS_ITE8172 CONFIG_MIPS_IVR CONFIG_MIPS_PB1000 CONFIG_MIPS_UNCACHED CONFIG_MTD_OCELOT CONFIG_NINO CONFIG_NINO_16MB CONFIG_NINO_4MB CONFIG_NINO_8MB CONFIG_ORION CONFIG_SH_7751_SOLUTION_ENGINE CONFIG_ST40_LMI_MEMORY CONFIG_SYSCLK_100 CONFIG_SYSCLK_75 CONFIG_SYSCLK_83 CONFIG_TULIP_MMIO This list exposes a couple of problems: 1. CONFIG_ORION has been removed from the main MIPS config.in but is still referenced in drivers/net/config.in. 2. The MIPS config.in sets CONFIG_AU1000 but does not reference it, then references CONFIG_AU1000_UART without ever setting it. This probably indicates that one of these is a mistake. I have already written help entries for three other symbols CONFIG_DDB5477, CONFIG_QTRONIX_KEYBOARD, and CONFIG_AGP_SWORKS. Would responsible maintainers please supply help entries for the above? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "Boys who own legal firearms have much lower rates of delinquency and drug use and are even slightly less delinquent than nonowners of guns." -- U.S. Department of Justice, National Institute of Justice, Office of Juvenile Justice and Delinquency Prevention, NCJ-143454, "Urban Delinquency and Substance Abuse," August 1995. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing help entries in 2.4.6pre5
Nicolas Pitre <[EMAIL PROTECTED]>: > > CONFIG_XSCALE_IQ80310 > > 1- This symbol is mine; > 2- It is part of 2.4.6-pre5 only as a dependency argument, with no >point where a value is actually assigned to it; > 3- It is likely to be different when the actual question for which the >user need an help text is merged into the mainline kernel. > > So you can safely ignore it for now. I've put it on my ignore list. > Maybe it could be a good thing for your tool to ignore missing help text for > symbols that don't get enabled interactively by the user? It already does that for derivations (in CML1, define_*). The real problem here is that my report generators aren't smart enough to tell when a CML1 symbol is referenced in a CML1 config but never set. That problem could be solved, but it's unusual that I don't think it's worth the effort. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Controversy over dynamic linking -- how to end the panic
Andrew Pimlott <[EMAIL PROTECTED]>:
> On Thu, Jun 21, 2001 at 03:17:16PM -0400, Eric S. Raymond wrote:
> > IANAL, but I believe that Linus's position as anthology copyright holder
> > makes him privileged in this respect.
>
> Regardless of what you find in the books, recall that Linus has
> stated that decentralizing the copyright of Linux was a goal, so you
> may not find him willing to claim an "anthology copyright" (if such
> a thing even applies to the kernel, which in my NAL opinion, it does
> not).
Linus *is*, however, implicitly claiming the authority to make license
policy on behalf of the other copyright holders in cases where the GPL
is unclear.
In COPYING, Linus says that that the version of GPL applying to the
kernel is v2 unless explicitly otherwise stated. He has also already
issued the interpretation that normal system calls from userland do
not create a derivation relationship.
I consider Linus to have the moral right to make these decisions, whether
or not the law gives him a formal legal right to do so. All I have done
is propose that he be more explicit about his policy in order to prevent
needless confusion and nervousness.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The possession of arms by the people is the ultimate warrant
that government governs only with the consent of the governed.
-- Jeff Snyder
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Missing help entries in 2.4.6pre5
Russell King <[EMAIL PROTECTED]>:
> On Thu, Jun 21, 2001 at 03:49:34PM -0400, Eric S. Raymond wrote:
> > CONFIG_XSCALE_IQ80310
>
> I think we've covered this one before.
Yes. But if I don't ask, I won't ncessarily know when it changes status.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The danger (where there is any) from armed citizens, is only to the
*government*, not to *society*; and as long as they have nothing to
revenge in the government (which they cannot have while it is in their
own hands) there are many advantages in their being accustomed to the
use of arms, and no possible disadvantage.
-- Joel Barlow, "Advice to the Privileged Orders", 1792-93
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Controversy over dynamic linking -- how to end the panic
Alan Cox <[EMAIL PROTECTED]>:
> > >As copyright holder of the Linux kernel, Linus is the only person with
> > >standing to sue for license violation. Therefore, when he says
>
> He's copyright holder of parts of it. The FSF is also a copyright holder of
> oddments, as are many people.
IANAL, but I believe that Linus's position as anthology copyright holder
makes him privileged in this respect.
My wife, who *is* an attorney, will be researching this.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
If gun laws in fact worked, the sponsors of this type of legislation
should have no difficulty drawing upon long lists of examples of
criminal acts reduced by such legislation. That they cannot do so
after a century and a half of trying -- that they must sweep under the
rug the southern attempts at gun control in the 1870-1910 period, the
northeastern attempts in the 1920-1939 period, the attempts at both
Federal and State levels in 1965-1976 -- establishes the repeated,
complete and inevitable failure of gun laws to control serious crime.
-- Senator Orrin Hatch, in a 1982 Senate Report
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Controversy over dynamic linking -- how to end the panic
As you know, there's been another flap recently about the GPL status of loadable kernel modules. You have a note that touches on this in the kernel COPYING file, but it is not sufficient to resolve the questions that keep coming up. Earlier today I was contacted by a principal at a well-known Linux company who was in a mild panic over recent arguments by Alan Cox and David Miller. This company (not VA or Red Hat, BTW) fears that their customers will run from Linux if they get the idea that linking drivers to the kernel might force them open. I wrote back as follows: >Alan's posting beginning "Linus opinion on this is irrelevant" is not a >`perspective' that he can be argued out of. He is not arguing about whether >allowing proprietary binary modules is good, bad, or indifferent. > >Alan is merely stating legal facts as he understands them -- and, in >fact, I agree with his assessment. The key question is whether the >particular kind of linking involved with loading binary modules >propagates derivative-work status under copyright law. This is a legal >question a court may rule on someday. Until one does, anyone who >relies on such linking is taking a legal risk. > >Alan is not quite right that Linus's opinion is irrelevant. It is irrelevant >to the underlying legal question, but not to the associated business risk. > >As copyright holder of the Linux kernel, Linus is the only person with >standing to sue for license violation. Therefore, when he says >"binary modules are OK", he is stating a policy intention which your >customers may include in their evaluation of legal risk. This means >that in order for them to lose, a court must rule that module linking >propagates derivative-work status *and* Linus must reverse himself and >sue. So I'm proposing a solution. We can't resolve the underlying legal question yet, but you can make your policy clearer. In the existing kernel COPYING file: > NOTE! This copyright does *not* cover user programs that use kernel > services by normal system calls - this is merely considered normal use > of the kernel, and does *not* fall under the heading of "derived work". > Also note that the GPL below is copyrighted by the Free Software > Foundation, but the instance of code that it refers to (the Linux > kernel) is copyrighted by me and others who actually wrote it. I suggest replacing this with something resembling the following: The GPL license reproduced below is copyrighted by the Free Software Foundation, but the Linux kernel is copyrighted by me and others who actually wrote it. The GPL license requires that derivative works of the Linux kernel also fall under GPL terms, including the requirement to disclose source. The meaning of "derivative work" has been well established for traditional media, and those precedents can be applied to inclusion of source code in a straightforward way. But as of mid-2001, neither case nor statute law has yet settled under what circumstances *binary* linkage of code to a kernel makes that code a derivative work of the kernel. To calm down the lawyers, I as the principal kernel maintainer and anthology copyright holder on the code am therefore adding the following interpretations to the kernel license: 1. Userland programs which request kernel services via normal system calls *are not* to be considered derivative works of the kernel. 2. A driver or other kernel component which is statically linked to the kernel *is* to be considered a derivative work. 3. A kernel module loaded at runtime, after kernel build, *is not* to be considered a derivative work. These terms are to be considered part of the kernel license, applying to all code included in the kernel distribution. They define your rights to use the code in *this* distribution, however any future court may rule on the underlying legal question and regardless of how the license or interpretations attached to future distributions may change. I believe this would express the present policy clearly enough to soothe jittery nerves at a lot of companies that are worried about this issue. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Government: If you refuse to pay unjust taxes, your property will be confiscated. If you attempt to defend your property, you will be arrested. If you resist arrest, you will be clubbed. If you defend yourself against clubbing, you will be shot dead. These procedures are known as the Rule of Law. -- Edward Abbey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel configuration. It's not just a job, it's an adventure!
-- set numeric or string; follow with symbol and value. load -- read in a configuration (follow with the filename). save -- save the configuration (follow with a filename). xyzzy -- toggle suppression flag. quit -- quit, discarding changes. exit -- exit, saving the configuration. You can move in compass directions n,e,w,s,ne,nw,se,sw or dn for down. > quit -- http://www.tuxedo.org/~esr/";>Eric S. Raymond What, then is law [government]? It is the collective organization of the individual right to lawful defense." -- Frederic Bastiat, "The Law" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
Arjan van de Ven <[EMAIL PROTECTED]>: > > Linux Kernel v2.4.5-ac5 Configuration > > CML1 > > > > Bottom of IDE, ATA and ATAPI Block devices; > > > > < > Support Promise software RAID (NEW) -> Help > > There is no help available for this kernel option. > > How about > "Say "Y" or "M" if you have a Promise Fasttrak (tm) Raid controller > and want linux to use the softwarraid feature of this card. > This driver uses /dev/ataraid/dXpY (X and Y numbers) as device names. > > If you have a Promise Fasttrak(tm) card but do not use the BIOS provided > raid feature, say "N". Um, tell me what the symbol name and prompt for this is, please? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond [President Clinton] boasts about 186,000 people denied firearms under the Brady Law rules. The Brady Law has been in force for three years. In that time, they have prosecuted seven people and put three of them in prison. You know, the President has entertained more felons than that at fundraising coffees in the White House, for Pete's sake." -- Charlton Heston, FOX News Sunday, 18 May 1997 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
José Luis Domingo López <[EMAIL PROTECTED]>: > Would it be great to have a similar documentation for those hundreds of > "files" under /proc ?. Yes, this would be wonderful. Are you volunteering to write it? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Configure.help is complete
It gives me great pleasure to announce that the Configure.help master file is now complete with respect to 2.4.5. Every single one of the 2699 configuration symbols actually used in the 2.4.5 codebase's C source files or Makefiles now has an entry in Configure.help. This does not, of course, mean the job of maintaining Configure.help is done; symbols will be added and dropped in the future (there are a handful of new ones in ac5, all now documented), and some existing entries could stand to be rewritten and expanded. But we have passed a milestone -- maintainance will now be a matter of keeping the boat bailed rather than trying to ignore a hole in the side. Thanks to all the contributors who helped put together the over 550 entries necessary to catch up, too many to name here. The result is available at: http://www.tuxedo.org/~esr/cml2/Configure.help.gz Though carried on the CML2 project page, it can be used with CML1 and is current with respect to both Linus's tree and Alan's. I now have two requests of Linus and Alan: 1. Please pick up this work now. It is a really substantial improvement on what you have in your trees, incorporating it cannot break anything, and you'll help prevent unnecessary hassles due to clashing patches in the future. 2. Please make a policy of rejecting patches that add new configuration symbols without also adding an explanatory Configure.help entry -- and please *announce* that you will do so. We can raise our standards now, and for the sake of having a well-documentated kernel and configuration system I submit that we ought to. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Only 5 undocumented configuration symbols left
The current list of symbols with missing help is very short. Here it is: PPC port: CONFIG_BLK_DEV_MPC8xx_IDE CONFIG_IRQ_ALL_CPUS CONFIG_USE_MDIO CRIS port: CONFIG_ETRAX_FLASH_BUSWIDTH CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C Let's finish this off, people! -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The people cannot delegate to government the power to do anything which would be unlawful for them to do themselves. -- John Locke, "A Treatise Concerning Civil Government" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Remaining undocumented Configure.help symbols
Harald Welte <[EMAIL PROTECTED]>: > On Tue, May 29, 2001 at 02:59:40PM -0400, Eric S. Raymond wrote: > > > CONFIG_NET_CLS_TCINDEX > > If you say Y here, you will be able to classify outgoing packets > according to the tc_index field of the skb. You will want this > feature if you want to implement Differentiates Services useing > sch_dsmark. If unsure, say Y. > > This code is also available as a module called cls_tcindex.o ( = code > which can be inserted in and removed from the running kernel > whenever you want). If you want to compile it as a module, say MM > here and read Documentation/modules.txt Looks good. > > CONFIG_NET_SCH_INGRESS > > If you say Y here, you will be able to police incoming bandwidth > and drop packets when this bandwidth exceeds your desired rate. > If unsure, say Y. > > This code is also available as a module called cls_tcindex.o ( = code > which can be inserted in and removed from the running kernel > whenever you want). If you want to compile it as a module, say MM > here and read Documentation/modules.txt I'm going to assume that the cls_tcindex.o in the second entry is a cut'n'paste error and should read sch_ingress.o. Should the CLS_POLICE entry, then, read like this? Traffic policing (needed for in/egress) CONFIG_NET_CLS_POLICE Say Y to support traffic policing (bandwidth limits). Needed for ingress and egress rate limiting. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond A ``decay in the social contract'' is detectable; there is a growing feeling, particularly among middle-income taxpayers, that they are not getting back, from society and government, their money's worth for taxes paid. The tendency is for taxpayers to try to take more control of their finances .. -- IRS Strategic Plan, (May 1984) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Remaining undocumented Configure.help symbols
With the help of a number of contributors, Steven Cole and I have managed to cut the list of undocumented configuration symbols from the previous 55 to 10. The three *_NET_SCH_* symbols that didn't appear in the previous listing have popped up because my cross-referencer was fooled by some old comments in Configure.help. Networking: CONFIG_NET_CLS_POLICE CONFIG_NET_CLS_TCINDEX CONFIG_NET_SCH_INGRESS ARM port: CONFIG_SA1100_SHERMAN PPC port: CONFIG_EST8260 CONFIG_BLK_DEV_MPC8xx_IDE CONFIG_IRQ_ALL_CPUS CONFIG_USE_MDIO CRIS port: CONFIG_ETRAX_FLASH_BUSWIDTH CONFIG_ETRAX_I2C_USES_PB_NOT_PB_I2C As before, if you know enough about any of these configuration options to write a help entry, please send it to me. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond 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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Configure.help entries wanted
Philip Blundell <[EMAIL PROTECTED]>: > >CONFIG_ARCH_FTVPCI > >CONFIG_ARCH_NEXUSPCI > > These symbols both refer to the same thing (the latter is an obsolete name). > I guess appropriate text would be something like: > > Say Y here if you intend to run this kernel on a FutureTV (nee Nexus > Electronics) StrongARM PCI card. Hm. They're both in active use in 2.4.5pre4. My cross-referencer shows CONFIG_ARCH_NEXUSPCI: arch/arm/config.in arch/arm/boot/Makefile arch/arm/kernel/entry-armv.S arch/arm/kernel/arch.c snark:~/src/linux$ scripts/kxref.py -f "o&~h&~x" -n defconfig | grep FTVPCI Reading cross-reference database...done. CONFIG_ARCH_FTVPCI: arch/arm/Makefile arch/arm/config.in arch/arm/boot/compressed/Makefile arch/arm/kernel/Makefile arch/arm/kernel/bios32.c arch/arm/kernel/debug-armv.S arch/arm/def-configs/clps7500 arch/arm/def-configs/shark On further investigation I find that neither of these symbols is actually set in the ARM config file! This is kind of a mess. Is it going to be fixed in the next merge? (They're not the only dead symbols. CONFIG_TBOX and CONFIG_SHARK don't have associated questions either.) -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Courage is resistance of fear, mastery of fear, not absence of fear. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help entries wanted
Keith Owens <[EMAIL PROTECTED]>: > I claim my erudition prize (do I get steak knives with that?). Results doubtful. Consult Magic 8-Ball again :-). I'm going to critique these individually pour encourager les autres. > +Disable IA-64 Virtual Hash Page Table > +CONFIG_DISABLE_VHPT > + The Virtual Hash Page Table (VHPT) enhances virtual address > + translation performance. Normally you want the VHPT active but you > + can select this option to disable the VHPT for debugging. If you're > + unsure, answer N. Excellent! Second sentence a good example of motivation. > +McKinley A-step specific code > +CONFIG_MCKINLEY_ASTEP_SPECIFIC > + Select this option to build a kernel for an IA64 McKinley system > + with any A-stepping CPU. > + > +McKinley A0/A1-step specific code > +CONFIG_MCKINLEY_A0_SPECIFIC > + Select this option to build a kernel for an IA64 McKinley system > + with an A0 or A1 stepping CPU. Ah, now I could have written these. What I was hoping for was extra information analogous to what's in these: Enable Itanium B-step specific code CONFIG_ITANIUM_BSTEP_SPECIFIC Select this option to build a kernel for an Itanium prototype system with a B-step CPU. You have a B-step CPU if the "revision" field in /proc/cpuinfo has a value in the range from 1 to 4. Enable Itanium B0-step specific code CONFIG_ITANIUM_B0_SPECIFIC Select this option to build a kernel for an Itanium prototype system with a B0-step CPU. You have a B0-step CPU if the "revision" field in /proc/cpuinfo is 1. Is there a value range in /proc/cpuinfo that tells you you have an A/A0 step? > +IA64 compare-and-exchange bug checking > +CONFIG_IA64_DEBUG_CMPXCHG > + Selecting this option turns on bug checking for the IA64 > + compare-and-exchange instructions. This is slow! If you're unsure, > + select N. > + > +IA64 IRQ bug checking > +CONFIG_IA64_DEBUG_IRQ > + Selecting this option turns on bug checking for the IA64 irq_save and > + restore instructions. This is slow! If you're unsure, select N. These would be much improved by some indication of what IA64 variants or mask steppings have these problems. > +IA64 Early printk support > +CONFIG_IA64_EARLY_PRINTK > + Selecting this option uses the VGA screen for printk() output before > + the consoles are initialised. It is useful for debugging problems > + early in the boot process, but only if you have a VGA screen > + attached. If you're unsure, select N. Good! > +IA64 Print Hazards > +CONFIG_IA64_PRINT_HAZARDS > + Selecting this option prints more information for Illegal Dependency > + Faults, that is, for Read after Write, Write after Write or Write > + after Read violations. This option is ignored if you are compiling > + for an Itanium A step processor (CONFIG_ITANIUM_ASTEP_SPECIFIC). If > + you're unsure, select Y. Excellent! This is a fine start. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "If I must write the truth, I am disposed to avoid every assembly of bishops; for of no synod have I seen a profitable end, but rather an addition to than a diminution of evils; for the love of strife and the thirst for superiority are beyond the power of words to express." -- Father Gregory Nazianzen, 381 AD - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
What's up with GT96100 in the MIPS config file?
Near line 55 of drivers/net/Config.in there is code that reads like this: if [ "$CONFIG_MIPS_GT96100" = "y" ]; then bool ' MIPS GT96100 Ethernet support' CONFIG_MIPS_GT96100ETH fi All very well except that CONFIG_MIPS_GT96100 is never set (or even used) anywhere else. My cross-reference generator shows this: snark:~/src/linux$ scripts/kxref.py | grep GT96 CONFIG_MIPS_GT96100: drivers/net/Config.in CONFIG_MIPS_GT96100ETH: drivers/net/Makefile drivers/net/Config.in drivers/net/gt96100eth.c The simplest guess is that the guard part is just wrong. Can anybody shed any light on this? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The saddest life is that of a political aspirant under democracy. His failure is ignominious and his success is disgraceful. -- H.L. Mencken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > I'm going to assume for now that CML2 saves two files - one storing a > relatively small number of symbols (which is strictly limited to those > explicitly set by the user), and one containing the full set for > consumption by the Makefiles. No, that's not the case. Would it be too much to ask that you learn how the existing language works brfore proposing improvements? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
Urban Widmark <[EMAIL PROTECTED]>:
> What happened with the discussion on configurable colors in make
> menuconfig? Darkblue on black as frozen options get isn't exactly optimal
> ... at least not for my eyes. Being next to a bold, white text doesn't
> help either.
Nobody could come up with a way to support configurable colors that didn't seem
like way more trouble than it was worth.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
"...quemadmodum gladius neminem occidit, occidentis telum est."
[...a sword never kills anybody; it's a tool in the killer's hand.]
-- (Lucius Annaeus) Seneca "the Younger" (ca. 4 BC-65 AD),
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Dead symbols in CMl1
I think I've identified a number of dead symbols. Here's a list: CONFIG_BAGETBSM (Baget Backplane Shared Memory support) Set in arch/mips64/config.in, not used anywhere. CONFIG_ACPI_INTERPRETER (ACPI interpreter) Set in arch/ia64/config.in, not used anywhere. CONFIG_BINFMT_JAVA (Kernel support for JAVA binaries) Set in arch/parisc/config.in and arch/cris/config.in, not used anywhere. CONFIG_SCSI_DECSII (DEC SII SCSI Driver) Set in drivers/scsi/Config.in, not used anywhere. CONFIG_PROFILE (Enable traffic profiling) CONFIG_PROFILE_SHIFT (Profile shift count) Set in arch/cris/config.in, not used anywhere. CONFIG_SERIAL_21285_OLD (Use /dev/ttyS0 device) Set in drivers/char/Config.in, not used anywhere The following patch removes them cleanly: Diffs between last version checked in and current workfile(s): --- arch/cris/config.in 2001/05/22 00:55:28 1.1 +++ arch/cris/config.in 2001/05/22 00:56:22 @@ -20,9 +20,6 @@ bool 'System V IPC' CONFIG_SYSVIPC tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA -fi bool 'Use kernel gdb debugger' CONFIG_ETRAX_KGDB @@ -232,8 +229,4 @@ comment 'Kernel hacking' #bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC -bool 'Kernel profiling support' CONFIG_PROFILE -if [ "$CONFIG_PROFILE" = "y" ]; then - int ' Profile shift count' CONFIG_PROFILE_SHIFT 2 -fi endmenu --- arch/ia64/config.in 2001/05/22 00:51:05 1.1 +++ arch/ia64/config.in 2001/05/22 00:51:26 @@ -89,7 +89,6 @@ if [ "$CONFIG_ACPI_KERNEL_CONFIG" = "y" ]; then define_bool CONFIG_PM y define_bool CONFIG_ACPI y - define_bool CONFIG_ACPI_INTERPRETER y fi fi --- arch/mips64/config.in 2001/05/22 00:50:33 1.1 +++ arch/mips64/config.in 2001/05/22 00:50:44 @@ -183,7 +183,6 @@ fi if [ "$CONFIG_BAGET_MIPS" = "y" ]; then tristate 'Baget AMD LANCE support' CONFIG_BAGETLANCE -tristate 'Baget Backplane Shared Memory support' CONFIG_BAGETBSM fi if [ "$CONFIG_ATM" = "y" ]; then source drivers/atm/Config.in --- arch/parisc/config.in 2001/05/22 00:55:04 1.1 +++ arch/parisc/config.in 2001/05/22 00:55:14 @@ -68,9 +68,6 @@ tristate 'Kernel support for SOM binaries' CONFIG_BINFMT_SOM tristate 'Kernel support for ELF binaries' CONFIG_BINFMT_ELF tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC -if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then - tristate 'Kernel support for JAVA binaries (obsolete)' CONFIG_BINFMT_JAVA -fi endmenu --- drivers/char/Config.in 2001/05/22 00:56:44 1.1 +++ drivers/char/Config.in 2001/05/22 00:56:56 @@ -63,9 +63,6 @@ if [ "$CONFIG_FOOTBRIDGE" = "y" ]; then bool 'DC21285 serial port support' CONFIG_SERIAL_21285 if [ "$CONFIG_SERIAL_21285" = "y" ]; then - if [ "$CONFIG_OBSOLETE" = "y" ]; then - bool ' Use /dev/ttyS0 device (OBSOLETE)' CONFIG_SERIAL_21285_OLD - fi bool ' Console on DC21285 serial port' CONFIG_SERIAL_21285_CONSOLE fi fi --- drivers/scsi/Config.in 2001/05/22 00:55:54 1.1 +++ drivers/scsi/Config.in 2001/05/22 00:56:01 @@ -39,7 +39,6 @@ if [ "$CONFIG_TC" = "y" ]; then dep_tristate 'DEC NCR53C94 Scsi Driver' CONFIG_SCSI_DECNCR $CONFIG_SCSI fi - dep_tristate 'DEC SII Scsi Driver' CONFIG_SCSI_DECSII $CONFIG_SCSI fi if [ "$CONFIG_PCI" = "y" ]; then End of diffs. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Hoplophobia (n.): The irrational fear of weapons, correctly described by Freud as "a sign of emotional and sexual immaturity". Hoplophobia, like homophobia, is a displacement symptom; hoplophobes fear their own "forbidden" feelings and urges to commit violence. This would be harmless, except that they project these feelings onto others. The sequelae of this neurosis include irrational and dangerous behaviors such as passing "gun-control" laws and trashing the Constitution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
[EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Speaking from the perspective of a user of the CML tools, rather > than as a developer, all I've been trying to say is this: When I > type "make menuconfig" or "make oldconfig" in the future, I want to > see the same interface and the same results that I've always seen, > because it's always worked for me in the past. Visual details will differ, but I've been careful about maintaining functional compatibility. There was a phase of the development during which I was mostly processing feature requests from people who wanted features of the old system that I had not properly understood (such as the NEW tag). That phase ended almost a month ago. Nobody who has actually tried the CML2 tools more recently has reported that the UI changes present any difficulty. CML2 drops its configuration results in the same place, in the same formats, as CML1. So you should in fact be able to type `make menuconfig' and `make oldconfig' with good results. Have you actually tried this? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The right of the citizens to keep and bear arms has justly been considered as the palladium of the liberties of a republic; since it offers a strong moral check against usurpation and arbitrary power of rulers; and will generally, even if these are successful in the first instance, enable the people to resist and triumph over them." -- Supreme Court Justice Joseph Story of the John Marshall Court - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Brent D. Norris <[EMAIL PROTECTED]>: > didn't Eric say that this has stalled though? Is that not the case? Nope. Greg is still working. He got the first version of the theorem prover working recently. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond A wise and frugal government, which shall restrain men from injuring one another, which shall leave them otherwise free to regulate their own pursuits of industry and improvement, and shall not take from the mouth of labor the bread it has earned. This is the sum of good government, and all that is necessary to close the circle of our felicities. -- Thomas Jefferson, in his 1801 inaugural address - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Tom Rini <[EMAIL PROTECTED]>: > python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script > uses undocumented things which did work in python1.5.x. That's true of the core language. The reason I moved to 2.0 was that there are library changes in 2.0 that enabled me to to cut CML2's in-kernel footprint substantially. > Which brings up another point, RedHat (7.1?) and Debian/woody both have the > option of having python2 around. Anyone know about mandrake? My point is > that some dists are already dealing with python2. Yes. By the time 2.5 forks, distros covering an estimated 85% of the market will carry python2 binaries which the CML2 install script will find automatically. By the time 2.6 forks, we're going to laugh if we ever remember that we thought this was an issue. > Eric, would it be easy/possible to go back to requiring python 1.5.x for > CML2, since that is what many dists ship with? It wouldn't be too difficult. But it would make the code heavier, and I'm not clear that it would make anybody happy who isn't already willing to deal with the design concept. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The world is filled with violence. Because criminals carry guns, we decent law-abiding citizens should also have guns. Otherwise they will win and the decent people will lose. -- James Earl Jones - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Because it is evidently confusing the issue. Perhaps because it sounds like > you were intending to feed Linus large patches for 2.5.[12] which effect > _both_ changes. I'm going to give Linus the same installation kit the people working with CML2 have now. That will include both the CML2 engine and the rulesfiles. > Have patience - let the less contentious part of CML2 go in first, and then > we can deal with the other stuff later, once CML2 has been accepted (however > grudgingly in some cases) by developers. I don't think there is a "less contentious" part. The same people who bitched about the engine are now bitching about the changes I'm contemplating in the rulesfiles. It seems clear to me that their attitude, in general, has little to do with technical specifics of the engine or rulesets and everything to do with resistance to change in general and fear of losing control and/or hard-won implicit knowledge about the old system. I can sympathize with their upset, but I don't intend to let it stop me. And since I'm going to have these people angry at me unless I give up entirely, I figure I have little to lose by steaming ahead full. > > The engine is working. Why is it not yet time to discuss ruleset design > > and modes? > > For a man who claims to hack social systems, that's an incredibly naïve > question. You think so, eh? Heh. Experience has taught me that sometimes hacking social systems requires a certain amount of sheer bloodymindedness. See, I've already written off the chronic bellyachers. Since I can't please them without scrapping the whole plan, I'm going to ignore them. In particular, anybody who repeated "fsck Python..." after Linus ruled that Python is not an issue and Greg Banks announced the C implementation of CML2 has got a sufficiently severe case of rectocranial insertion that they've defined themselves out of the conversation. Instead I'll take my cues from people like you and Ray Knight and Tom Rini and Alan Cox and Martin Schwidefsky who are actually offering help and constructive criticism. (Arjan de Ven is trying but he's not up to speed on the language yet.) I trust you've noticed by now that I *do* listen very carefully in that situation, and I follow up with questions when I'm not sure what people are trying to tell me. I'll keep doing that. Eventually the bellyachers may get a message about what kind of behavior gains them influence and what kind loses them influence. That's a social-systems hack of a sort ;-). -- http://www.tuxedo.org/~esr/";>Eric S. Raymond I don't like the idea that the police department seems bent on keeping a pool of unarmed victims available for the predations of the criminal class. -- David Mohler, 1989, on being denied a carry permit in NYC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > Let's not talk about CONFIG_AUNT_TILLIE any more, or change the existing > behaviour of config options to make that the default, until we've settled > the discussion about CML2. What discussion is that? Unless Linus has changed his mind and I don't know about it, CML2 is going in between 2.5.1 and 2.5.2. The engine is working. Why is it not yet time to discuss ruleset design and modes? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond That the said Constitution shall never be construed to authorize Congress to infringe the just liberty of the press or the rights of conscience; or to prevent the people of the United states who are peaceable citizens from keeping their own arms... -- Samuel Adams, in "Phila. Independent Gazetteer", August 20, 1789 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
David Woodhouse <[EMAIL PROTECTED]>: > I think you already have the mechanism required to answer this - in NOVICE > mode you disallow the strange choices, in EXPERT mode you allow them. That pushes the third button. I'm nervous that if we go down this path we will end up with a thicket of modes and a combinatorial explosion in ruleset complexity, leading immediately to a user configuration experience that is more complex than necessary, and eventually to an unmaintainable mess in the rulesfiles. In order to prevent that happening, I would like to have some recognized criterion for configuration cases that are so perverse that it is a net loss to accept the additional complexity of handling them within the configurator. A lot of people (including, apparently, you) are saying there are no such cases. I wonder if you'll change your minds when you have to handle the overhead yourselves? Sigh... -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action." -- George Washington, in a speech of January 7, 1790 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Background to the argument about CML2 design philosophy
Jonathan Morton <[EMAIL PROTECTED]>: > One caveat though - not all Macs have SCSI controllers, and not all that do > even have one of the two standard ones. I know. But these derivations are only for the old 68K macs, which don't have PCI. Closed issue. > >3. The MVME derivations are correct *if* (and only if) you agree to ignore > >the possibility that somebody could want to ignore the onboard hardware, > >plug outboard disk or Ethernet cards into the VME-bus connector, and > >do something like running SCSI-over-ATAPI to the outboard device. > > ...and then someone else mentioned the possibility of f*x0r3d hardware. In > this case, I would say this *isn't* a kernel-configuration issue but one of > being able to disable the drivers for the malfunctioning hardware. But the other side is going to ask: suppose you're memory-limited (quite likely on older SBCs) and don't want to pay the core cost of drivers you won't use? I don't really think we can duck this question by talking about boot-time parameters. > I think the MVME derivations are *perfectly* sensible - if the reference > board and most (read: virtually all) derivatives have those features, turn > them on by all means. That's my gut feeling, too. But a lot of people insist that the only right way is totally fine-grained control, even in weird edge cases like this one. > To satisfy some others, you might want to say "Hey, > these guys might want to *explicitly turn off* some of this stuff" - so > provide an option under "Are you insane?" which presents all the "derived" > symbols and allows the hackers to manually turn stuff off. Interesting thought... -- http://www.tuxedo.org/~esr/";>Eric S. Raymond I cannot undertake to lay my finger on that article of the Constitution which grant[s] a right to Congress of expending, on objects of benevolence, the money of their constituents. -- James Madison, 1794 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Background to the argument about CML2 design philosophy
r going to hook an outboard device to one of these puppies again is if some hacker pulls a dusty one off a shelf for some garage project. So the real question here is whether it is ever acceptable to say that a possible configuration is just silly and ruleset will ignore it, in order to hold down ruleset complexity and simplify the user experience. The cost of deciding that the answer to that question is "yes, sometimes" is that on rare occasions like this one you might have to haul out a text editor to tweak something in your config. But the cost of deciding that the answer is "no" will be some pretty serious complexity headaches both in the configuration user experience and (down the road) in the maintainability of the ruleset. So far, I have to say I'm disappointed in the quality of the debate. Almoist nobody seems to want to think about this tradeoff globally, as a systems design issue. Instead, I'm hearing a lot of reflexive chuntering that we have to do things a certain way because we've always done them a certain way, and who am I to even dare *think* about raising different possibilities? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond [The disarming of citizens] has a double effect, it palsies the hand and brutalizes the mind: a habitual disuse of physical forces totally destroys the moral [force]; and men lose at once the power of protecting themselves, and of discerning the cause of their oppression. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
David Woodhouse <[EMAIL PROTECTED]>: > On one hand you have dependencies which are present to make life easier for > Aunt Tillie, by refraining from confusing her with strange questions to > which the answer is _probably_ 'no'. Like the question of whether she has > an IDE controller on her MVME board. > > One the other hand, you have the dependencies present in the existing CML1 > configuration, which are _absolute_ dependencies - which specify for example > that you cannot enable support for PCI peripherals if !CONFIG_PCI, etc. > These dependencies are there to prevent you from enabling combinations of > options which are utterly meaningless, and usually won't even compile. There are no `advisory' dependencies in CML2. They're all absolute. What you call an `advisory' dependency would be simulated by having a policy symbol for Aunt Tillie mode and writing constraints like this: require AUNT_TILLIE implies FOO >= BAR This is exactly why the CML2 ruleset has EXPERT, WIZARD, and TUNING policy symbols, as hooks for doing things like this. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond No one who's seen it in action can say the phrase "government help" without either laughing or crying. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
David Woodhouse <[EMAIL PROTECTED]>:
> The dependencies in CML1 are (supposed to
> be) absolute - the 'advisory' dependencies you're adding are arguably a
> useful feature, but please don't make it possible to confuse the two, and
> please do make sure it's possible to disable the latter form.
I don't understand this request. I have no concept of `advisory' dependencies.
What are you talking about? Is my documentation horribly unclear?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
"Both oligarch and tyrant mistrust the people,
and therefore deprive them of arms."
--Aristotle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Brown-paper-bag bug in m68k, sparc, and sparc64 config files
This bug unconditionally disables a configuration question -- and it's so old that it has propagated across three port files, without either of the people who did the cut and paste for the latter two noticing it. This sort of thing would never ship in CML2, because the compiler would throw an undefined-symbol warning on BLK_DEV_ST. The temptation to engage in sarcastic commentary at the expense of people who still think CML2 is an unnecessary pain in the butt is great. But I will restrain myself. This time. --- arch/m68k/config.in 2001/05/19 21:36:57 1.1 +++ arch/m68k/config.in 2001/05/19 21:37:12 @@ -192,7 +192,7 @@ int 'Maximum number of SCSI disks that can be loaded as modules' CONFIG_SD_EXTRA_DEVS 40 fi dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi dep_tristate ' SCSI CD-ROM support' CONFIG_BLK_DEV_SR $CONFIG_SCSI --- arch/sparc/config.in2001/05/19 21:34:54 1.1 +++ arch/sparc/config.in2001/05/19 21:35:21 @@ -162,7 +162,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi --- arch/sparc64/config.in 2001/05/19 21:37:33 1.1 +++ arch/sparc64/config.in 2001/05/19 21:37:45 @@ -146,7 +146,7 @@ dep_tristate ' SCSI tape support' CONFIG_CHR_DEV_ST $CONFIG_SCSI - if [ "$CONFIG_BLK_DEV_ST" != "n" ]; then + if [ "$CONFIG_CHR_DEV_ST" != "n" ]; then int 'Maximum number of SCSI tapes that can be loaded as modules' CONFIG_ST_EXTRA_DEVS 2 fi -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Conservatism is the blind and fear-filled worship of dead radicals. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > Being able to turn CML2 into CML1 might be the more useful exercise. That's...not a completely crazy idea. Hmmm... It might be possible to take a CML2 rulebase and generate a sort of stupid jackleg CML1 translation of it. The resulting config.in would be huge and nasty, and would only work in forward sequence with no side-effect computation, but you just might be able to get the old tools to parse it. Again there's a technical problem with derivations. Probably solvable. But the real question is whether the old tools have enough value to be worth the effort. What problem are you trying to solve here? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond This would be the best of all possible worlds, if there were no religion in it. -- John Adams, in a letter to Thomas Jefferson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>:
> What I am trying to say is that if you can infer probable configuration
> categories that are relevant then instead of automatically filling the other
> areas in and blocking changing them without using vi you can put the other
> options as a submenu. That guides the less expert user and also helps rather
> than hinders the expert
OK, that's useful input. Noted.
There's a bit of a technical problem with the distinction between
derivations (which are like macros) and question symbols (which can
be suppressed or unsuppressed depending on their visibility predicate
But perhaps I can think up a solution to that one over lunch.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
-- Lyndon Johnson, former President of the U.S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > I hereby volunteer to maintain at least make oldconfig and make config, > and perhaps make menuconfig. That's the easy part; the CML1 config code may be ugly and broken, but at least it's relatively stable. What you'd also have to do is maintain an entire CML1 ruleset in parallel with the canonical CML2 one. That's the hard part. I've been keeping the CML2 ruleset synced with CML1 for a year now. It's been an ugly, nasty, horrible job -- *much* nastier, by an order of magnitude, than designing and writing the CML2 engine. Going the other direction would be worse. "Like chewing razor blades" is the simile that leaps to mind. (And no, dropping back to CML1 format for the masters wouldn't be an option; it doesn't have the semantic strength to enable CML2's new capabilities.) -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Michael Meissner <[EMAIL PROTECTED]>:
> On Fri, May 18, 2001 at 06:09:09PM +0200, Christoph Hellwig wrote:
> > Aunt Tillie shouldn't try to manually configure a kernel.
>
> Ummm, maybe Aunt Tillie wants to learn how to configure a kernel After
> all, all of us at one point in time were newbies in terms of configuring
> kernels, etc.
And if she doesn't, maybe her teenage daughter Muffy wants to learn. You know,
the one with the unicorn appliques and the pink scrunchies and the Back Street
Boys posters in her bedroom?
Dammit, if we're serious about empowering people with free software we can't
limit ourselves with the attitude that configuring kernels (or anything
else) is the sacred preserve of a geek elite.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The price of liberty is, always has been, and always will be blood. The person
who is not willing to die for his liberty has already lost it to the first
scoundrel who is willing to risk dying to violate that person's liberty. Are
you free?
-- Andrew Ford
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>:
> Right now, it's now a dropping back. You seem to take for granted that CML2
> and your python2 frontend to it are 2.5.0 material. I don't right now.
Linus is free to change his mind. Perhaps he will. But the last word I heard
from him is that CML2 goes in in the 2.5.1-2.5.2 timeframe. That's the
assumption I'm operating on.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
An armed society is a polite society. Manners are good when one
may have to back up his acts with his life.
-- Robert A. Heinlein, "Beyond This Horizon", 1942
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > In my opinion, no configuration that is actually physically possible > is perverse. Noted. And a very pithy statement of the position. Thanks. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond I do not find in orthodox Christianity one redeeming feature. -- Thomas Jefferson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>:
> > I think you're confusing a couple of different issues here, Alan. Even
> > supposing CML2 could parse CML1 rulesets, the design question about how
> > configuration *should* work (that is, what kind of user experience we
> > want to create and who we optimize ruleset design for) wouldn't go away.
>
> It would. Because people who like the old config would continue to use the
> old tools
Excuse me?
Alan, it sounds very much like you just said something stupid. This
seems sufficiently unlikely that I am shaking my head in disbelief and
fingernailing wax out of both ears (and if you think doing both those
things at once is easy try it sometime :-)).
Do you really believe that anyone is going to maintain the CML1 tools
for as long as a nanosecond after they get dropped out of the kernel tree?
Even supposing somebody were loony enough to do that, how would preserving
an old interface in amber do anything to explore new UI possibilities?
Perhaps I'm just unusually dense this morning.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
Alcohol still kills more people every year than all `illegal' drugs put
together, and Prohibition only made it worse. Oppose the War On Some Drugs!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Jonathan Morton <[EMAIL PROTECTED]>: > Not everyone falls into the "expert user" and "Aunt Tillie" categories. > It's a *very* big grey area. If some semi-computer-literate user (ie. some > friends of mine!) wants to upgrade their kernel so they have access to > newer hardware (such as a cheap USB webcam), it should be made as simple as > possible for them. CML1 doesn't handle that very well, I'd like to see > it's replacement do better. Yes. One of the reasons I keep Aunt Tillie in mind as a UI target is that if I can design a configuration system that makes the task possible for her, then I'll have one that makes it easy for this much larger class of intermediate-level users. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond In the absence of any evidence tending to show that possession or use of a 'shotgun having a barrel of less than eighteen inches in length' at this time has some reasonable relationship to the preservation or efficiency of a well regulated militia, we cannot say that the Second Amendment guarantees the right to keep and bear such an instrument. [...] The Militia comprised all males physically capable of acting in concert for the common defense. -- Majority Supreme Court opinion in "U.S. vs. Miller" (1939) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > > I don't want to do (a); it conflicts with my design objective of > > simplifying configuration enough that Aunt Tillie can do it. I won't > > do that unless I see a strong consensus that it's the only Right Thing. > > Its a good way of getting the defaults right. It may also be an appropriate > way of guiding presentation (eg putting the stuff the ruleset says you wont > have under a subcategory so you would see > > > CPU type > Devices > blah > blah > Other Options > IDE disk > Cardbus I want to understand what you're driving at here and I don't get it. What's the referent of "Its"? Are you saying you think Aunt Tillie's view of the world should guide the presentation of options? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Are we at last brought to such a humiliating and debasing degradation, that we cannot be trusted with arms for our own defence? Where is the difference between having our arms in our own possession and under our own direction, and having them under the management of Congress? If our defence be the *real* object of having those arms, in whose hands can they be trusted with more propriety, or equal safety to us, as in our own hands? -- Patrick Henry, speech of June 9 1788 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > > In general this is the best option, if you create a non-standard > > configuration for machine foo then it is your problem, not everybody > > else's. > > Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets > this whole discussion wouldn't be needed. I think you're confusing a couple of different issues here, Alan. Even supposing CML2 could parse CML1 rulesets, the design question about how configuration *should* work (that is, what kind of user experience we want to create and who we optimize ruleset design for) wouldn't go away. I'm raising these questions now because CML2's capabilities invite thinking about them. But they're independent of the underlying language. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>:
> Don't get me wrong. I'm NOT opposed to having a config tool everyone and
> their aunt can use. I'm opposed to that tool taking away the options expert
> users have to do what they know is right for them.
I'll take that as a vote for (b), to handle even perverse configurations
even if it means adding a lot of complexity to the ruleset.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
...the Federal Judiciary...an irresponsible body, working like gravity
by night and by day, gaining a little today and a little tomorrow, and
advancing its noiseless step like a thief over the field of
jurisdiction until all shall be usurped from the States; and the
government of all be consolidated into one.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Arjan van de Ven <[EMAIL PROTECTED]>: > Aunt Tillie doesn't even know what a kernel is, nor does she want > to. I think it's fair to assume that people who configure and > compile their own kernel (as opposed to using the distribution > supplied ones) know what they are doing. I'd like to break these assumptions. Or at the very least see how far they can be bent. I know this sounds crazy to a lot of hackers, but I think there's a certain amount of unhelpful elitism and self-puffery in the "kernels are hard to configure and they *should* be hard to configure* attitude. Let's give Aunt Tillie a chance to surprise us. > Or at least make something like a "Expert level" question as first > question, so that people who DO know what they are doing can select > the options they want. Already in the plan -- in fact the EXPERT symbol exists in CML2 now. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond It is proper to take alarm at the first experiment on our liberties. We hold this prudent jealousy to be the first duty of citizens and one of the noblest characteristics of the late Revolution. The freemen of America did not wait till usurped power had strengthened itself by exercise and entangled the question in precedents. They saw all the consequences in the principle, and they avoided the consequences by denying the principle. We revere this lesson too much ... to forget it -- James Madison. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.4.5 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.4.5: Fri May 18 02:02:27 EDT 2001 * Rulesfile updated for 2.4.5pre3, 2.4.4ac10. The project page now also includes a download URL for the latest version of the Configure.help file. It features over 340 entries that are missing in the one Linus and Alan are shipping. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "The best we can hope for concerning the people at large is that they be properly armed." -- Alexander Hamilton, The Federalist Papers at 184-188 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Jes Sorensen <[EMAIL PROTECTED]>: > If Ray wants to fix things, it's just fine with me. I have corrected the Mac dependencies as Ray directed. > Eric> Does this mean you'll take over maintaining the CML2 rules files > Eric> for the m68k port, so I don't have to? That would be wonderful. > > For a start, so far there has been no reason whatsoever to change the > format of definitions. The judgment of the kbuild team is unanimous that you are mistaken on this. That's the five people (excluding me) who wrote and maintained the CML1 code. *They* said that code had to go, Linus has concurred with their judgment, and the argument is over. > So far you have only been irritating developers for no reason. What I > asked you to do is to NOT change whatever config options developers > developers felt were necessary to introduce. If you want to change the > format of the config.in files go ahead. Messing around with the config > options themselves is *not* for you to do, nor are you to impose a > more restrictive space for people to work in. If you persist in misunderstanding what I am doing, you are neither going to be able to influence my behavior nor to persuade other people that it is wrong. Listen carefully, please: 1. The CML2 system neither changes the CONFIG_ symbol namespace nor assumes any changes in it. (Earlier versions did, but Greg Banks showed me how to avoid needing to.) 2. The ruleset changes I have made simplify the configuration process, but they do *not* in any way restrict the space of configurations that are possible. By design, every valid (consistent) configuration in CML1 can be generated in CML2. I treat departures from that rule as rulesfile bugs and fix them (as I just did at Ray Knight's instruction). 3. I do not have (nor do I seek) the power to "impose" anything on anyone. You really ought to give CML2 a technical evaluation yourself before you flame me again. Much of what you seem to think you know is not true. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond According to the National Crime Survey administered by the Bureau of the Census and the National Institute of Justice, it was found that only 12 percent of those who use a gun to resist assault are injured, as are 17 percent of those who use a gun to resist robbery. These percentages are 27 and 25 percent, respectively, if they passively comply with the felon's demands. Three times as many were injured if they used other means of resistance. -- G. Kleck, "Policy Lessons from Recent Gun Control Research," - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.4.3 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.4.3: Mon May 14 01:35:07 EDT 2001 * Rulesfile sync with 2.4.5-pre2. It's notable that the configurator codebase has now been unchanged for ten days. It's looking really stable now, all the action is in rulesfile updates and fixes. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Question with boldness even the existence of a God; because, if there be one, he must more approve the homage of reason, than that of blindfolded fear Do not be frightened from this inquiry from any fear of its consequences. If it ends in the belief that there is no God, you will find incitements to virtue in the comfort and pleasantness you feel in its exercise... -- Thomas Jefferson, in a 1787 letter to his nephew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Jes Sorensen <[EMAIL PROTECTED]>: > Not all cards have all features, not all users wants to enable all > features. Yes, I understand that. You're not reading the derivations correctly. Let's take an example: derive MVME147_SCSI from MVME147 & SCSI This doesn't turn on MVME147_SCSI on every MVME147 board. It turns on MVME147_SCSI when both MVME147 *and SCCI* are on. So to suppress MVME147_SCSI, one just leaves SCCI off. All these derived symbols will still be controllable. The difference is that instead of being controlled by a low-level hardware-oriented question they're controlled by a capability or subsystem symbol like SCSI, NET_ETHERNET, or SERIAL. > Eric> # These were separate questions in CML1 derive MAC_SCC from MAC > Eric> & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from > Eric> (SUN3 | SUN3X) & SCSI > > As Alan already pointed out thats assumption is invalid. I'm in touch with Ray Knight directly and will fix this as he requests. > Yes I have objections. I thought I had made this clear a long time > ago: Go play with another port and leave the m68k port alone. Does this mean you'll take over maintaining the CML2 rules files for the m68k port, so I don't have to? That would be wonderful. Reasoned objections can change my behavior. Grunting territorial challenges at me will not. You have two options: (1) persuade Linus that the whole CML2 thing is a bad idea and should be dropped, or (2) work with me to correct any errors I have made and improve the system. Growling at me and hoping I go away won't work, not when I've invested a year's effort in this project. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond As with the Christian religion, the worst advertisement for Socialism is its adherents. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Alan Cox <[EMAIL PROTECTED]>: > There are also a lot of config options that are implied by your setup in > an embedded enviromment but which you dont actually want because you didnt > wire them Well, then, you don't specify the guard capability! If your MV147 isn't wired for serial, then leave SERIAL off. The point of the derivation is exactly to let you do that. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Jamie Lokier <[EMAIL PROTECTED]>:
> Which is unfortunately wrong if you want the parport subsystem on x86
> but won't be using the parport_pc driver with it. I.e. you'll be using
> some other driver which isn't part of the kernel tree. Perhaps a
> modified version of parport_pc, perhaps something else.
If you're integrating drivers that aren't in the kernel tree, you can and
should patch the CML2 rulebase to compensate. So your patch for
the modified driver should comment out the PARPORT_PC==PARPORT
requirement. Problem solved.
More generally, arguments of the form "Non-mainline custom hack X
could invalidate constraint Y, therefore we can't have Y in the
rulebase" are dangerous -- I suspect you could reduce your set of
constraints to nil very quickly that way, and thus badly screw over
the 99% of people who just want to build a more or less stock kernel.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The abortion rights and gun control debates are twin aspects of a deeper
question --- does an individual ever have the right to make decisions
that are literally life-or-death? And if not the individual, who does?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
David Weinehall <[EMAIL PROTECTED]>:
> > require X86 and PARPORT implies PARPORT_PC
> > unless X86==n suppress PARPORT_PC
> >
> > which forces PARPORT_PC==y and makes the question invisible on X86
> > machines, but leaves the question visible on all others.
>
> Yes, but there are quite a lot of people who don't want
> parport/serial/whatever compiled into their kernels at all,
> eventhough they have an x86. Think low-memory systems or similar.
That's OK. Neither of these constraints says PARPORT must be compiled in.
Look at the conditionals carefully.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
"...The Bill of Rights is a literal and absolute document. The First
Amendment doesn't say you have a right to speak out unless the
government has a 'compelling interest' in censoring the Internet. The
Second Amendment doesn't say you have the right to keep and bear arms
until some madman plants a bomb. The Fourth Amendment doesn't say you
have the right to be secure from search and seizure unless some FBI
agent thinks you fit the profile of a terrorist. The government has no
right to interfere with any of these freedoms under any circumstances."
-- Harry Browne, 1996 USA presidential candidate, Libertarian Party
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Tom Rini <[EMAIL PROTECTED]>: > Only sort-of. There are some cases where you can get away with that. > Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, > always (right?) Yes. So the right answer there isn't to use a derivation but to say: require X86 and PARPORT implies PARPORT_PC unless X86==n suppress PARPORT_PC which forces PARPORT_PC==y and makes the question invisible on X86 machines, but leaves the question visible on all others. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The real point of audits is to instill fear, not to extract revenue; the IRS aims at winning through intimidation and (thereby) getting maximum voluntary compliance -- Paul Strassel, former IRS Headquarters Agent Wall St. Journal 1980 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 design philosophy heads-up
Tom Rini <[EMAIL PROTECTED]>: > On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: > > > # These were separate questions in CML1 > > > derive MAC_SCC from MAC & SERIAL > > > derive MAC_SCSI from MAC & SCSI > > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI > > > > Not all Mac's use the SCC if they have serial > > Not all Mac's use the same SCSI controller > > Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but > I never did get Linux up and running on the m68ks I had.. Exactly. In fact we can be more specific -- the "Macintoshes" in question are the old-fashioned NuBus-based 68k toaster boxes, not the more recent designs with a PCI bus. Relevant stuff in the Configure.help implies that MAC_SCC and MAC_SCSI enable support for the on-board hardware built into those puppies. > But Alan's point is a good one. There are _lots_ of cases you can't get away > with things like this, unless you get very fine grained. In fact, it would > be much eaiser to do this seperately from the kernel. Ie another, > possibly/probably _not_ inkernel config tool which asks what machine you > have, picks lots of sane defaults and setups a kernel config for you. This > is _sort of_ what PPC does right now with the large number of 'default > configs' (arch/ppc/configs). You're really talking about a different issue here, autoconfiguration rather than static dependencies. Giacomo Catenazzi is working on that. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 design philosophy heads-up
I've said before on these lists that one of the purposes of CML2's single-apex tree design is to move the configuration dialog away from low-level platform- specific questions towards higher-level questions about policy or intentions. Or to put another way: away from hardware, towards capabilities. As a concrete example, the CML2 rulesfile master for the m68k port tree now has a section that looks like this: # These were separate questions in CML1. They enable on-board peripheral # controllers in single-board computers. derive MVME147_NET from MVME147 & NET_ETHERNET derive MVME147_SCC from MVME147 & SERIAL derive MVME147_SCSI from MVME147 & SCSI derive MVME16x_NET from MVME16x & NET_ETHERNET derive MVME16x_SCC from MVME16x & SERIAL derive MVME16x_SCSI from MVME16x & SCSI derive BVME6000_NET from BVME6000 & NET_ETHERNET derive BVME6000_SCC from BVME6000 & SERIAL derive BVME6000_SCSI from BVME6000 & SCSI # These were separate questions in CML1 derive MAC_SCC from MAC & SERIAL derive MAC_SCSI from MAC & SCSI derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI If it isn't obvious, the intent is that if you specify (say) both MVME147 (a machine type) and SERIAL (a capability) you automatically get the specific driver support under MVME147_SCC. This is different from the CML1 approach, which generally involved explicitly specifying each driver with mutual dependencies described (if at all) in Configure.help. I've created a number of derivations of this kind recently. I'm not going out of my way to do this, but what I am trying to do is reduce the number of symbols undocumented in Configure.help to zero (I've got it down to 243 from 547 when I started). When I can eliminate the need for a configuration question and associated help by writing this kind of formula, I'm doing so. This note is a heads-up. If others with a stake in the configuration system (port managers, etc.) have objections to moving further in this direction, I need to hear about it, and about what you think we should be doing instead. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.4.0, aka "brutality and heuristics"
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.4.0: Fri May 4 18:18:15 EDT 2001
* Ugly hack for recovery from inconsistent configurations.
We've spent a lot of time and effort recently arguing about elaborate
recovery algorithms for the extremely unusual case that the CML2
configurator loads a configuration that has become invalid because of
a constraint added to the rulebase since the configuration was
written. (Mere addition of new symbols doesn't trigger this.)
The general problem is theoretically hard and for practical purposes
insoluble, so I've have implemented a suggestion by Dave Wagner and
John Stoffel. CML2 will now try to recover fom a load-time
inconsistency by smashing all the non-frozen symbols in the violated
constraint to the value N (and notifying the user that it's doing so).
This is ugly, but will handle most cases. In the few it doesn't
handle, the bindings loaded from the file will be backed out as a
unit. In any case the user will be left in a running configurator.
Sigh...now, I hope, we can get back to solving problems that I don't
expect to be so rare they're lost in the statistical noise. It's not
good to get so obsessed about finding clever solutions to corner cases
that one loses sight of the larger issues.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The prestige of government has undoubtedly been lowered considerably
by the Prohibition law. For nothing is more destructive of respect for
the government and the law of the land than passing laws which cannot
be enforced. It is an open secret that the dangerous increase of crime
in this country is closely connected with this.
-- Albert Einstein, "My First Impression of the U.S.A.", 1921
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: Why recovering from broken configs is too hard
Albert D. Cahalan <[EMAIL PROTECTED]>:
> Procedure:
>
> 1. throw out all junk symbols (could try spell checking first)
> 2. mark non-default settings as read-only
> 3. add missing symbols as needed to meet constraints
> 4. add any additional missing symbols
> 5. mutate the config until it works... user may ^C when bored
You can't be serious. You invite the poor user to sit through an
indefinite, unpredictable, and *large* number of mutation passes
hoping the stupid search will trip over a solution? That's a far worse
waste of their time than telling them to correct by hand in the
exceedingly rare cases that would be necessary, in my considered
opinion.
A more egregious case of using a bazooka to swat a fly I've seldom seen.
Can we restore some sense of *proportion* here?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons. A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
-- George Orwell, "You and the Atom Bomb", 1945
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Why recovering from broken configs is too hard
Alan Cox <[EMAIL PROTECTED]>: > If you get a conflict, turn the second feature in config file order off/on > as appropriate then tell the user you did it. Then continue to verify. > Actually I think the problem is different. You are trying to solve a > mathematical graph theory problem elegantly. Make oldconfig solves a real > world problem by a mixture of brutality and heuristics. You want brutality and heuristics? I'll give you brutality and heuristics... I could just treat a config as a sequence of assignments, as though the user had typed them in sequence, rejecting any later ones that throw constraint violations. That way we can avoid ever accepting or having to deal with an invalid configuration. The invariant that every symbol assignment either augments a valid configuration or is rejected would be conserved. This isn't "recovery", it's more like high-handedly throwing away assignments that don't happen to fit stuff bound earlier in the tree traverse that defines symbol print order. And it's going to give odd, "brutal" results in some cases because guard symbols are ordered before their dependents. But if all you want is brutality and heuristics, it might do. I guess you didn't know that I trained as a mathematical logician. On the one hand, that predisposes me to try to find "elegant" solutions where you might regard brutality and heuristics as more appropriate. On the other hand, without that kind of background you don't get people building constraint-satisfaction systems to give you provably-correct results, either. So perhaps, on the whole, mine is a more positive predisposition than not ;-). -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Men trained in arms from their infancy, and animated by the love of liberty, will afford neither a cheap or easy conquest. -- From the Declaration of the Continental Congress, July 1775. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Why recovering from broken configs is too hard
Keith Owens <[EMAIL PROTECTED]>: > On Thu, 3 May 2001 03:47:55 -0400, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >OK, so you want CML2's "make oldconfig" to do something more graceful than > >simply say "Foo! You violated this constraint! Go fix it!" > > (i) Start with a valid config. CML2 will not allow any changes that > violate the constraints. Not a problem. Right. This is 99.9% of cases. All this heat and argument is over a very, very unusual situation. Much more unusual than most of the people arguing about it realize. (For those of you haven't caught up with this, *missing symbols do not make a configuration invalid*. Only inconsistencies between explicitly set symbols can do that.) > (ii) Start with a invalid config. CML2 makes best effort at correcting > it. > > (a) Interactive mode (menuconfig, xconfig) - tell the user to fix > it. The problem with this is that in order to support it I have to throw away the configurator's central invariant -- which is that every change that does not lead to a valid configuration is rejected (with an explanation). I'm not going to do that. It's not worth it to handle a case this marginal. > (b) Batch mode (oldconfig). Attempt to automatically correct the > config using these rules. > > (1) Earlier constraints take priority over later constraints. > That is, scan the constraints from top to bottom as listed > by the rules. > > (2) For valid constraints, freeze all variables in the > constraint, both guard and dependent. > > (3) For failing constraints, freeze the guard variables, change > the dependent variable to satisfy the constraint then > freeze it. There's the problem. You don't know which variable(s) are dependent. That's not a well-defined notion here. Consider the case that stimulated this whole argument: (X86 and SMP) implies RTC!=n You think you know that RTC is 'dependent', but this is an illusion created by the presence of the asymmetrical `implies'. Go look at the hierarchy. You'll see what I mean. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Are we at last brought to such a humiliating and debasing degradation, that we cannot be trusted with arms for our own defence? Where is the difference between having our arms in our own possession and under our own direction, and having them under the management of Congress? If our defence be the *real* object of having those arms, in whose hands can they be trusted with more propriety, or equal safety to us, as in our own hands? -- Patrick Henry, speech of June 9 1788 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hierarchy doesn't solve the problem
Juan Quintela <[EMAIL PROTECTED]>: > linux 2.4.(x+1) has more drivers/options/whatever that linux-2.4.x. I > want to be prompted only for the new drivers/options/whatever it > chooses the old ones from the .config file. Note that my old .config > file is not a valid configuration because it misses symbols (or I am > wrong and this is a valid configuration ?). Yes, you're wrong. This is a valid configuration. If any of the missing values have to be non-N, CML2 will deduce this and tell you what it's changing them to and why. In CML2's world "symbol not set" is different from "symbol set to n". When a symbol is not set, the deducer can force it to value that satisfies constraints. Your second scenario is addressed by the samne correction. >Otherwise I will be happy if > you provide me something like: > > make "CONFIG_SCSI=n" oldconfig > > or similar, i.e. _I_ know what I want to change, and I want to change > only that. Notice that I want also be able to do the other way > around: > > make "CONFIG_SCSI=m" oldconfig > > and then be prompted for all the SCSI drivers (because they was not in > the .config before). There is such an option. It's -d, which sets a symbol from the -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
Horst von Brand <[EMAIL PROTECTED]>: >> No. Every new kernel changes the constraints so every new kernel you have >> to reconfigure from scratch. That also makes it very hard to be sure you got >> the results right. > > Really? I've mostly seen symbols added, very rarely did I see constraints > changed. But that might be just my narrow view on the matter... It's mine as well. And I have been paying careful attention to this issue. > > oldconfig has a simple algorithm that works well for current cases > > > > Start at the top of the symbols in file order. If a symbol is new ask the > > user. If a symbol is now violating a constraint it gets set according to > > existing constraints if not it gets set to its old value. > > I understand that to mean: "If it is new and (at least somewhat) > unconstrained, ask the user. If fully constrained, take that value > unconditionally." This is a _very_ different case from a broken > configuration as a starting point, in which constraints are violated with > the values as set. Exactly! And in fact, my oldconfig already does what Alan prescribes. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
Horst von Brand <[EMAIL PROTECTED]>: > If you support broken configurations in any way, your program is just > wildly guessing what they did mean. The exact (and very probably not in any > way cleanly thought out) behaviour in corner cases then becomes "the way > things work", and we end up in an unmaintainable mess yet again. Yes, this is precisely what I fear. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Rapists just *love* unarmed women. And the politicians who disarm them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why recovering from broken configs is too hard
David Mansfield <[EMAIL PROTECTED]>: > If so, given the above ruleset involving symbols A, B and C, and given > that such a ruleset is violated for some reason (you don't even care > why), use the following approach: > > set C to 'n' -> are we ok? > set B to 'n' -> are we ok? > set A to 'n' -> are we ok? > > Inform the user of each change. In a massively broken configuration you > could end up with a lot of stuff set to 'n' ultimately, but I think that > this generally would just end up shutting off troublesome configuration > settings, and requiring that the user then reset them manually. Actually this is the best idea I've seen yet, because the single "known-good" configuration is almost all n values. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why recovering from broken configs is too hard
Alexander Viro <[EMAIL PROTECTED]>: > I'm not talking about connectedness of the thing. However, I suspect that > graph has a small subset such that removing it makes it fall apart. Um. So how does that help? -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Hitler, April 11 1942, revealing the real agenda of "gun control" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why recovering from broken configs is too hard
Alexander Viro <[EMAIL PROTECTED]>: > Assertion: you can split the set of variables into disjoint union of > small subsets X, Y_1,...,Y_m such that each constraint is concerned > only with variables from X and at most one of Y_i. > > IOW, there is a small "core" and for fixed values of core variables > constraints fall into groups, each dealing with its own _small_ > set of variables. > > If that assertion is true the complexity is nowhere near 3^N. > > Eric, you probably have the most accurate information about the > existing constraints. Care to verify the assertion above? I'm > serious - the set of constraints is very far from generic and > if nothing else, such preprocessing (splitting variables into > core and peripherial groups) can make life easier in other > parts of the thing. You're almost right. If you counted only explicit constraints, created by require statements, you get a bunch of cliques that aren't that large. Unfortunatelythere are a huge bunch of implicit constraints created by dependency relationships in the menu tree. For example, all SCSI cards are dependents of the SCSI symbol. Set SCSI to N and all the card symbols get turned off; set any card symbol to Y or M and the value of SCSI goes to Y or M correspondingly. So the way it actually works (I think; I've have to write code to do a topological analysis to be sure) out is that there's sort of a light dust of atoms (BSD quota is one of them) surrounding one huge gnarly menu-tree-shaped clique. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why recovering from broken configs is too hard
Ingo Oeser <[EMAIL PROTECTED]>: > If the current dependencies of the symbols can be represented as > a tree (or can be topologically sorted, to be CS-correct), then I > would only care about the "leaves" of that tree. Sorry, there are crosslinks, it's a DAG. The example that triggered this displays one. > Most added symbols in newer configs are added as leaves. So this > should suffice in most situations. Oh? What if the leaf participates in a newly-added constraint such that when you flip it, something else (node or leaf) has to change? There could be ripple effects all through the tree. This isn't a farfetched case, either. The new leaf might be a PCMCIA card (for example) in which case enabling it would force generic PCMCIA support on. Sound harmless? OK. Suppose the new capability is some new IP filtering capability that interacts with NAT and connection tracking. Now go look at the cross-constraints in IP filtering. Take a bottle of strong analgesic with you, because you're going to need it. I told you there's no way to separate the easy cases from the hard ones. I didn't say that casually. I've been thinking about problems like this since last May. The configuration-state space is all tangled together by the the constraints in such a way that it's hard to put a bound beforehand on the side-effects effects of what might at first look like a single-point change. Even in a new leaf node. The most relevant distinction isn't "leaf vs. interior node"; it's the size of a symbol's clique. Consider the relation "X participates in a constraint with Y" (X co Y). Now consider the transitive completion of that relationship; we'll say that X is "related" to Y if there is any chain of co relations between them. The set of all Y related to X is its clique. > If we miss a symbol from .config, we ask the user, using the one > from defconfig as default, if we cannot derive its value from > our constraints. That's almost the way it works now. If the user doesn't supply a config the defconfig gets used. Falling back on the defconfig for *individual* symbols if the user's config didn't supply a value...hmm. technically possible but doesn't strike me as a good idea. What if the defconfig is set up for IDE but the user wants to do SCSI? He doesn't supply a value for IDE, it gets picked up as y from the defconfig...user is now carrying code he doesn't want and didn't expect. > If we have a symbol in .config, that we don't know about, we > simply ignore it (and tell the user that it's "obsolete or > renamed"). Yup, I do that. > If the value for a symbol is there, but doesn't fit our > constraints: Ask the user or use the opposite (if it is boolean). *You don't know which symbol is wrong* That's the whole point! > And will the derivation be in nearly constant time, if I change > one symbol? Deduction time is...hm. Linear in tbe symbol's clique size. I think. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Certainly one of the chief guarantees of freedom under any government, no matter how popular and respected, is the right of the citizens to keep and bear arms. [...] the right of the citizens to bear arms is just one guarantee against arbitrary government and one more safeguard against a tyranny which now appears remote in America, but which historically has proved to be always possible. -- Hubert H. Humphrey, 1960 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Why recovering from broken configs is too hard
Greg Banks <[EMAIL PROTECTED]>: > There is a natural order for presenting variables to the > user, and that's the menu tree order. At least in the Linux > kernel CML2 corpus the menus are roughly organised from most > general to most specific options, so options appearing earlier > in the tree are likely to appear in more constraints and you > probably want to ask the user to mutate them later. OK. Agreed, but it doesn't solve the general problem. Generating models is still hard. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond To make inexpensive guns impossible to get is to say that you're putting a money test on getting a gun. It's racism in its worst form. -- Roy Innis, president of the Congress of Racial Equality (CORE), 1988 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hierarchy doesn't solve the problem
John Stoffel <[EMAIL PROTECTED]>: > He's saying that when you find the first invalid assertion, such as > not having CONFIG_RTC defined, when reading the .config file, you > should prompt for a fix. Then once the input is taken, continue your > checks, prompting for each following problem as needed. The problem lies in that innocent-sounding phrase "prompt for a fix". Generating such a prompt is a far deeper problem than you seem to realize. > No, we're just asking you to make the CML2 parser more tolerant of old > and possibly broken configs. The parser is not the problem. The parser tolerates old, broken configs quite happily. Gives you a nice pop-up message when it hits an invalid symbol. No, the problem is that y*ou're asking me to make the deduction machinery solve a problem that is (a) ill-defined and (b) subject to a 3^n combinatorial explosion. > I haven't looked at the parser in any detail, but I assume that there > are heirarchal configuration settings. When there is a mis-match, > where a sub-option conflicts with an upper option, how hard would it > be to print a warning, and just reset the sub-option to an acceptable > state? Clever idea -- not so clever that stupid me didn't think of it six months ago, but clever. Might even work if the constraints always obeyed a neat hierarchy. They don't. The constraints can reach across the tree. In many cases there is no way to define "upper" or "lower". (X86 and SMP) implies RTC!=n is actually a good example. Here's where they fit in the tree: main 'Linux Kernel Configuration System' arch 'Processor type' X86'Intel or compatible 80x86 processor' generic'Architecture-independent feature selections' SMP'Symmetric Multi-Processing support' archihacks 'Architecture-specific hardware hacks' RTC'Enhanced Real Time Clock Support' Yes, that's right -- they're all at the same level. OK, X86 is frozen by hypothesis. So now give me a rule for telling which of SMP and RTC is "superior". Note that in order to make the rule usable by the deducer, it can't know anything about the semantics of the symbols. Do you sense an abyss yawning beneath you yet? If not, hold on. You'll see it shortly. I started to write up a full explanation but I think I'm going to post that separately. It's long. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Never could an increase of comfort or security be a sufficient good to be bought at the price of liberty. -- Hillaire Belloc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
Giacomo Catenazzi <[EMAIL PROTECTED]>: > No. You propmt only one invalid assertion. After you this prompt > you continue to validate rules and you will maybe prompt for another > invalid rules. But these invalid rules are generally infrequent. I may be having problems with your English. I don't think I understand this. > It is very unlikely to have constraint on string or on integer. But > anyway, where is the problem? You simple ask the new value of this > symbol. The problem is that you're now, in effect, telling me to invent a new interactive configurator with different rules than the normal one! This is a horrible swamp to wander into just to avoid making oldconfig users fire up vi occasionally. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "You have taught us much. Come with us and join the movement." "This movement of yours, does it have slogans?" inquired the Chink. "Right on!" they cried. And they quoted him some. "Your movement, does it have a flag?" asked the Chink. "You bet!" and they described their emblem. "And does your movement have leaders?" "Great leaders." "Then shove it up your butts," said the Chink. "I have taught you nothing." -- Tom Robbins, "Even Cowgirls Get The Blues" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
Giacomo A. Catenazzi <[EMAIL PROTECTED]>: > I think that a fundamental requirment is that 'make oldconfig' should > validate any configurations (also the wrong conf). > (If you correct your rules, our old .config can be invalid on a new > kernel, and we don't want regualary edit our .config). Validating is exactly what it's doing now. What you really want is for it to semi-automatically *correct* broken configurations, which is very different and much harder. > My proposal is instaed of complain about configuration violatation, > you just wrote the possible correct configuration and prompt user to > select the correct configuration. > In the case you cite, e.g. oldconfig shoud prompt: > 1) SMP=n > 2) RTC=m > 3) RTC=y > (assuming the ARCH is invariant). You, and the other person who proposed this previously, are getting way too hung up on this particular easy case and not thinking about the general problem. The number of prompts goes up with the number of variables in the constraint. But the number of possible correct configurations goes up as 2**n -- actually, 3**n because we have trits. What you're saying, in effect, is that if f is number of frozen variables in the constraint then the configurator ought to generate 3 ** (n - f) possible correct models and prompt for one of them. Since f typically equals just 1 that number goes up really fast with n. And what if one of the variables in the constraint is of integer or string type? In that case the number of possible models to be prompted for is effectively infinite. (Finite but very very large). You are proposing an interface that will handle easy cases but blow up in the user's face in any hard one. That's poor design, frustrating the user exactly when he/she most needs help. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Peter Samuelson <[EMAIL PROTECTED]>:
> [esr]
> > Besides, right now the configurator has a simple invariant. It will
> > only accept consistent configurations
>
> So you are saying that the old 'vi .config; make oldconfig' trick is
> officially unsupported? That's too bad, it was quite handy.
Depends on how you define `unsupported'. Make oldconfig will tell you
exactly and unambiguously what was wrong with the configuration. I think
if you're hard-core enough to vi your config, you're hard-core enough to
interpret and act on
This configuration violates the following constraints:
(X86 and SMP==y) implies RTC!=n
without needing some wussy GUI holding your hand :-).
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
The end move in politics is always to pick up a gun.
-- R. Buckminster Fuller
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
John Stoffel <[EMAIL PROTECTED]>: > It should then highlight *all* of the potential problem config > setting(s) and let the user deal. But they should never be forced to > hand edit their config file because a dependency is broken somewhere. > CML2 should enforce the *writing* of compliant files, but should deal > gracefully with non-compliant ones. Within reason of course. The "within reason" is the problem. It's very easy to construct simple cases of invalid configs that blow the number of `tainted' symbols up much larger than the number of violated constraints. An interface of the kind you suggest would deluge the user with possible things to be corrected without actually revealing the nature of the problem. Besides, right now the configurator has a simple invariant. It will only accept consistent configurations and it will only write consistent configurations -- in fact, your configuration is guaranteed correct after ever attempt to change a symbol with the configurator itself. I'm very, very reluctant to do anything that will go near breaking that invariant. I believe the the right fix is to go through the one-time transition necessary to be in a world where inconsistent configurations never get written, rather than to be overly accomodating to yesterday's bugs. > Eric> USB and SCSI are both enabled/disabled in the system buses menu. > Eric> The apparent confusion > > Then they should be pushed down a level to be under those buses. They > don't belong on the top level. That doesn't work either. See the "Good style in rulebase design" section in the CML2 paper for discussion. The last paragraph is especially relevant. > More correctly, *any* configuration setting on an upper level should > not depend on a lower level setting. Sorry, that's dreadfully bad advice and is not going to happen. If I did as you suggest, I'd be throwing out the ability to do consistency checks and deduce side effects. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "Those who make peaceful revolution impossible will make violent revolution inevitable." -- John F. Kennedy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
[EMAIL PROTECTED] <[EMAIL PROTECTED]>: > I think ppl are recommending you BZ2 all your sigs.. Yes, I got that. Except for the people saying they like them as-is. In the absence of a clear consensus on the matter, I'm going to do as I please. Especially since I have a strong suspicion that neither camp would change their evaluation of my sigs if I did compress them. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Alexander Viro <[EMAIL PROTECTED]>: > We hang in different parts of USENET I don't hang in Usenet at all, any more. Gave up on it about '98. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Anton Altaparmakov <[EMAIL PROTECTED]>: > >I tried whitespace, but the default Tkinter font isn't fixed-width. How > >do you do invisible text? > > Text colour = background colour -> invisible Well, duh. Unfortunately, it doesn't seem to have occured to the dozen or so people who suggested this that: (a) Background color can vary depending on how Tk's X resources are set, and (b) Tk doesn't give me, AFAIK, any way to query either that background color or those resources. Fer cripes' sake. If it were that easy I'd have *done* it already, people! Anyway my attempts to set a foreground color on an inactive button widget failed. I don't know why. Tk is full of weird little corners like that. What I've done is just disabled inactive help buttons without trying to hack the text or color. That makes them all the same width, though the legend "Help" does show up in gray on the inacive ones. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "The state calls its own violence `law', but that of the individual `crime'" -- Max Stirner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Alexander Viro <[EMAIL PROTECTED]>:
> >From AFW FAQ:
>
> Q11. What is the McQuary limit?
> A11. "There once was a man from Nantucket,
> who lost his .sig in a bucket.
> Five lines was too long,
> columns 80 just strong,
> so he didn't know where to tuck it."
> A11. The limit on signature size: "4x80".
I just added the following to the Jargon File masters:
@hd{McQuary limit} @p{} 4 lines of at most 80 characters each,
sometimes still cited on Usenet as the maximum acceptable size of a
@es{sig block}. Before the great bandwidth explosion of the early
1990s, long sigs actually cost people running Usenet servers
significant amounts of money. Nowadays social pressure against
long sigs is intended to avoid waste of human attention rather
than machine bandwidth. Accordingly, the McQuary limit should
be considered a rule of thumb rather than a hard limit; it's
best to avoid sigs that are large, repetitive, and distracting.
See also @es{warlording}.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
What, then is law [government]? It is the collective organization of
the individual right to lawful defense."
-- Frederic Bastiat, "The Law"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
David Emory Watson <[EMAIL PROTECTED]>: > Oh. Well in hindsight, I guess your are right. After all I wouldn't > want to be a luser, much less associated with AOL. Gosh I never > realized. Maybe I just didn't read the right standards manual when I > started using the internet. Where did you learn all of this? No, > nevermind I don't care. I'm sorry for contributing to this silly flame > war. Time for me to put on my hacker-folklorist hat... Actually, Al is sort of half-right here. There used to be a 4-lines-or-less convention on USENET, back in the days when bandwidth was expensive. I adhered to it then, because it mattered. Nowadays it doesn't -- at least not at that level. Huge sigs with embedded ASCII graphics and the like are still best avoided, but merely because they're tasteless and distracting. I don't think I've heard anyone invoke the 4-line rule since about 1992, though. I didn't start generating short random quotes into my sig until about 1996, well after the "standard" was effectively dead. Despite the demise of the 4-line standard, I have a pretty definite impression that the average size of sigs actually dropped in the 1990s. The main thing that formerly inflated a lot of them was the need to list multiple bang-path addresses and other forms of contact info. Reliable @-addressing pretty much eliminated that pressure. Even back in its day this "rule" was frequently abused as a socially acceptable way to attack people whose opinions or style one disliked. This is doubtless one reason it failed to survive the bandwidth boom. Hmmm. Maybe this should be a Jargon File entry... -- http://www.tuxedo.org/~esr/";>Eric S. Raymond The politician attempts to remedy the evil by increasing the very thing that caused the evil in the first place: legal plunder. -- Frederick Bastiat - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.3.3 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/
Release 1.3.3: Sun Apr 29 23:00:33 EDT 2001
* Resync with 2.4.4.
* Help texts merged into symbols file; the `helpfile' declaration
is gone. (Text is merged in from Documentation/Configure.help
at CML2 installation time.)
* Tweaked the appearance of inactive help buttons by popular demand.
My clever plan worked. Less than three hours after I pronounced 1.3.1
"stable", somebody turned in the first crash bug in three weeks. Fortunately
it was pretty trivial to fix, a loose end from one of my speedups. Fixed in
yesterday's 1.3.2.
The big news in this version is that all the help texts have been merged into
the CML2 rules files. A typical symbol declaration now looks like this:
GONK_5523 'Support for B5523 adaptive gonkulator' text
Say Y here to compile in support for the Bollix 5523 adaptive gonkulator.
.
Help texts are merged into the CML2 symbols file at CML2 installation time.
The `helpfile' declaration is gone. Among other things, this means you no
longer need to run CML2 inside a kernel source tree; you can test the scripts
anywhere.
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
See, when the GOVERNMENT spends money, it creates jobs; whereas when the money
is left in the hands of TAXPAYERS, God only knows what they do with it. Bake
it into pies, probably. Anything to avoid creating jobs.
-- Dave Barry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Anton Altaparmakov <[EMAIL PROTECTED]>:
> I don't know about whether this is possible with Tcl but have you tried A)
> invisible text and/or B) white space character text (e.g. one or more
> spaces)? That's the kind of thing I usually try in this situation... Just
> an idea...
I tried whitespace, but the default Tkinter font isn't fixed-width. How
do you do invisible text?
--
http://www.tuxedo.org/~esr/";>Eric S. Raymond
..every Man has a Property in his own Person. This no Body has any
Right to but himself. The Labour of his Body, and the Work of his
Hands, we may say, are properly his. The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
-- John Locke, "A Treatise Concerning Civil Government"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
John Stoffel <[EMAIL PROTECTED]>: > Before on startup it would give: > > [root@jfs linux]# make config > rm -f include/asm > ( cd include ; ln -sf asm-i386 asm) > python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out > rules.out > ISA=y (deduced from X86) > Side effects from config.out: > NETDEVICES=m (deduced from ATALK) > SOUND_OSS=m (deduced from SOUND_VIA82CXXX) > SOUND_OSS=y (deduced from SOUND_YMFPCI_LEGACY) > SOUND=y (deduced from SOUND_OSS) > python -O scripts/configtrans.py -h include/linux/autoconf.h -s > .config config.out > > > So I poked around, found the RTC setting, read the help and now I > understand why I should have had it enabled all along. No problem. > So saved my changes and exited. > > I then restarted, and it came up properly, but I'm now getting the > following output: > > [root@jfs linux]# make config > rm -f include/asm > ( cd include ; ln -sf asm-i386 asm) > python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out > rules.out > ISA=y (deduced from X86) > > > Notice that it's still setting the ISA=y flag, but not the rest it was > complaining about. I think it should have either updated this setting > by default for the ISA bus, or warned on exit that it still needed to > be set. > > I think this is a true bug somewhere. Nope, it's a benign side-effect of the order of evaluation of command-line switches. Here's what's happening: 1. X86=y is being set and frozen. 2. ISA=y is deduced from X86 3. config.out is read in. In step 3, you don't see any side effects from config.out because they were calculated last time and wruitten into the saved configuration. You still see the ISA=y message because your config.out has not yet been read in at the time that side effect is computed. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "Among the many misdeeds of British rule in India, history will look upon the Act depriving a whole nation of arms as the blackest." -- Mohandas Ghandhi, An Autobiography, pg 446 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Eric S. Raymond <[EMAIL PROTECTED]>: > USB and SCSI are both enabled/disabled in the system buses menu. The > apparent confusion Sorry, I typoed... USB and SCSI are both enabled/disabled in the system buses menu. The apparent confusion happens because of their defaults. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Society in every state is a blessing, but government even in its best state is but a necessary evil; in its worst state an intolerable one; for when we suffer, or are exposed to the same miseries *by a government*, which we might expect in a country *without government*, our calamities is heightened by reflecting that we furnish the means by which we suffer." -- Thomas Paine - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CML2 1.3.1, aka "I stick my neck out a mile..."
John Stoffel <[EMAIL PROTECTED]>: > Which is a real PITA because now I have to edit my .config file to > have: > >CONFIG_RTC=y The correct fix for this PITA is for Linus not to ship a broken defconfig. > Now when I do a 'make config' it comes up properly. I > think this is a poor interface setup. It should either > > a. Give more info on what to correct, such as the configuration line > to edit and in which file. > > b. Print a warning, startup the configuration tool and put you at the > problematic line, with the help section showing. Or highlight this > choice in some manner as being wrong and showing you how to ffix it. > > This is a minor, but annoying problem and should be fixed ASAP before > public use. I hear you. The problem is that "what's wrong" is not as well-defined as one might like. In this case the error could be in the setting of X86, SMP, or RTC. CML2 has no way to know which of these is mis-set, so it can't know which one to pop up.. > At the top-level, most stuff cannot be selected on/off, but you can > enter it. But you also do have some y/m/n choices which seems wierd > and out of place. For example, "SCSI disk support" is a menu, but > "HAMRADIO: Amateur Radio support (NEW)" is a y/n choice. It would > make more sense to me to have it down a level, with a simple entry to > "Hamradio support". Once you go into that level, you would be asked > to have it turned on/off there. > > This would remove some of the clutter at the top level. > > As a contrast, the USB entry doesn't ask Y/N for USB support, and when > I enter the directory, it has all these options listed. I thought > that CML would suppres stuff (children, drivers, etc) if I didn't have > the top level selected. In this case, I can't turn off USB support in > any manner, so I see all the children when I could care less about > them. USB and SCSI are both enabled/disabled in the system buses menu. The apparent confusion > Also, the buttons on the right hand side for HELP, are wider when they > have text in them, but slightly narrower when they are blank. They > should be the same width no matter what. It looks ragged and ugly. I know. Sadly, I couldn't find a way to coerce Tcl into doing this right. > I don't like how it keeps changing the window size whenever you go > into a sub-level. It should not re-size the main window at all, it > should just update the contents and give scroll bars if needed for > both up/down scolling and side to side. Once the user has setup their > prefs, the CML code shouldn't keep it jumping all over the screen. That's on my to-do list. It's low-priority, though, since I figure most people will use menuconfig. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "Today, we need a nation of Minutemen, citizens who are not only prepared to take arms, but citizens who regard the preservation of freedom as the basic purpose of their daily life and who are willing to consciously work and sacrifice for that freedom." -- John F. Kennedy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.3.1, aka "I stick my neck out a mile..."
Release 1.3.1: Fri Apr 27 19:02:31 EDT 2001 * kxref.py can now replace the unmaintained checkhelp.pl, checkconfig.pl, and checkincludes.pl scripts. I'm going to stick my neck out a mile and say that I think this is a stable release. Doing so, of course, is in reality a clever plan which ensures that at least three embarrassing bugs will be discovered within the next 24 hours... Seriously, I am now out of stuff to do on the CML2 code itself. The code now seems to be up to acceptable speed even on slow machines, the UI feature requests have petered out, and this release seems to be feature-complete with respect to everything that can be done before the 2.5 cutover. There is one 1.3.0 bug report pending from jeff millar, but I have not been able to reproduce it with 1.3.1. I will, of course, continue to process CML2 bug reports and rulesfile fixes. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.2.8 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.2.8: Thu Apr 26 15:18:38 EDT 2001 * Major internal speedup; symbol evaluation is much faster now. Symbol evaluation was the speed bottleneck in the configurator for quite a while. Thanks to a reorganization of one of the central data structures, it's now down in the profiler noise. As a result, many operations like commits and file loading are now so fast that I've removed their twirly-baton progress indicators. The new slowdown king is the algebraic-simplification code for constraints. Greg Banks and I have been kicking around some ideas about common-subexpression elimination that might lead to big speedups here as well, but it's a complex change that might take a while. It's beginning to look like I might be able to remove the fastmode crock after the next round of tuning. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Militias, when properly formed, are in fact the people themselves and include all men capable of bearing arms. [...] To preserve liberty it is essential that the whole body of the people always possess arms and be taught alike, especially when young, how to use them. -- Senator Richard Henry Lee, 1788, on "militia" in the 2nd Amendment - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 1.2.5 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.2.5: Wed Apr 25 13:55:02 EDT 2001 * Synchronized with 2.4.4-pre6. * Fixed KEY_HOME bug reported by Alex L. Mauer. * Tom Rini's next round of PPC rules patches. * Reference manual updated to reflect gcml implementation experience. Just another point release. -- 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
