Kernel Traffic #146 For 17 Dec 2001

indent does _not_ solve the problem of:

• buggers who think that MyVariableIsBiggerThanYourVariable is a good name
• buggers who define a function with 42 arguments and body being return (foo == bar) ? TRUE : FALSE;
• buggers who add 1001st broken implementation of memcmp(), call it FooTurdCompare and prepend it with 20x80 block comment.
• buggers who use typedefs like WORD, DWORD, BYTE, IMANIDIOTSHOOTME and other crap from the same source (OK, they don't write the last one explicitly - not that it wasn't obvious from the rest of their, ahem, code).
• buggers who use Hungarian notation for no good reason and come up with structure fields that sound like street names from R'Lyeh
• buggers who introduce wrappers for standard kernel stuff - like, say it, typedef int Int32; and sprinkle their crap with per-architecture ifdefs.
• buggers who think that cpp is Just The Thing and produce turds that would make srb cringe in disgust.

Cool. I can really see it. "foo inc." releases a GPL driver for Linux and gets publically humiliated in the "linux source code hall of shame". Perfect. I can hear the laughter from Redmond over here (and it is 12000km away).

Press release:

"If you support Linux, you may get flamed and humiliated in public for doing so. Don't do it."

Grow up. There is more to life than coding style that is not "Al Viro compatible (TM)".

Sigh, sometimes, sometimes, I _really_ understand the BSD folks when they call the Linux community "a bunch of unkempt nerds that need to get a life". If they only would use sane init scripts. ;-)

You tell me, that SUN treated _CUSTOMERS_ and companies that wanted to support SunOS 4.1.x like that? If yes, then I definitely know why they went SysV. Surely noone wanted BSD any longer.

I would consider the internal development groups in SUN that treated each other like this also "in need of a change". :-)

A security issue is an universal accepted problem that most of the time has a reason and a solution.

Coding style, however, is a very personal thing that start with "shall we use TABs or not? (Jakarta: No. Linux: Yes ...) and goes on to "Is a preprocessor macro a good thing or not" until variable names (Al Viro: Names with more than five letters suck. :-) Java: Non-selfdescriptive names suck. Microsoft: Non-hungarian names suck) and so on.

And you really want to judge code just because someone likes to wrap code in preprocessor macros or use UPPERCASE variable names?

Come on. That's a _fundamental_ different issue than dipping vendors in their own shit if they messed up and their box/program has a security issue. Code that you consider ugly as hell may be seen as "easily understandable and maintainable" by the author. If it works and has no bugs, so what? Just because it is hard for you and me to understand (cf. "mindboggling unwind routines in the NTFS" (I thing Jeff Merkey stated it like this). It still seems to work quite well.

Are you willing to judge "ugliness" of kernel drivers? What is ugly? Are Donald Beckers' drivers ugly just because they use (at least on 2.2) their own pci helper library? Is the aic7xxx driver ugly because it needs libdb ? Or is ugly defined as "Larry and Al don't like them"? :-)

Flaming about coding style is about as pointless as flaming someone because he supports another sports team. There is no universal accepted coding style. Not even in C.

The kernel has an accepted coding style, both the documented and the tradition part of it. Using that makes life a lot lot easier for maintaining the code. Enforcing it there is a good idea, except for special cases (headers shared with NT has been one example of that).

There are also some nice tools around that will do the first stage import of a Hungarian NT'ese driver and linuxise it.

Fact of life: we all suck at reviewing our own code. You, me, Ken Thompson, anybody - we tend to overlook bugs in the code we'd written. Depending on the skill we can compensate - there are technics for that, but it doesn't change the fact that review by clued people who didn't write the thing tends to show bugs we'd missed for years.

If you really don't know that by your own experience - you don't _have_ experience. There is a damn good reason for uniform style within a project: peer review helps. I've lost the count of bugs in the drivers that I'd found just grepping the tree. Even on that level review catches tons of bugs. And I have no reason to doubt that authors of respective drivers would fix them as soon as they'd see said bugs.

"It's my code and I don't care if nobody else can read it" is an immediate firing offense in any sane place. It may be OK in academentia, but in the real life it's simply unacceptable.

It's all nice and dandy to shed tears for poor, abused, well-meaning company that had made everyone happy by correct but unreadable code and now gets humiliated by mean ingrates. Nice image, but in reality the picture is quite different. Code _is_ buggy. That much is a given, regardless of the origin of that code. The only question is how soon are these bugs fixed. And that directly depends on the amount of efforts required to read through that code.

Coming from the background of having threaded from scratch a complete networking stack (ie. my shit doesn't stink and I'm here to tell you about it :-))) I think your claims are pretty much out of whack.

Starting from initial implementation to having all the locking disappear from the kernel profiles during any given load was composed of three tasks:

1. Is this object almost entirely reader based (or the corrolary)? Use special locking that exploits this. See linux/brlock.h for one such "special locking" we invented to handle these cases optimally.

   This transformation results in ZERO shared dirty cache lines if the initial analysis is correct.

2. Can we "fan out" the locking so that people touching seperate objects %99 of the time touch different cache lines?

   This doesn't mean "more per-object locking", it means more like "more per-zone locking". Per-hashchain locking falls into this category and is very effective for any load I have ever seen.

3. Is this really a per-cpu "thing"? The per-cpu SKB header caches are an example of this. The per-cpu SLAB magazines are yet another.

Another source of scalability problems has nothing to do with whether you do some kind of clustering or not. You are still going to get into situations where multiple cpus want (for example) page 3 of libc.so :-) (what I'm trying to say is that it is a hardware issue in some classes of situations)

Frankly, after applying #1 and/or #2 and/or #3 above to what shows up to have contention (I claim the ipv4 stack to have had this done for it) there isn't much you are going to get back. I see zero reasons to add any more locks to ipv4, and I don't think we've overdone it in the networking either.

Even more boldly, I claim that Linux's current ipv4 scales further than anything coming out of Sun engineering. From my perspective Sun's scalability efforts are more in line with "rubber-stamp" per-object locking when things show up in the profiles than anything else. Their networking is really big and fat. For example the Solaris per-socket TCP information is nearly 4 times the size of that in Linux (last time I checked their headers). And as we all know their stuff sits on top of some thick infrastructure (ie. STREAMS) (OK, here is where someone pops up a realistic networking benchmark where we scale worse than Solaris. I would welcome such a retort because it'd probably end up being a really simple thing to fix.)

My main point: I think we currently scale as far as we could in the places we've done the work (which would include networking) and it isn't "too much locking".

The problem areas of scalability, for which no real solution is evident yet, involve the file name lookup tree data structures, ie. the dcache under Linux. All accesses here are tree based, and everyone starts from similar roots. So you can't per-node or per-branch lock as everyone traverses the same paths. Furthermore you can't use "special locks" as in #1 since this data structure is neither heavy reader nor heavy writer.

But the real point here is that SMP/cc clusters are not going to solve this name lookup scaling problem.

The dcache_lock shows up heavily on real workloads under current Linux. And it will show up just as badly on a SMP/cc cluster. SMP/cc clusters talk a lot about "put it into a special filesystem and scale that all you want" but I'm trying to show that frankly thats where the "no solution evident" scaling problems actually are today.

If LLNL was not too jazzed up about your proposal, I right now don't blame them. Because with the information I have right now, I think your claims about it's potential are bogus.

I really want to be shown wrong, simply because the name path locking issue is one that has been giving me mental gas for quite some time.

Another thing I've found is that SMP scalability changes that help the "8, 16, 32, 64" cpu case almost never harm the "4, 2" cpu cases. Rather, they tend to improve the smaller cpu number cases. Finally, as I think Ingo pointed out recently, some of the results of our SMP work has even improved the uniprocessor cases.

Hey, that's not a bug, that's a FEATURE!

You know what the most complex piece of engineering known to man in the whole solar system is?

Guess what - it's not Linux, it's not Solaris, and it's not your car.

It's you. And me.

And think about how you and me actually came about - not through any complex design.

Right. "sheer luck".

Well, sheer luck, AND:

• free availability and _crosspollination_ through sharing of "source code", although biologists call it DNA.
• a rather unforgiving user environment, that happily replaces bad versions of us with better working versions and thus culls the herd (biologists often call this "survival of the fittest")
• massive undirected parallel development ("trial and error")

I'm deadly serious: we humans have _never_ been able to replicate something more complicated than what we ourselves are, yet natural selection did it without even thinking.

Don't underestimate the power of survival of the fittest.

And don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit.

Quite frankly, Sun is doomed. And it has nothing to do with their engineering practices or their coding style.

Don't forget the fact that 2.4 is the first kernel you managed to get stable under high load since 1.2.

Both 2.0 and 2.2 didn't get stable until Alan took over and Alan's 2.4 fork got stable some 4 months before your 2.4 tree got stable.

I think you've pretty much proven how well random development works.

Linus kept ignoring, refusing and merging conflicting patches. The -ac tree since 2.4.9-ac or so with Rik's actual fixes he wanted Linus to takes passes the Red Hat test suite. 2.4.16 kind of passes it now.

It had nothing to do with the VM being broken and everything to do with what Linus applied. As it happens it looks like the new VM is better performing for low loads which is good, but the whole VM mess wasn't bad QA and wasn't bad design.

Linus was even ignoring patches that fixed comments in the VM code that referenced old behaviour. And due to the complete lack of VM documentation at the moment I can only assume he's been dropping Andrea's VM comments/docs too.

Directed evolution - ie evolution that has more specific goals, and faster penalties for perceived failure, works on the scale of tens or hundreds of years, not tens of thousands. Look at dog breeding, but look even more at livestock breeding, where just a few decades have made a big difference.

The belief that evolution is necessarily slow is totally unfounded.

HOWEVER, the belief that _too_ much direction is bad is certainly not unfounded: it tends to show up major design problems that do not show up with less control. Again, see overly aggressive breeding of some dogs causing bad characteristics, and especially the poultry industry.

And you have to realize that the above is with entities that are much more complex than your random software project, and where historically you have not been able to actually influence anything but selection itself.

Being able to influence not just selection, but actually influencing the _mutations_ that happen directly obviously cuts down the time by another large piece.

In short, your comment about "not pertinent" only shows that you are either not very well informed about biological changes, or, more likely, it's just a gut reaction without actually _thinking_ about it.

Biological evolution is alive and well, and does not take millions of years to make changes. In fact, most paleolontologists consider some of the changes due to natural disasters to have happened susprisingly fast, even in the _absense_ of "intelligent direction".

Of course, at the same time evolution _does_ heavily tend to favour "stable" life-forms (sharks and many amphibians have been around for millions of years). That's not because evolution is slow, but simply because good lifeforms work well in their environments, and if the environment doesn't change radically they have very few pressures to change.

There is no inherent "goodness" in change. In fact, there are a lot of reasons _against_ change, something we often forget in technology. The fact that evolution is slow when there is no big reason to evolve is a _goodness_, not a strike against it.

Let's just be honest, and admit that it wasn't designed.

Sure, there's design too - the design of UNIX made a scaffolding for the system, and more importantly it made it easier for people to communicate because people had a mental _model_ for what the system was like, which means that it's much easier to discuss changes.

But that's like saying that you know that you're going to build a car with four wheels and headlights - it's true, but the real bitch is in the details.

And I know better than most that what I envisioned 10 years ago has _nothing_ in common with what Linux is today. There was certainly no premeditated design there.

And I will claim that nobody else "designed" Linux any more than I did, and I doubt I'll have many people disagreeing. It grew. It grew with a lot of mutations - and because the mutations were less than random, they were faster and more directed than alpha-particles in DNA.

Trust me, it never was.

And I will go further and claim that _no_ major software project that has been successful in a general marketplace (as opposed to niches) has ever gone through those nice lifecycles they tell you about in CompSci classes. Have you _ever_ heard of a project that actually started off with trying to figure out what it should do, a rigorous design phase, and a implementation phase?

Dream on.

Software evolves. It isn't designed. The only question is how strictly you _control_ the evolution, and how open you are to external sources of mutations.

And too much control of the evolution will kill you. Inevitably, and without fail. Always. In biology, and in software.

Amen.

I'd say it is better because the mutations themselves (individual patches) go through a _very_ harsh evaluation before being applied in the "official" sources. There is a population of kernels out there (each developer has a few, distributions check out others, ...), only what survives there has got a chance to be considered for inclusion.

Sure, this is not the only way Linux moves forward. But it is a large factor in the success of "Release early. Release often. Take patches from everywhere."

Yeah, right, Linus. We should all go home and turn loose the monkeys and let them pound on the keyboard. They'll just as good a job, in fact, by your reasoning they'll get there faster, they aren't so likely to waste time trying to design it.

I can't believe the crap you are spewing on this one and I don't think you do either. If you do, you need a break. I'm all for letting people explore, let software evolve, that's all good. But somebody needs to keep an eye on it.

If that's not true, Linus, then bow out. You aren't needed and *you* just proved it. You can't have it both ways. Either you are here for a reason or you aren't. So which is it? You're arguing that you don't matter. I personally don't agree, I think Linux would be a pile of dog doo without you. If you don't agree, back off and see what happens.

Oh, absolutely.

I wish more people realized it. Some people realize it only when they get really pissed off at me and say "Go screw yourself, I can do this on my own". And you know what? They are right too, even if they come to that conclusion for what I consider the wrong reasons.

The reason I'm doing Linux is not because I think I'm "needed". It's because I enjoy it, and because I happen to believe that I'm better than most at it. Not necessarily better than everybody else around there, but good enough, and with the social ties to make me unbeatable right now.

But "indispensable"? Grow up, Larry. You give me too much credit.

And why should I bow out just because I'm not indispenable? Are you indispensable for the continued well-being of humanity? I believe not, although you are of course free to disagree. Should you thus "bow out" of your life just because you're strictly speaking not really needed?

Do I direct some stuff? Yes. But, quite frankly, so do many others. Alan Cox, Al Viro, David Miller, even you. And a lot of companies, which are part of the evolution whether they realize it or not. And all the users, who end up being part of the "fitness testing".

And yes, I actually do believe in what I'm saying.

The impressive part is that Linux development could _look_ to anybody like it is that organized.

Yes, people read literature too, but that tends to be quite spotty. t's done mainly for details like TCP congestion control timeouts etc - they are _important_ details, but at the same time we're talking about a few hundred lines out of 20 _million_.

And no, I'm no tclaiming that the rest is "random". But I _am_ claiming that there is no common goal, and that most development ends up being done for fairly random reasons - one persons particular interest or similar.

It's "directed mutation" on a microscopic level, but there is very little macroscopic direction. There are lots of individuals with some generic feeling about where they want to take the system (and I'm obviously one of them), but in the end we're all a bunch of people with not very good vision.

And that is GOOD.

A strong vision and a sure hand sound like good things on paper. It's just that I have never _ever_ met a technical person (including me) whom I would trust to know what is really the right thing to do in the long run.

Too strong a strong vision can kill you - you'll walk right over the edge, firm in the knowledge of the path in front of you.

I'd much rather have "brownian motion", where a lot of microscopic directed improvements end up pushing the system slowly in a direction that none of the individual developers really had the vision to see on their own.

And I'm a firm believer that in order for this to work _well_, you have to have a development group that is fairly strange and random.

To get back to the original claim - where Larry idolizes the Sun engineering team for their singlemindedness and strict control - and the claim that Linux seems ot get better "by luck": I really believe this is important.

The problem with "singlemindedness and strict control" (or "design") is that it sure gets you from point A to point B in a much straighter line, and with less expenditure of energy, but how the HELL are you going to consistently know where you actually want to end up? It's not like we know that B is our final destination.

In fact, most developers don't know even what the right _intermediate_ destinations are, much less the final one. And having somebody who shows you the "one true path" may be very nice for getting a project done, but I have this strong belief that while the "one true path" sometimes ends up being the right one (and with an intelligent leader it may _mostly_ be the right one), every once in a while it's definitely the wrong thing to do.

And if you only walk in single file, and in the same direction, you only need to make one mistake to die.

In contrast, if you walk in all directions at once, and kind of feel your way around, you may not get to the point you _thought_ you wanted, but you never make really bad mistakes, because you always ended up having to satisfy a lot of _different_ opinions. You get a more balanced system.

This is what I meant by inbreeding, and the problem that UNIX traditionally had with companies going for one niche.

(Linux companies also tend to aim for a niche, but they tend to aim for _different_ niches, so the end result is the very "many different directions" that I think is what you _want_ to have to survive).

the fundamental reasons why this happens are the following, special conditions of our planet:

• the human brain has a limited capacity, both in terms of 'storage' and 'computational power'.
• the world itself, at least how we understand it currently, is inherently random. (Such randomness is the main driving force of 'structure' as well, it seems.)
• this planet has limited resources, so 'survival of the fittest' is still the main driving force of 'life'.
• we do not know and understand the rules of our world yet, and chip technology (which drives and enables operating systems) is right at the edge (and often beyond the edge) of what physics is capable of explaining today. We simply do not know what breakthrough (or brick wall of performance) might happen in 1, 2 or 5 years. We did not know 50 years ago that something like 'SMP' would happen and be commonplace these days. I mean, often we dont even know what might happen in the next minute.

due to these fundamental issues the development of 'technology' becomes very, very unpredictable. We only have 5 billion brain cells, and there's no upgrade path for the time being. Software projects such as Linux are already complex enough to push this limit. And the capacity limits of the human brain, plus the striving towards something better (driven by human needs) cause thousands of ambitios people working on parts of Linux in parallel.

a few things are clear:

• if we knew the rules of this world and knew how to apply them to every detail then we'd be building the 'perfect chip' by this christmas, and there would probably be no need for anything else, ever.
• if the human brain (and human fingers) had no limits then we'd be designing the 'perfect OS' from grounds up and write it in 2 minutes.
• and if the world wasnt random then there would probably be nothing on this planet, ever.

but the reality is that we humans have severe limits, and we do not understand this random world yet, so we'll unevitably have lots of fun writing random pieces of Linux (or other) code in many many years to come.

in fact, most computer science books are a glaring example of how limited the human brain is, and how small and useless part of the world we are able to explain exactly ;-)

and frankly, i'd *very* disappointed if it was possible to predict the future beyond our lifetime, and if it was possible to design a perfect enough OS that does not need any changing in the foreseable future. I'd be a pretty disappointed and bored person, because someone would predict what happens and we'd only be dumbly following that grand plan. But the reality is that such grand plan does not exist. One of the exciting things about developing an OS is that we almost never know what's around the next corner.

This whole effort called Linux might look structured on the micro-level (this world *does* appear to have some rules apart of chaos), but it simply *cannot* be anything better than random on the macro (longterm) level. So we better admit this to ourselves and adapt to it.

And anyone who knows better knows something that is worth a dozen Nobel prizes.

After preparing my talk on CBQ/HTB (http://ds9a.nl/cbq-presentation), I finally understood how CBQ and filters etc truly work. And I wrote it down. Check out the Linux Advanced Routing & Shaping HOWTO, it's changed a lot!

Especially this part is very new, please check it for mistakes and inconsistencies:

http://ds9a.nl/2.4Routing/HOWTO//cvs/2.4routing/output/2.4routing-9.html

I even got 'split' and 'defmap' figured out, which should be a first. There is not a single other page online that tells you correctly what these do.

One thing - does *anybody* understand how hash tables work in tc filter, and what they do? Furthermore, I could use some help with the tc filter police things.

So if you do understand how these work, please drop me a line.

Thanks to Andreas Steinmetz and David Sauer, tc hash tables are now documented as well, thanks!

See:

http://ds9a.nl/2.4Routing/HOWTO//cvs/2.4routing/output/2.4routing-12.html

And then 'Hashing filters for very fast massive filtering'.

I also finished documenting all parameters for TBF, CBQ, SFQ, PRIO, bfifo, pfifo and pfifo_fast. All queues in the Linux kernel are now described in the Linux Advanced Routing & Shaping HOWTO, which can be found on

http://ds9a.nl/2.4Routing

I want to send this off to the LDP and Freshmeat somewhere next week, I *would really* like people who are knowledgeable about this subject (this means you, ANK & Jamal 8) ) to read through this.

This HOWTO is rapidly becoming the perceived authoritative source for traffic control in linux (google on 'Linux Routing' finds it), it might as well be right! So if you have any time at all, check the parts you know about. I expect mistakes.

Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I want to do this in separate steps to make it easier for architectures that have not been converted yet.

2.5.1 Semi-stable kernel, after bio is working.

2.5.2-pre1 Add the kbuild 2.5 code, still using Makefile-2.5. i386, sparc, sparc64 can use either kbuild 2.4 or 2.5, 2.5 is recommended. ia64 can only use kbuild 2.5. Other architectures continue to use kbuild 2.4. Wait 24 hours for any major problems then -

2.5.2-pre2 Remove kbuild 2.4 code, rename Makefile-2.5 to Makefile. i386, ia64, sparc, sparc64 can compile using kbuild 2.5. Other architectures cannot compile until they convert to kbuild 2.5. The kbuild group can help with the conversion but without access to a machine we cannot test other architectures. Until the other archs have been converted, they can stay on 2.5.2-pre1.

Doing the change in two steps provides a platform where both kbuild 2.4 and 2.5 work. This allows other architectures to parallel test the old and new kbuild during their conversion, I found that ability was very useful during conversion.

The CML1 to CML2 conversion comes later, either in 2.5.3 or 2.5.4.

Linus, is this acceptable?

There is a CML1 language specification, as written down in a file, namely Documentation/kbuild/config-language.txt in the kernel tree. There is one tool (mconfig) which has a yacc-parser that implements that specification completly, and some horrid ugly scripts in the tree that parse them in a more or less working way. There also are a number of other tools I don't know to much about that understand the language as well.

All of these tools just require the runtime contained in the LSB and no funky additional script languages. Also none needs a binary intermediate representation of the config.

I quote Linus at the 2.5 kernel summit: "Python is not an issue." Unless and until he changes his mind about that, waving around this kind of argument is likely to do your case more harm than good.

If you want to re-open the case for saving CML1, you'd be better off demonstrating how CML1 can be used to (a) automatically do implied side-effects when a symbol is changed, (b) guarantee that the user cannot generate a configuration that violates stated invariants, and (c) unify the configuration tree so that the equivalents of arch/* files never suffer from lag or skew when an architecture-independent feature is added to the kernel.

FWIW I have no particular problem with CML2. I agree that CML1 is fairly limited, and can see the advantages in ditching it for a new language.

I do have objections to some of the other ideas which have been floated for changing the behaviour of the config rules, which aren't strictly related to the change in language.

I just want to make sure that the introduction of CML2 doesn't sneak in controversial changes to the config behaviour to make my Aunt Tilley happy, when those changes should be given individual consideration, not presented as a fait accomplis.

If I can't have one without the other, I'd rather not have either - CML1 may indeed suck, but it doesn't suck _that_ much.

But I figure we can trust you not to do that - can't we?

The rules are nearly the same (but written in another language). The problem was in converting rules: esr found a lot of error: these error should be corrected, also some rules are different.

Also converting rules, you surelly found some error: i.e. wrong dependencies syntax, wrong implementation,....

I don't think esr changed non problematic rules, but one: all rules without help become automatically dependent to CONFIG_EXPERIMENTAL. I don't like it, but I understand why he makes this decision.

Remember: The config.in files contain a lot of errors, and automatic tools can not find all.

this change is not wired in. Comment out this declaration in the top-level rulesfile:

condition nohelp on EXPERT

and it reverts to old behavior.

Every new kernel version required new tools, 2.2 particularly many, 2.4 also some, so it's just one more tool to add in the end.

Current distributions already ship with Python2, and probably all will when distributors know that Python2 will be needed to configure Linux 2.5 or 2.6.

Oops. I wasn't going to tell anyone this yet, but since you've made this argument I feel I must be up front here....

After CML2 has proven itself in 2.5, I do plan to go back to Marcelo and lobby for him accepting it into 2.4, on the grounds that doing so will simplify his maintainance task no end. That's why I'm tracking both sides of the fork in the rulebase, so it will be an easy drop-in replacement for Marcelo as well as Linus.

Don't do it! A stable kernel should be stable also on the building tools. When Marcelo will correct some grave potential security problem, the user will rebuild the kernel and it will found that it must install some other package (machine with 2.4 are now common, python2 not yet so common) to secure his kernel, it would be happy.

This is an example, but for a better maintainability you will give serious problem to the novice kernel user.

Marcelo,

after a fairly lengthy off-list discussion, it turns out that special-casing printk is probably the best way to proceed to fix this one.

The problem is that the boot processor sets up the console drivers, and is able to call them via printk(), but the application processors at that time are not able to call printk() because the console device driver mappings are not set up. Undoing this inside the ia64 boot code is complex and fragile. Possibly the problem exists on other platforms but hasn't been discovered yet.

So the patch defines an architecture-specific macro `arch_consoles_callable()' which, if not defined, defaults to `1', so the impact to other platforms (and to uniprocessor ia64) is zero.

No if you can't access the console to print the message :)

Its just that I would prefer to see the thing fixed in arch-dependant code instead special casing core code.

Only architecture specific problems should be fixed with architecture specific code.

I'm not entirely sure whether this particular problem is architecture specific. Perhaps it is and, if so, I'm certainly happy to fix it in the ia64 specific code.

I can explain it. The old devfs core was forgiving of duplicate entries, while the new one is not (it now gives EEXIST errors).

There are some broken boot scripts (modelled after the long obsolete rc.devfs script) which dump a whole bunch of inodes in /dev, prior to loading various modules. So the drivers which load after this will not be able to create their devfs entries (because said entries already exist).

This is not actually a problem for leaf nodes, since the user-space created device nodes will still work. It just results in a warning message. It is potentially a problem for directories, if the following conditions are all met:

• boot scripts create a directory in /dev
• driver loads and tries to create same directory (fails)
• driver creates device nodes under that directory using the handle it obtained from creating the directory
• device nodes driver is trying to create were not created by boot script (i.e. the untar process).

This is a fairly rare case. Usually, if you are "restoring" some inodes, you will be restoring the individual device nodes as well as the parent directory (otherwise, what's the point of restoring?). So, in this case, the device nodes that the user wants to use will still be there (created by the boot script) and will work fine. There will just be a bunch of warning messages.

Possibly, depending on the driver, the device nodes it tried to create may appear in the /dev directory, rather than the intended subdirectory. While perhaps messy, this isn't actually harmful.

This thread was spawned because of a bug report with two issues. The first issue was the harmless warning messages about duplicate leaf node entries. Nothing broke.

The second issue was due to a broken devfsd configuration file which caused the wrong permissions to be set on a directory. This led to Roman thinking that the new devfs core was breaking stuff. As I've shown above, the breakage is a rare corner case involving an obsolete script.

In general, if you are tarring and untarring inodes, you take the whole directory and put it all back again. Even the partitioning event is a corner case, since you're most likely to install a new drive (and thus have no inodes to "restore") and then partition. And even the obsolete rc.devfs only saved away inodes which had been changed, not everything.

However, if this concerns you, I can send a patch that effectively restores the old behaviour for directories. It's just a matter of grabbing the right lock, fiddling a flag and returning a different entry. But I definately want to keep a warning message. I want there to be some pain for broken or really obsolete configurations.

Who is the maintainer of the driver ?

Try to think from my side: I may have no hardware or time to test all patches which come to me.

Please, people, send this kind of driver changes to the people who know all hardware specific details.

If there is no maintainer for i810, I'll be glad to apply it on 2.4.18pre and wait for reports. Not going to be on 2.4.17, though.