any chance of 2.6.0-test*?

Say, I've been having _smashing_ success with 2.5.x on the desktop and on big fat highmem umpteen-way SMP (NUMA even!) boxen, and I was wondering if you were considering 2.6.0-test* anytime soon.

I'd love to get this stuff out for users to hammer on ASAP, and things are looking really good AFAICT.

Any specific concerns/issues/wishlist items you want taken care of before doing it or is it a "generalized comfort level" kind of thing? Let me know, I'd be much obliged for specific directions to move in.

Thanks,
Bill

There's still a boatload of drivers that don't compile,
a metric shitload of bits that never came over from 2.4 after I stopped doing it circa 2.4.18, a lot of little 'trivial' patches that got left by the wayside, and a load of 'strange' bits that still need nailing down (personally, I have two boxes that won't boot a 2.5 kernel currently (One was pnpbios related, other needs more investigation), and another that falls on its face after 10 minutes idle uptime. My p4-ht desktop box is the only one that runs 2.5 without any problems.

I think we're a way off from a '2.6-test' phase personally, but instigating a harder 'code freeze' would probably be a good thing to do[1]

Dave

[1] Exemption granted for the bits not yet brought forward of course.

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

IDE is all broken still and will take at least another three months to fix - before we get to 'improve'. The entire tty layer locking is terminally broken and nobody has even started fixing it. Just try a mass of parallel tty/pty activity . It was problematic before, pre-empt has taken it to dead, defunct and buried.

Most of the drivers still don't build either.

I think its important that we get to the stage that we can actually say

- It compiles (as close to all the mainstream bits of it as possible)
- The stuff that is destined for the bitbucket is marked in Config and people agree it should go
- It works (certainly the common stuff)
- Its statistically unlikely to eat your computer
- It passes Cerberus uniprocessor and smp with/without pre-empt

Otherwise everyone wil rapidly decide that ".0-pre" means ".0 as in Windows" at which point you've just destroyed your testing base.

Given all the new stuff should be in, I'd like to see a Linus the meanie round of updating for a while which is simply about getting all the 2.4 fixes and the 2.5 driver compile bugs nailed, and if it doesn't fix a compile bug or a logic bug it doesn't go in.

No more "ISAPnP TNG" and module rewrites please

Alan

Highlighted and seconded...

I had a problem with PCI init, pnpbios ordering at some point, but i haven't tried a kernel with pnpbios in a while.

Thats interesting, i have a laptop experiencing the same symptoms, i'll be looking at it over the weekend.

Zwane

function.linuxpower.ca

or still lack 2.4 fixes.

What's happening with the OSS drivers ?
I'm still carrying a few hundred KB of changes from 2.4 for those. I'm not going to spent a day splitting them up, commenting them and pushing to Linus if we're going to be dropping various drivers.

I think this should wait until at least some more of the 2.4 changes come forward. Most of those are security issues and the likes, but there are a few driver corner cases too.

agreed.

Seconded.

Absolutly. Lets try and get 2.6 out the door _this_ year.

Dave

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

This is exactly the sort of thing I meant. There are still problems out there which a lot of people haven't reported, yet when they see someone else with that problem, suddenly the 'me too's come in.

I'm hoping the bugzilla will help out for corelating these as it starts to get used more.

Dave

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

I've been updating the via audio every now and again.

If sound/oss is staying for 2.6.0, we might as well merge the 2.4.x changes.

Jeff

I'd hope they would go away but it seems that will be post 2.6. The drivers do seem to mostly work in 2.5.x. I'm meaning the stuff that doesn't compile and nobody gives a damn about.

I consider them to be old drivers, the same way "hd.c" was. Not necessarily useful for most people, but neither was hd.c. And it was around for a _long_ time (heh. I needed to check. The config option is still there ;)

So I don't see a huge reason to remove them from the sources, but we might well make them harder to select by mistake, for example. Right now the config help files aren't exactly helpful, and the OSS choice is before the ALSA one, which looks wrong.

They should probably be marked deprecated, and if they don't get a lot of maintenance, that's fine.

Linus

As is the whole frame buffer mess. USB slowly seems to return to a working state. ISDN seems to be a total mess, as well.

Full ACK. There are still archs without working module code, right now (parisc and mips come to my mind).

--jochen

Note that other architectures have never been an issue for releasing new kernels, and that is _particularly_ true of architectures like parisc and mips that haven't even _tried_ to track development kernels. In fact, mips "anti-maintenance" has often actively discouraged people from even bothering to update mips code when adding new features.

Linus

As there is a CONFIG_EXPERIMENTAL, how about a CONFIG_DEPRECATED for the opposite edge ?

J.A. Magallon <[email protected]>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre2-jam2 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-2mdk))

of

I heartly second this. And would be willing to do it when time permits.

Matthew

CONFIG_OBSOLETE already exists for this.

I've looked into this, and wow, it's not a simple fix :(

But this is really the first it's been mentioned, I can't see holding up 2.6 for this. It's a 2.7 job at the earliest, unless someone wants to step up and do it right now...

thanks,

greg k-h

2.5.x crashes erratically and randomly under high tty/pty load. At the moment I'm assuming this is the tty code. That means we can't decide not to fix it since its already fatally broken.

Alan

Hmm.. The tty layer still depends on the kernel lock, and we're clearly not changing that at this point any more.

I don't see what the fundamental problem is, it sounds like there's just some part that got the lock yanked, probably as part of the normal VFS kernel-lock-avoidance patches. Looking at tty_io.c (which pretty much drives everything else), it does seem to take the lock _most_ of the time, including read and write time.

The only place that looked like it _really_ didn't get the kernel lock was apparently tty_open(), which is admittedly a fairly important part of it ;)

Alan, do you have a test-load? Might be worth just renaming "tty_open()" to "do_tty_open()", and then do a

	tty_open(..)
	{
		lock_kernel();
		retval = do_tty_open(..);
		unlock_kernel();
		return retval;
	}

thing.

Quite frankly, very little has changed in the 2.5.x tty layer (serial stuff, yes, tty no), so its locking should work basically as well as 2.4.x does. Except for infrastructure changes like the VFS lock removal (where 2.4.x will hold the kernel lock itself over open, 2.5.x won't).

Yeah, preemption has this tendency to show locking problems more easily, and it could clearly be the case that it's broken in 2.4.x too but basically impossible to trigger. But the _simple_ explanation is that tty_open() (and perhaps some other cases like ioctl) just missed the kernel lock.

Linus

2.5 does hold the BKL on ->open of charater- (and block-) devices.

The real problem is that the big irqlock is gone and mingo just replaced it with local_irq_save & friends, which is not enough.

chrdev_open() kindly takes the BKL for tty_open() so there isn't an issue here.

There were, however, parts of the code which were using the global-cli(), and these merely got converted to local_irq_save() without (iirc) too much auditing. They're all marked with FIXME in my current sources.

One thing that regularly bugs me about our current tty implementation, however, is the handling of SIGWINCH. This is sent to the process group rather than the session. Take the following example:

- you're running an xterm, with a shell inside.
- you're running 3 ssh connections, 2 suspended, one running.
- you resize the xterm

The WINCH signal will be sent to just the one foreground ssh connection.

- you suspend the current ssh.

The shell believes that the terminal is the _old_ size.

- you resume one of the old ssh sessions.

Likewise, ssh doesn't believe the terminal has changed size.

My current "workaround" is to re-tweak the xterm size each time I resume or suspend an old process.

POSIX (at least signal and general terminal interface sections) seems to be rather quiet on the behaviour of WINCH.

Are there any reasons why we shouldn't send WINCH to the whole session rather than just the pgrp associated with the tty?

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Ahh, my bad.

Ok, most of them should be fixable with a simple spinlock approach.

If the recursion is too nasty to handle, we could make some tty-specific recursive spinlock as a stop-gap measure, and mark it as being destined for the garbage-heap in 2.7.x:

	/*
	 * This isn't even _trying_ to be fast!
	 */
	struct recursive_spinlock {
		spinlock_t lock;
		int lock_count;
		struct task_struct *lock_owner;
	};

	static struct recursive_spinlock tty_lock = {
		.lock = SPIN_LOCK_UNLOCKED,
		.lock_count = 0,
		.lock_owner = NULL
	};

	unsigned long tty_spin_lock(void)
	{
		unsigned long flags;
		struct task_struct *tsk;

		local_irq_save(flags);
		preempt_disable();
		tsk = current;
		if (spin_trylock(&tty_lock.lock))
			goto got_lock;
		if (tsk == tty_lock.lock_owner) {
			WARN_ON(!tty_lock.lock_count);
			tty_lock.lock_count++;
			return flags;
		}
		spin_lock(&tty_lock.lock);
	got_lock:
		WARN_ON(tty_lock.lock_owner);
		WARN_ON(tty_lock.lock_count);
		tty_lock.lock_owner = tsk;
		tty_lock.lock_count = 1;
		return flags;
	}

	void tty_spin_unlock(unsigned long flags)
	{
		WARN_ON(tty_lock.lock_owner != current);
		WARN_ON(!tty_lock.lock_count);
		if (!--tty_lock.lock_count) {
			tty_lock.lock_owner = NULL;
			spin_unlock(&tty_lock.lock);
		}
		preempt_enable();
		local_irq_restore(flags);
	}

and be done with it.

Anybody willing to test it and see if the above works?

Linus

Linus,

I'm REALLY opposed to the use of the word "goto" in any code where it's not needed. OF course, I'm a linux kernel newbie, so I'm in no position to comment

Let me comment below the relevant code snippet below as to how I would change it:

	    	   <etc...>

I would change it to something like the following (without testing the code through a compiler or anything to see if it's valid):

			if (!(spin_trylock(&tty_lock.lock))){
				if (tsk ==tty_lock.lock_owner){
					WRAN_ON(!tty_lock.lcok_count);
					tty_lock.lock_count++;
					return flags;
				}
			}
			WARN_ON(tty_lock.lock_owner);	
			<etc...>

Am I wrong that the above would do the same thing without generating the sphagetti code that a goto would give you. Gotos are BAD, very very bad. Please note also that the two if statements above could probably even be combined further into one statement by using a short circuit && in the if.

If I'm misinterpreting the original code, then forgive me.. I just saw a goto and gasped. There's always a better option than goto.

-Rob

Minor change to my original message below.. I left a line out of a code change suggestion.

oops - Yes, I forgot to add one line here (my point remains the same:

			  spin_lock(&tty_lock.lock);

Who cares?

I do.

-Rob

I think goto's are fine, and they are often more readable than large amounts of indentation. That's _especially_ true if the code flow isn't actually naturally indented (in this case it is, so I don't think using goto is in any way _clearer_ than not, but in general goto's can be quite good for readability).

Of course, in stupid languages like Pascal, where labels cannot be descriptive, goto's can be bad. But that's not the fault of the goto, that's the braindamage of the language designer.

Linus

Whom do I pay to have this annoying clueless asshole shot? OH MY GOD, I really can't take any more.

Tomas Szepe <[email protected]>

In evolution its

Tools->Create filter from message->Filter on sender

Add action
Move to folder QUAINT

and then just read it when drunk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The horrific response to the use of "goto" is deprecated in favor of proper use. A function overloaded with gotos probably should be reworked. But there there is no need to outright avoid the use of 'goto'. if() is simply a conditional test with a goto A or goto B logic.

There is a reason for the implementation of goto. When it all boils down to it, in assembler it's all a matter of JMP with or without a condition.

David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+IcjV74cGT/9uvgsRAtPFAKDATzN7dkRyfRk7WXEDGyYe0oGiqACffj+X iXkDBQntdGnHeJFKjfmp0Lg=
=l9hb
-----END PGP SIGNATURE-----

You're a relatively succesful guy, so I guess I shouldn't argue with your style.

However, I have always been taught, and have always believed that "goto"s are inherently evil. They are the creators of spaghetti code (you start reading through the code to understand it (months or years after its written), and suddenly you jump to somewhere totally unrelated, and then jump somewhere else backwards, and it all gets ugly quickly). This makes later debugging of code total hell.

Would it be so terrible for you to change the code you had there to _not_ use a goto and instead use something similar to what I suggested? Never mind the philosophical arguments, I'm just talking good coding style for a relatively small piece of code.

If you want, but comments in your code to meaningfully describe what's happening instead of goto labels.

In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read.

-Rob

Mail filters are a wonderful thing, use them on me and you want have to have me shot. We'll both be happier in the end.

What exactly is it that you can't take? I made a minor suggestion in the above message, very minor, and only a suggestion -- one that was free to be ignorred. There are over 300 messages a day on this list, why do the few ones from _me_ bother you.

-Rob

But if the if() is already there, there is no need to have an additional goto in the statement, My version may even be faster than linus' version because it may save an extra assembler line of code (the beq or whatever branch statement generated by the if would do the branch during the if rather than after the if was evaluated and got to the first statement which was the goto). Of course, compiler optimizatoins probably make that particular point pointless to discuss.

But in this case, the condition was already there.. My point is that if you don't need a goto, you shouldn't use it. Whenever there's an obvious way not to use it, don't.

-Rob

Now, it's provable you never *NEED* a goto. On the other hand, *judicious* use of goto can prevent code that is so cluttered with stuff of the form:

        if(...) {
		...
		die_flag = 1;
		if (!die _flag) {...

Pretty soon, you have die_1_flag, die_2_flag, die_3_flag and so on, rather than 3 or 4 "goto bail_now;".

The real problem is that C doesn't have a good multi-level "break" construct. On the other hand, I don't know of any language that has a good one - some allow "break 3;" to break 3 levels- but that's still bad because you get screwed if somebody adds an 'if' clause....

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gotos aren't the root of code evil. Poor design style is and poor preparation is the root of spaghetti code. Use the right tool for the job which includes 'goto'. Every teacher that I've met who has an objection to the use of gotos has been quite naive, often recommends avoiding pointers, frequently suggests you restrict your strings to 255 characters or less, etc, etc. The oddball extras vary from teacher to teacher, but the overall impression of the teacher makes me want to avoid them even with that 10 foot pole.

It's not the fault of the student for being taught wrong, but it is the fault of the student for ignoring possibile variances of others. Particularly the "worldly wise"; people who actually write code for the real world v.s. lectures.

David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+Ic4P74cGT/9uvgsRAt1QAKCb7ryMMG5iBwTefYgDB7HLuDkRngCeNSq/ M/euGkdIdXpv6IZ1Rw9ikEo=
=Yy9i
-----END PGP SIGNATURE-----

Not necessarily. A good multilevel break/continue implementation will only work on loop blocks, not conditionals.

Tomas Szepe <[email protected]>

No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue.

Any if-statement is a goto. As are all structured loops.

Ans sometimes structure is good. When it's good, you should use it.

And sometimes structure is _bad_, and gets into the way, and using a "goto" is just much clearer.

For example, it is quite common to have conditionals THAT DO NOT NEST.

In which case you have two possibilities

- use goto, and be happy, since it doesn't enforce nesting

This makes the code _more_ readable, since the code just does what the algorithm says it should do.

- duplicate the code, and rewrite it in a nesting form so that you can use the structured jumps.

This often makes the code much LESS readable, harder to maintain, and bigger.

The Pascal language is a prime example of the latter problem. Because it doesn't have a "break" statement, loops in (traditional) Pascal end up often looking like total shit, because you have to add totally arbitrary logic to say "I'm done now".

Linus

longjump. Used with good effect in the plan9 code.

Probably takes more coordination than is possible in Linux and has marginal benefit, but it looks nice.

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com  www.rtlinux.com
1+ 505 838 9109

commence [email protected] quotation:

Perl's facility for labelling blocks and jumping to the beginning or end with 'next' and 'last' may be close to what you want, but I don't know if it's ever been implemented in a language one could sensibly use to write a kernel.

 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <[email protected]>     |      answers a prison for oneself.
 \                          |

You should not code to avoid a construction that's valid C. Just use the control structure that comes natural. Of course "if (c % 2) goto a;" is a crime, but things like "if (!buffer) goto err_out_nomem;" are better because the tell you why the code jumps here, it includes an implicit comment.

if (buffer) {
	/* do stuff */
} else {
	return -ENOMEM;
}

just obscures the logic of the code.
Or look at it another way, if you dislike goto you should crusade against conditional return as well.

Regards
Oliver

I thought Edsger Dijkstra coined the "gotos are evil" bit in his structured programming push?

Nonetheless, they would both be wrong...

Robert Love

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Naturally. Evaluate the assembler when it's done. Normally an unconditional jump takes less cycles than a conditional jump. It's hard to argue with that. Use the right tool for the job. If the code expression necessitates a goto within a block of code to keep things neat and orderly, then do it.

Regarding the if () { ... }, there are no braces around the assembler code. It's all a matter of linear instructions with jumps. An if() { ... } is a prettiness for our human eyes to organize code.

David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+IdFM74cGT/9uvgsRAuMkAJ4nKED1gEVvNKJiYqXg6J73aQgTRQCfWrrJ zYoHzuMjZ+ikKHCQ1O9E2C4=
=PBlz
-----END PGP SIGNATURE-----

We use goto's extensively in the kernel. They generate fast, tight code.

There is nothing wrong with being a newbie, but there is something wrong with voicing ignorance. "Learn first, form opinions later".

When you start posting more than most of the developers here, combined, and none of your posts are contributive kernel code, there is a problem.

Robert Love

Yeah, he did, but he's dead, and we shouldn't talk ill of the dead. So these days I can only rant about Niklaus Wirth, who took the "structured programming" thing and enforced it in his languages (Pascal and Modula-2), and thus forced his evil on untold generations of poor CS students who had to learn langauges that weren't actually useful for real work.

(Yeah, yeah, most _practical_ versions of Pascal ended up having all the stuff necessary to break structure, but as you may be able to tell, I was one of the unwashed masses who had to write in "standard Pascal" in my youth. I'm scarred for life).

Linus

[[email protected]]

There are a lot more where he came from; you can't get rid of them all, it'd be genocide. procmail and get it over with. It's been a sad fact of life since they let those AOL and compuserve FPOS's on the net.

Bill

Ok, so you disagree with his style is what you're saying. You are free to disagree, that's your right. We're just from different schools.

"structured" being a key word. I like structure in code. Let's face it, everyone likes code to be well structured, that's why there's the "CodingStyle" document -- people like the code to look a certain way so they can read it later. Without structure, you don't have that

Ok, we agree there.

I can't foresee many scenarios where this would be the case. Someone spoke, for example, about being indented too far and needing to jump out because there isn't a good "break" mechanism... Well, as it says in the coding style document -- if you're indented more then 3 levels in, "you're screwed anyway, and should fix your program".

In the code snippet you put up, I don't see structure as having been bad and a goto as having been clearer.

Could someone (Linus, I know your busy, so I won't ask you -- in fact, I'm amazed you'd bother to write to _me_ at all) please point me to sample code that illustrates this. I'm trying to envision "conditionals that do not nest that need goto". As near as I can tell, there must be some condition that the goto nests all the conditions in otherwise the goto wouldn't be needed. In some cases, Maybe what's between the goto and whats gone to should be broken up into a new function (modularized) and called independently of function that the goto was in.

As someone else pointed out, it's provable that goto isn't needed, and given that C is a minimalist language, I'm not sure why it was included.

But at least the code is "readable" when you do that. Sure it's a little more work on the part of the programmer. But anyone reading the code can say "oh, so the loop exits when condition x is met", rather than digging through the code looking for any place their might be a goto.

Of course, I'm not about to argue that the kernel should be rewritten in PASCAL, nor am I interested in reinventing the wheel. We've got a good system here, let's just keep it good and make it better. (Notice I say "we" as if I've contributed something to it, whereas really I mean we including myself as an end-user.)

-Rob

Hmm.. I'm not a Perl wizard.. <reads the docs> Yeah, that's what I meant, and no, that's not a sane kernel language. ;)

Mr. Love,

I posted a minor change to the floppy driver which no one commented on earlier (probably in wrong form)-- three times now (once in unified diff format).. And you might even say that the message you quoted was kernel code that I was posting since I posted alternate code to linus' code.

As per whether I post more than the developers here, it's only because I don't have a job, so I've got more free time than they do. I can't help it. If they're busier than me, I wouldn't expect them to waste time writing conversational messages about the kernel.

-Rob

Bob,

At first, read Documentation/CodingStyle of the kernel.
Then have a look into:

fs/open.c file do_sys_truncate() function.

Explain how you can do that cleanly, understandably, and without code duplication, or ugly kludges without using those goto ? (And sticking to coding-style.)

Also take into account, that there the most common execution path is direct, and exceptions are redirected elsewere.

Original "gotos are evil" comes from days of FORTRAN (and BASIC) coding, where labels were all numeric, and definitely non-descriptive. Where nested conditionals didn't exist, etc. Source-code nesting didn't exist either...

Doing things in moderation will usually produce better code, than strict sticking into some paradigm or other.

Of course in schools there is definite need for severe whaking of sense into heads of the young would-be coders. Clean reusable and maintainable code is _hard_ to produce without any sort of role-models and rules, especially when kids teach coding for themselves by looking into other kids code of "look how clever spaghetti I made" stuff.

When you learn the ropes (rules), and code enough (some years), you will finally learn where you can relax the rules a bit. Especially where the rules _must_ be altered to allow some formerly boo-boo styles.

...

Yes there are, but we are coding in C, nor C++ or Java...

/Matti Aarnio

That's fine for this particular troll, but some of the more well-known trolls here are so good at what they do that you sometimes have to read their messages while sober -- the errors can be subtle and well-hidden. So much so, sometimes, that I suspect it's done on purpose.

Besides, filtering in the MUA is blatantly the wrong place to do it. The MTA (or MDA) should be doing the filtering.¹

--
dwmw2
¹ Yes, I'm bored of the other off-topic flames :)

I've only compiled (and haven't tested this code), but it should be much faster than the original code. Why? Because we're eliminating an extra "jump" in several places in the code every time open would be called. Yes, it's more code, so the kernel is a little bigger, but it should be faster at the same time, and memory should be less of an issue nowadays.

Here's the patch if you want to apply it (i have only compile tested it, I haven't booted with it).. This patch applied to the 2.5.56 kernel.

@@ -100,44 +100,58 @@
 
 	error = -EINVAL;
 	if (length < 0)	/* sorry, but loff_t says... */
-		goto out;
+		return error;
 
 	error = user_path_walk(path, &nd);
 	if (error)
-		goto out;
+		return error;
 	inode = nd.dentry->d_inode;
 
 	/* For directories it's -EISDIR, for other non-regulars - -EINVAL */
 	error = -EISDIR;
-	if (S_ISDIR(inode->i_mode))
-		goto dput_and_out;
+	if (S_ISDIR(inode->i_mode)){
+		path_release(&nd);
+		return error;
+	}
 
 	error = -EINVAL;
-	if (!S_ISREG(inode->i_mode))
-		goto dput_and_out;
+	if (!S_ISREG(inode->i_mode)){
+		path_release(&nd);
+		return error;
+	}
 
 	error = permission(inode,MAY_WRITE);
-	if (error)
-		goto dput_and_out;
+	if (error){
+		path_release(&nd);
+		return error;
+	}
 
 	error = -EROFS;
-	if (IS_RDONLY(inode))
-		goto dput_and_out;
+	if (IS_RDONLY(inode)){
+		path_release(&nd);
+		return error;
+	}
 
 	error = -EPERM;
-	if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
-		goto dput_and_out;
+	if (IS_IMMUTABLE(inode) || IS_APPEND(inode)){
+		path_release(&nd);
+		return error;
+	}
 
 	/*
 	 * Make sure that there are no leases.
 	 */
 	error = break_lease(inode, FMODE_WRITE);
-	if (error)
-		goto dput_and_out;
+	if (error){
+		path_release(&nd);
+		return error;
+	}
 
 	error = get_write_access(inode);
-	if (error)
-		goto dput_and_out;
+	if (error){
+		path_release(&nd);
+		return error;
+	}
 
 	error = locks_verify_truncate(inode, NULL, length);
 	if (!error) {

@@ -146,9 +160,7 @@
 	}
 	put_write_access(inode);
 
-dput_and_out:
 	path_release(&nd);
-out:
 	return error;
 }
 

If the main flow of the code is through a bunch of hard to trace gotos and you choose to blame the tool instead of the programmer, I guess you could blame goto.

However, the goto can also be a great tool to make the code more readable. The goto statement is, IMHO, one of the more elegant ways to code exceptions into a C function; that is, dealing with error situations that don't happen very often, in such a way that the error handling code doesn't clutter up the main code path.

As an example, you could look at fs/super.c::do_kern_mount()

        mnt = alloc_vfsmnt(name);
        if (!mnt)
                goto out;
        sb = type->get_sb(type, flags, name, data);
        if (IS_ERR(sb))
                goto out_mnt;

Do you see how the absence of the error handling cleanup code makes the normal code path easier to read ?

regards,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

of error handling code is easier to maintain.

regards,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

There's no reason, though, that the error handling/cleanup code can't be in an entirely separate function, and if speed is needed, there's no reason it can't be an "inline" function. Or am I oversimplifying things again?

-Rob

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<sarcasm> An even worse misuse, exiting the function from random locations avoiding logic completion </sarcasm>

David

Remind me why this is better than a goto?

<quote who="Rob Wilkens">

you do, if you inline the code and every drive writer use this tecnique the kernel will be much bigger don't you think ?!?

Makeing a simple function instead is quite slower I think... don't forget that goto are used only in error recovery routines ...

You can simply build a "stack" of labels .. IMHO this is a great way to be sure of the right order we are performing cleanup/recovery ...

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

Congratulations. You've possibly increased the speed of an error path by an infintessimal amount at the expense of increasing the size of kernel image and making the code harder to read and maintain. (I say "possibly" since with caching effects you may have actually slowed the code down.)

Harder to read: The primary code path is polluted with repetative code that has no bearing on its primary mission.

Harder to maintain: Add an extra resource allocation near the top and now you have to hunt out every failure case and manually update them all (with yet more duplicate code) instead of just amending the cleanup code at the end of the function.

In the case of an inline function, you're saving a jump, because the code that you would "goto" is right there in sequence with the code you are executing as far as the processor is concerned. In essence, you're duplicating code, but you're not retyping code, and your keeping code consistent accross all uses of it (keeping it modular).

It's trivial, but where you're trying to cut down on the total number of instructions executed in kernel mode, you would think even where you could save one instructon (and branches are expensive, no?) you would want to.

-Rob

Am Sonntag, 12. Januar 2003 22:44 schrieb Rob Wilkens:

Yes. Typical error cleanup looks like:
err_out:

	up(&sem);
	return err;

Releasing a lock in another function is a crime punished by slow death. (Some might even resort to voodoo to make sure your shadow suffers in the beyond.)
It makes code absolutely unreadable.

Regards
Oliver

Kernel size (footprint in memory) would grow a tad bit (not much), but it's overall speed would also go up.

That wasn't the case in Torvalds' sample code which started this thread. That was spin-locking code, I believe. Of course, in that case, there was no need for an inline function or anything, but rather restructuring of an if statement.

If the kernel developer "knows" always that they have to follow the stack order when adding additional cases, it's fine. But it is more obvious in the patch I wrote what is going on than in the original "goto" version of the code with the fs/open.c code someone asked me to look at. This makes it harder for people unfamiliar with the complete linux kernel design in this area to get started. Of course, I'm getting a crash course it seems.

-Rob

These are usually error conditions. If you inline them, you will have to jump *over* them as part of the normal code path. You don't save any instructions, and you end up with a kernel which has much more duplicated code and thus thrashes the cache more. It also makes the code harder to read. goto makes it easy "stack" error handlers and not worry about the order in which you do clean up.

Not to mention that the 'return err;' statement is hard to move to an inline function meaningfully.

Hey, if the compiler does it's job right, I increased the speed of something in the kernel. And, as a kernel newbie, I'm proud of that. I also did it in under 12 minutes (from time stamp of message received to time stamp of message sent after code compiled and diff'd).

I thought it was easier to read. For me, I can read "ok, this condition happens, I fail"... Or "if this other condition happens, I release my path, then I fail"...

Whereas the "goto out" was very unclear. It made me page down to figure out what was going on.

That's the whole point.. To just browse the code.. I shouldn't have to page down to understand what the code right in front of me is doing. "goto out" is unclear. "retun error" is clear. "path_release" seems like a relatively plain english function name and I can guess what it does without knowing exactly what it does. I can also surmise that if I go beyond a certain point in the function that I need to path_release() the same way a non-kernel programmer might need to free memory allocated inside of a function before returning to the calling function.

It really is that simple.

It took me 12 minutes from message received to message sent to update the entire block of code to handle the new case. How long do you think it would take to make a minor modification that would only have to do a portion of what I did? Is it such a burden on the developer to make the code more readable?

-Rob

Rob,
You should really try to post one controversial thing at a time... :) Anyway, all programming languages (minimalistic or not) are Turing complete, maybe you want to program in Turing-machine language?

On a side note, I do hope you realize that Linus & Co. are considered by smart people in the business as being some of the best. And for good reason, too. That is to say, they are held in high esteem by a lot of very, _very_ smart people, based on their continuous review of the exceptional work done on the kernel. Now, doesn't it strike you a little bit odd that you come in here and find all this obvious "problems"? How come you are the only one seeing all thing things that any 1st year CS student should be able to spot, yet hundreds of the brightest minds in the business failed to notice?

Dimi.

I say "please don't use goto" and instead have a "cleanup_lock" function and add that before all the return statements.. It should not be a burden. Yes, it's asking the developer to work a little harder, but the end result is better code.

-Rob

Benchmark them - original and your revised. (Their equivalents, that is,
in userspace with rdtscll() )

Put them into a test-harness calling them million times (or some such). Look also what assembly the compiler produced, e.g. that it didn't optimize away error paths.

That is common fallacy. Learn to code in environments where you have to account for every byte of code and ram usage, and your code will be fast even in bigger systems.

....

/Matti Aarnio

No, it would go down. The damage may not be too great thanks to GCSE, but even that isn't sure especially if asms (via locking code) are involved. You really need to brush up on current computer architectures. Look in particular the L1 caches structures, cacheline sizes, cache sizes and branch prediction. And of course current compiler technology, so that you actually know what code is generated.

OG.

PS: I know, don't feed the troll, sorry.

"Never argue with an idiot. They drag you down to their level, then beat you with experience." -- Martin Josefsson

T.

Wrong. Thats the trouble with programming an abstract level. People just don't understand the real world. Cache is everything, small cache footprint is king.

Alan

<quote who="Rob Wilkens">

goto out_path_release is finer to you ?!? :)

I think you have no idea of the mole of the linux kernel and the number of daily patches the mantainers receive ...

I'm also a beginner, and me too at the very first time hated the goto (every one have told me they are evil !!) but after aving taken a look at the kernel and reading LinuxDevice Driver I think that the style the linux kernel is coded is cryptic for beginners, but it is perfect !

It is a wonderful experience to browse the linux kernel sources .. and every time I didn't understand why a thing was done in such a way .. well I discover later (with experience) that it was done in the best way it could ever be done !!!

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

You're wrong. You wouldn't have to jump over them any more than you have to jump over the "goto" statement. They would be where the goto statement is. Instead of the goto you would have the function.

If that argument was taken to it's logical conclusion (and I did, in my mind just now), no one should add any code the grows the kernel at all.

-Rob

Not that hard: You just "return functionname()" where functionname is the name of your inline function that returns the value you want to return.

-Rob

Am Sonntag, 12. Januar 2003 23:21 schrieb Rob Wilkens:

Nope you didn't.
Any compiler that can move outline code like

if (con) {
	cleanup()
	return err;
}
can easily simplify
if (con)
	goto err_out;

into a single branch. Still you have enlarged the kernel a bit. With the same number of jumps, as a rule of thumb, the smaller code is faster.

Regards
Oliver

Rob Wilkens <[email protected]> :
[...]

Herbal colon cleanser doesn't count as an efficient drug for linux kernel code programming.

--
Ueimor

Am Sonntag, 12. Januar 2003 23:22 schrieb Rob Wilkens:

It's code that causes added hardship for anybody checking the locking. It becomes impossible to see whether locks are balanced and turns into a nightmare as soon as you need error exits from several depths of locking or with and without memory to be freed.

Please listen to experience.

err_out_buffer:

	kfree(buffer);
err_out_nobuffer:
	up(&sem);
err_out_nolock:
	return err;

is pretty much the only readable construction.

Regards
Oliver

Hi !

On Sun, Jan 12, 2003 at 03:48:24PM -0500, Rob Wilkens wrote:
[...]

Look at any tree walking function or macro. Try to write an efficient one yourself, with lots of time the same tests and code to walk left, right, up or down. Always the same thing : just move pointers around and go on to the loop. Of course you can write it in your "clear structured" code, but I bet many people won't understand it because of the multiple nested tests. But a simple goto in each if statement to go to a common place is far cleaner. It's about the same as the final instruction in the for loop.

Of course it's provable. Anyway, any algorithm can also be written with a very complex S-K program ! But if you'd know how a processor works, you'd understand the evidence : about 1/5 of instructions is a branch (goto). The basics of computing are test, set and branch. Your while, for, if ... all do a mix of these. Why do you want to put the branch as a special case ? it's as much needed as others. And the only instruction which does only branch without test nor set is goto.

What you do with your methods, is replacing a branch with a set, test then branch. More efficient ? I don't think so ! More readable ? I don't think so. Linus is right, you've been brainwashed :-)

In fact, at school, thet tell you not to use goto to force you to learn how to use useful things such as the while loop. If you had used BASIC in the past, you'd remember how awful these programs were, not because of all the gotos, but because since we were never told the beauty of other methods, we simply used crappy gotos everywhere within left-justified code.

and the CPU ! Fortunately, Borland added the break and continue statements so that their compiler could be used to produce good programs.

I prefer a "goto end_of_loop" than a "end_of_loop=1" followed by nested "if (!end_of_loop)" for each following blocks ! This way, you focus on what the code really does and not how the programmer could trick the compiler to tell the CPU what he wanted to really do.

Now, you asked for an example. Here is one. Please recode it without the gotos, try to keep it at least as readable, and then bench it ! I'll send you public apologies if you can make it either faster and as much readable, or as fast and much more readable. (yes, all the code sits within a for condition, just to allow 'break' within the loop !). As you see, I don't really mind writing awful primitives if they help upper levels being much cleaner and efficient.

Cheers,
Willy

#define tree_foreach_destructive(__type, __root, __data, __stack, __slen)               \
    for (__slen = 0, __stack[0] = __root, __data = NULL; ({             \
        __label__ __left, __right, __again, __end;                      \
        typeof(__root) __ptr = __stack[__slen];                         \
__again:                                                                \
        __data = __ptr->data;                                           \
        if (__data != NULL) {                                           \
            __ptr->data = NULL;                                         \
            goto __end;                                                 \
        }                                                               \
        else if (__ptr->left != NULL) {                                 \
            __stack[++__slen] = __ptr = __ptr->left;                    \
            goto __again;                                               \
        }                                                               \
        else                                                            \
__left:                                                                 \
        if (__ptr->right != NULL) {                                     \
            __stack[++__slen] = __ptr = __ptr->right;                   \
            goto __again;                                               \
        }                                                               \
        else                                                            \
__right:                                                                \
        if (!__slen--)                                                  \
            goto __end; /* nothing left, don't delete the root node */  \
        else {                                                          \
            typeof (__root) __old;                                      \
            pool_free(__type, __ptr);                                   \
            __old = __ptr;                                              \
            __ptr = __stack[__slen];                                    \
            if (__ptr->left == __old) {                                 \
                /* unlink this node from its parent */                  \
                __ptr->left = NULL;                                     \
                goto __left;                                            \
            }                                                           \
            else {                                                      \
                /* no need to unlink, the parent will also die */       \
                goto __right;                                           \
            }                                                           \
        }                                                               \
__end:                                                                  \
        (__slen >= 0); /* nothing after loop */}); )

The goto is a conditional jump. You propose replacing it with a conditional jump past the error handling code predicated on the opposite condition. Where's the improvement?

Not without good reason.

commence Rob Wilkens quotation:

He said the *normal* path. Jumping to error code is rarely a normal path. By replacing the gotos with inlined functions, you turn the fast path into a bunch of jumps over duplicated error code, and the error path into a straight line.

The interesting thing about taking arguments to their logical conclusion is that it rarely makes any sense to do so.

 /                          |
[|] Sean Neakums            |  Questions are a burden to others;
[|] <[email protected]>     |      answers a prison for oneself.
 \                          |

I can certainly see where it would seem "easier" to match "one lock" to "one unlock" if your troubleshooting a locking issue.

"easier" is the motivation behind using goto.. Laziness.. that's all it is.

-Rob

No, it is gross and it bloats the kernel. It inlines a bunch of junk for N error paths, as opposed to having the exit code once at the end. Cache footprint is key and you just killed it.

Nor is it easier to read.

As a final argument, it does not let us cleanly do the usual stack-esque wind and unwind, i.e.

	do A
	if (error)
		goto out_a;
	do B
	if (error)
		goto out_b;
	do C
	if (error)
		goto out_c;
	goto out;
	out_c:
	undo C
	out_b:
	undo B:
	out_a:
	undo A
	out:
	return ret;

Now stop this.

Robert Love

And faster, cleaner, simpler, and smaller. Yup.

In the history of trolls on lkml, you are rising to the top. Are you proud?

Robert Love

<quote who="Rob Wilkens">

In italy we say "Non c'è peggior sordo di chi non vuole sentire"

Till to this point the thread was useful to beginners becouse of a lot of smarty coders explained a point that everyone has heard but that rarely knows at deep...

but now Let's ignore him ! He is not a beginner he is a lamer!

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

Am Sonntag, 12. Januar 2003 23:34 schrieb Rob Wilkens:

That exactly is the problem. If they are where the goto would be they needlessly fill the CPU's pipeline, take up space in L1 and use up bandwidth on the busses.
A goto is much shorter than a cleanup.

And you would have to jump. Any control structure will result in one or more conditional jumps in the assembler code (or conditional instructions)

Turning "if (a) goto b;" into a single branch instruction is trivial. The best the compiler can do with

if (a) {
	cleanup();
	return err;
}

is putting the conditional code on the end of the function.

So in the best case the compiler can generate almost equivalent code at a cost of maintainability.

Correct. If you mean that literally, you've grasped an important concept. You grow the kernel only with good cause.

And you look where you add the code. Additional device drivers don't hurt. A computed jump is still only one computed jump. Additional code in common code paths of the core hurts a lot.
For the inner loops of core code there are two considerations, size and reducing jumps.

Regards
Oliver

[Most of a discussion about coding style removed]

It's worth keeping in mind, when coding in *any* language, that concepts such as loops, functions, and any kind of 'structured' programming, are all completely artificial concepts.

Microprocessors are essentially based around:

Loading discrete values to registers.
Loading discrete values into memory locations.
Copying a value from a register or a memory location, to another register or a memory location.
Pushing and poping values on to and off of the stack. Jumping to another location based on whether a register contains zero or a non zero value.

The only thing that can really be considered anything like structured programming is the stack, (and possibly interupts).

Assember for a simple microprocessor such as a Z80 is arguable easier to understand than C source code for something like the Linux kernel.

It's not the language, or how it is indented, that determines how difficult code is to read. It's the logic in the code.

John.

The goto is absolutely not a conditional jump. The if that precedes it is conditional. The goto is not. The if is already there.

-Rob

What amazes me the most is the ability this guy has to have people generate replies. Even Linus got caught. That's nearly better than RMS postings so far...

Nicolas

Am Sonntag, 12. Januar 2003 23:51 schrieb Rob Wilkens:

Yes, exactly. Lazyness is good. Any second spend on hitting Ctrl+F and typing in the name of a cleanup function is lost. Any time you overlook something because the cleanup and the code are not on the same screen is a bug that is overlooked.
Any time one of the cleanup functions is overlooked can cause hours lost in debugging after a change.

Oliver

Let's see, I subscribed Thursday, it's now Sunday.. That's 3 or 4 days on the list.. I'm impressed if I've shot myself to the top of the entire troll list that quickly.

Are there any other famous trolls to know about? :-) Does labelling or classifying someone as a troll make it any easier to dismiss what they're saying?

-Rob

Am Montag, 13. Januar 2003 00:05 schrieb Emiliano Gabrielli:

There's no worse fate than that of those who don't want to listen? (My Italian is bad.)

Very well. What could be said has been said. But please don't insult him. Time spent explaining is usually well spent. Perhaps somebody learned.

OK, maybe I have a soft spot.

Regards
Oliver

Am Montag, 13. Januar 2003 00:11 schrieb Rob Wilkens:

Oh, well.
Apologies first, my assembler is rusty.

if (a == NULL)

	goto err_out;

bad compiler ->
tst $D0 ; evaluate a == NULL
bne L1 ; this is the if
bra err_out ; this is the goto
L1:

good compiler ->
tst $D0
beq err_out ; obvious optimisation

Oliver

<quote who="Rob Wilkens">

Oh my God ... really you are the only one on this list not to understand that hi has mispelled ?!?

Now I understand the reason of your trollness !!

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

<quote who="Oliver Neukum">

It is better than my english :-))

I agree .. my apologises .. I use currently the word "lamer" in IRC, but I don't really know the true translation.. if it is an insult .. plz adcept my apologises

:-)

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

<quote who="Oliver Neukum">

It is better than my english :-))

I agree .. my apologises .. I use currently the word "lamer" in IRC, but I don't really know the true translation.. if it is an insult .. plz adcept my apologises

:-)

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

Umm, an if + goto IS a conditional jump. A modern compiler will simply turn the goto into a conditional jump, meaning that the normal code path doesn't do any jumps.

cheers,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

Enough with the personal attacks.. They get you know where, I'm not botherred by them, and they clog the list.

-Rob

<quote who="Rob Wilkens">

Ok, my apologises... what I would say is "why don't you sit for a moment and think about what a lot of skilled coder said you ???"

What I can't understand in you is the reason of your insistence, ...

cheers :-)

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

I've spent some time looking through the kernel source code, getting a feel for the style and process before attempting to contribute something of my own. In most ways, the quality of Linux code equals or exceeds that of commercial products I've worked on. It may not be perfect, but I'd prefer that the maintainers focus on features and bug fixes, not religious issues.

Your attitude against "goto" is perhaps based upon an excellent but dated article, "Goto Considered Harmful", written by Edsger W. Dijkstra, and published by the ACM in 1968. (A recent reprint can be found at
http://www.acm.org/classics/oct95/.) As you can tell from the date, this article predates modern programming languages and idioms; it comes from a time when Fortran ruled, and before Fortran 77 provided significant tools for avoiding spaghetti code.

A "goto" is not, in and of itself, dangerous -- it is a language feature, one that directly translates to the jump instructions implemented in machine code. Like pointers, operator overloading, and a host of other "perceived" evils in programming, "goto" is widely hated by those who've been bitten by poor programming. Bad code is the product of bad programmers; in my experience, a poor programmer will write a poor program, regardless of the availability of "goto."

If you think people can't write spaghetti code in a "goto-less" language, I can send you some *lovely* examples to disabuse you of that notion. ;)

Used over short distances with well-documented labels, a "goto" can be more effective, faster, and cleaner than a series of complex flags or other constructs. The "goto" may also be safer and more intuitive than the alternative. A "break" is a goto; a "continue" is a "goto" -- these are statements that move the point of execution explicitly.

That said, I have used exactly two "goto" statements in all the lines of C, C++, Fortran 95, and (yes) COBOL I've written since leaving BASIC and Fortran IV behind. In one case, a single "goto" doubled the speed of a time-critical application; in the other case, "goto" shortens a segment of code by half and makes the algorithm much clearer. I would not use a goto willy-nilly for the fun of it -- unless I was entering an obfuscated code contest ;)

We keep lowering the bar for technical prowess, it seems; if something has the potential to be used "wrong", high-minded designers remove the offending syntax rather than find or train competent programmers. This is why Java removes pointers (among other things) -- it's not that pointers aren't useful or efficient, it's that they require discipline from programmers.

Just because something is dogma doesn't mean it is absolute truth. If anything, dogma should be sniffed quite carefully, since it tends to be rather rank if you get close enough. Removing goto is a religious choice, not a technical one.

I could draw parallels with idiotic laws in general society, but this message is already marginal for this list.

..Scott

--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Professional programming for science and engineering; Interesting and unusual bits of very free code.

Believe me when I say, I'm learning a lot from these discussions. Hey, that's what I'm here for. And that's what the list is about in some respect (discussion). Call me a troll if you want, call me a cockroach if it makes you feel better. I don't care. But in the end, I'm saying what I think is right, and when I'm wrong, I'm learning the whys. If I still think I'm right, I'm saying so, and people explain vividly exactly why it is that I'm wrong, and believe it or not, I do learn. Sometimes I learn at a different rate than others, but that's only because I have a different background and a different set of learning disabilities.

-Rob

Good. (although I don't know why I'm replying as this thread is way overdone....:)

or put

There are goto-less languages, even Algol-like ones. And OSes can be written in them.
Well, they just have different names for JUMP.

~Randy

In part that's why i haven't contributed too much of any actual code yet. I'm trying to get a feel for the code and the users. I figure the best way is to join the discussion list and follow the patches going in.

It only goes to show that the core of computer science hasn't changed over the years. While some technology changes, the science itself stays the same. Much like a physicist should know the outdated theories of relativity by Albert Einstein (made way back in the 20th century as well) a good computer scientist should appreciate the contributions of its founders, and have a good grasp of their core contributions. I'm not claiming to be an expert in either field, however.

Of course, this isn't a computer science mailing list, this is a linux kernel mailing list, so I apologize for getting off topic. Let's agree to drop it here.

-Rob

Right.

The one that I used in a previous life was like so. No "while" or "for" constructs, only "do thisloop forever" with conditionals all being explicitly coded inside the loop(s). All based on:

  do [loopname] [forever];
    {block};

end [loopname];

with {block} possibly containing "undo [loopname]". An unnamed undo just terminates the innermost loop. Named undo's can be used to terminate any loop level.

~Randy

Yes, Burroughs (who?) implemented it in System Development Language (SDL) more than 20 years ago. Worked very well.

~Randy (I hope I don't find more of this thread to reply to. :(

The example you gave me wasn't valid C.. Well, from what I can tell it wasn't valid C, because the "for" statement had an opening "(", but no visible closing ")" .. And the "{" looked like it was in the wrong spot. If you want me to have something to benchmark against, I have to first be able to test and use your code, and if I can't use your code it's pointless to try to make it quicker.

If you could provide (preferrably via web download or ftp) sample source that uses that function, it would speed up my ability to benchmark, thereafter I could submit improved code.

-Rob

As long as I can't unzip the latest, do a quick

'make xconfig' w/o changing the defaults,

followed by

'make bzImage',

and actually get the sucker to compile, I'd say go for it. But there's
still too much breakage. And until that breakage is fixed, you won't get
the next wave of people (users) who are curious to poke around with it.
(some of us don't care to take half a day just to figure out what to do to make something compile because there's problems in the source.)

(Yes, I realize I have to customize the kernel some. But at the very least the defaults shouldn't cause it to fall flat on its face.)

-mike

over and over, with additions each time?

So you choose to agree with your lessons that goto is bad, but ignore the other lesson that functions shouldn't have multiple return paths? Or didn't have that lesson?
~Randy

I didn't have a lesson about multiple return paths.. I actually before posting checked out the coding style document..

:/usr/src/linux-2.5.56/Documentation# grep -i return CodingStyle

Returned nothing.. There was no mention of using return in the middle or end of a function in the coding style document, though perhaps there should be.

-Rob

[...]

[...]

[...]

Well, first, I must say I've never seen such an arrogant beginner ! You even felt the need to send me two posts, one private, then nearly the same one to LKML. Poor guy, I gave you a piece of code to show you that your concepts were wrong when applied to reality, and all you try to do is to gain street credit. You will never learn because you whine before you think or search. Don't start a code review of the kernel or you'll get lots of ennemies !

gcc extensions which allow a complex instruction block inside an expression. The special construct ({ blabla }) is an expression which gets the value of the last evaluated expression. Now I'm fedup with explaining to you how to access basic information. Please unsubscribe, forget us and reboot under windows this way (I'm sure you're already reading your mail as root) :

# lilo -u
# reboot

you'd need more code to be able to compile something. At least, I thought you were smart enough to imagine how to rework it as you did on Linus' code, but apparently I was wrong.

I don't have all the parts of the code right at hand, and I don't know when/if I'll send them. For the moment, just try to understand what I sent to you and you can use this structure definition to understand better :

struct ultree {

    unsigned long low;          /* 32 bits low value of this node */
    unsigned long high;         /* 32 bits high value of this node, not used in 32 bits */
    int level;                  /* bit level of this node */
    void *data;                 /* carried data */

struct ultree *left, *right; /* children : left and right. NULL = leaf */
struct ultree *up; /* parent node. NULL = root */
};

Oh and if you have complaints about comments after the 80th column, remove them. And if the order of the declaration doesn't match your habits, just know that this is the order which gives me best performance, since swapping any 2 of its members induces a loss of about 20%. You know, L1, cache line size... all the things that your teachers didn't tell you because the story of the evil goto was better to keep children quiet !

Bye,
Willy

Rob, one thing you may not have noticed since you haven't been following the list for a while is that with the current generation of computers size frequently translates directly into speed and a lot of the time honored performance tricks that trade size for fewer commands executed end up being losses.

this can be seen by compiling code with -O2 and with -Os and frequently the -Os will actually be faster.

This is becouse not all memory is equal, main memory is very slow compared to the CPU cache, so code that is slightly larger can cause more cache misses and therefor be slower, even if significantly fewer commands are executed.

in addition frequently the effect isn't direct (i.e. no noticable difference on the code you are changing, but instead the change makes other code slower as it gets evicted from the cache)

unfortunantly while this effect is known the rules of when to optimize for space and when to optimize for fewer cpu cycles for code execution are not clear and vary from CPU to CPU frequently within variations of the same family)

if you google for -Os you should find one of the several discussions on the list in the last year on the subject.

David Lang

You dont realistically expect to learn how to program reading Documentation/CodingStyle, do you? CodingStyle merely serves as general guidelines of what is considered good practice among kernel development, no more no less. If you dont know how to code in the first place (which you have proved spectacularly, by now), you're SOL.

Go educate yourself and stop trolling. Somewhere, along the bucketloads of vomit you insisted in throwing here, you asked who were the other top-rank trolls -- sincerely, and as far as I can remember, you're ahead by a fair margin. Not even [email protected] with his delireous "single user linux" crap came anywhere near you, although he was, too, very resistant to being clued in.

See things from this end -- when 99% of the people tell you you're wrong, consider the possibility you are _actually_ wrong, and not the other way around.

Now, off to ~/.killfile you go.

Regards,

Nuno

Hmm, I never do this, I've been recycling my own .configs for some time. Sounds like a valid concern, I'll give it a shot.

Bill

Not all memory is equal here, either i.e. I'm on NUMA boxen.

Bill

Have you ever read "Programming Perl"?

Laziness is a virtue. (At least I think that's the right book - possibly the 3rd edition.)

Ryan Anderson
  sometimes Pug Majere

No, but I would expect rules of kernel coding to be in there. For example, we were talking about using return mid-function. I always considerred that perfectly OK. Others were saying that's a no-no. If it's a no-no, it should be documented. That is, if it's a no-no. That may be a situational thing though.

99% of the people are running a microsoft based OS (It has 95% of the market in terms of sales, but factor in pirated copies and your figure will get close), of the 0.5% running linux, 0.025% of them are probably subscribed to this mailing list. Of that, probably 5% read it regularly. Now, of those 5% (of 0.25% of 0.5%), I'm probably getting 5-10 people reacting negatively (the rest are neutral reactions or no reactions), and claiming to speak (in a rather -- shall we say -- arrogant and self-important manor) for the list as a whole.

Yeah, yeah, should've done it before..

-Rob

p.s. Yes, all statistics are made up on the spot for comical purposes only and are only half-way intended to represent the real world. p.p.s. given those percentages, 5-10 people may be a lot percentagewise, I don't know, I haven't done the math.

No Rob, most people don't bother responding because they read the FAQ for the list and they realize that this is waste of bandwidth of a lot of people that are important to Linux. You're wasting their times and this is why this should stop NOW.

You're soo arrogant you don't want to see how much YOU'RE wrong ?
See, I'm a computer geek that started at 11, that learned everything from the practical viewpoint (first assembly then Basic then structured language) and even going through structured programming classes 7 years latter they still managed to get brainwashed to the point that just now I realize that goto's are really a good thing, and that it should be used as standard practice (college has been 10+ years ago). So open your mind to the fact that you were brainwashed, and the fact that they brainwash so many people that aren't smart enough to question them, that everything is taken at face value.

And Linux is not a hobbist thing anymore. From the point a lot of people trust their businesses to Linux like I do everyday (I'm MIS with about 12 Penguins, with about 30 more Microshits to be converted to Penguins), then you should respect people here. Me and I'm sure a lot others read this list daily, and they don't want to spend their time on this thread. I apreciate very much the work of everybody here, considering that they could probably make a hell of a lot more money through other ways, but they decided to go the open source way, and the whole world's society is benefiting from their work, instead of mostly benefiting big, greedy companies like microshit.

By the way, you're not being paid my Microshit or other companies that have a lot to benefit from stalling Linux development to troll this list, aren't you ?

Marcelo Pacheco

But it IS a computer science mailing list.

Applied, practical, real world computer science - This is where the rubber meets the road - and interesting theories that don't cut the mustard in real life are discarded.

:-)

Best Regards,

Joe

    Hi,

You don't think people might be silent because they think everything relevant was said by those 5-10 people?

Please do assume long-time kernel hackers *know* what they do. Asking of course is OK, but please do not consider anything they do plain wrong just because you don't understand after some seconds of thinking. If you imply they're too dumb to do their job, you *will* get negative reactions, like it or not.

If you think there's not enough documentation, try the web (including the mailing list archive) or some kernel hacking books. If some things are *not* documented at all (that is, you don't find the proper documentation), ask and write some documentation yourself or ask yourself were to get a grip on techniques your not familiar with.

Thanks,

Jochen.

The sequence is important. People just learning to pee sometimes
put the steps in the wrong order, with frustrating results.
Maybe a checklist would be useful to those just starting out.
  -- Brien K. Meehan; Msg-ID <[email protected]>

Actually, it's one of the few books I actually still own (the perl one).. Laziness is indeed a virtue.. One I live my life by. Of course, that's why I haven't gotten off my ass all day and have been doing nothing but reading/writing mails from this list. :-0 If the list accepted binaries, I'd take a photo of my room and workspace, and you'd get the impression that I was one of the laziest people you've ever met. Granted, one of my computer science professors (not one of the greatest professors I ever had) said that the best programmers in the world are the laziest sons of bitches you'll ever meet, and I think I may qualify (as a lazy son of a bitch, not necessarily as a great programmer).

Aww.. Heck.. Go ahead and use goto all you want. I'm not in a position to stop anyone anyway.

-Rob

See Brian Kernighan's explanation in 1981. Still good.

http://bit.csc.lsu.edu/tutorial/ten-commandments/bwk-on-pascal.html

---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com  www.rtlinux.com
1+ 505 838 9109

Actually, we were talking in private e-mail, so if we were discussing the FAQ, you would've continued this there, but since you've decided to bring this discussion out here, I'll continue it here for now..

I have unlimitted bandwidth, as do many others. IF they don't they shouldn't subscribe to this list, they should subscribe to the newsgroup and pick-and-choose by sbject/thread.

I'm perfectly willing to see how much I'm wrong. No one has yet shown me that I'm wrong, though. I'd be perfectly willing to see it if it were shown.

I have a head start on you then, I started around age 8. TI-99/4A & the BASIC programming language back then (I even had a voice box for the computer so I was writing programs that could talk which I thought was the coolest thing.) Moved on to the Commodore 64, 128, then moved into the PC world kind of late, in 1990 I bought an XT 10MHz machine that happenned to work with the commodore 128 monitor, and since then have incrementally upgrade part by part to my current machine (haven't upgraded in three years).

If I'm questioning people on this list, what makes you think I wasn't smart enough to question them then?? Think about that one for a second?

Serverwise or backofficewise, penguins have their place. On the desktop, penguins have to learn to adapt to a different climate. That's off topic for the kernel list though.

Then don't read it, skip over to the next message and move on with life. As someone else put it, life is too short.

Few would be doing it if there weren't SOME benefit for themselves. That benefit _may_ be a better system for themselves.. Some may be the intellectual satisfaction of a job well done.. Some may work for companies like red hat or suse.. Some may work for companies that want to replace old UNIX systems with cheaper PC hardware that does the same thing... Everyone has a motivating factor.

The answer to this is that I'm not in any way shape or form employed by any company what so ever at present. I'm considering part time work, but will not say more about that because the last time I mentioned something about an employer on a list where people thought I was a troll (alt.support.depression.manic around 2000 when I was unmedicated) they were sending faxes and calling the office where I worked at with complaints. I'd rather not forewarn any employer that I'm a little off-center, though I guess it wouldn't hurt my chances of eventually getting on social security disability which would cover my bills.

-Rob

I never implied anyone was too dumb to do their jobs. IF that was read into in any of my messages, I apologize.

-Rob

As annoying as this thread is, there are occassional valid points.

A first pass at an addition:

@@ -264,3 +264,27 @@
 
 Remember: if another thread can find your data structure, and you don't
 have a reference count on it, you almost certainly have a bug.
+
+		Chapter 9: Error handling
+
+Error handling in functions needs to follow a few simple rules.  If the
+function has allocated resources (irqs, memory), taken a reference, 
+grabbed locks, etc, all of those allocations must be reversed when 
+returning an error.
+
+In functions that depend on several allocations, the preferred way to 
+return the error is with with the use of a few "goto"s that point at an
+error block at the end of the function, after the normal, successful 
+return.
+
+Several consecutive lables can be used, reversing the order of the 
+allocations.  For example, if memory is allocated, a lock taken, and 
+an irq activated, the error labels might be labeled "err_noirq", 
+"err_nolock", "err_nomem", in order.  The final step would be to
+return the error.
+
+The reason for this style is very simple: Multiple return paths from
+the same block of code are extremely confusing, and make verification
+that locks are balanced, memory is properly freed, and that reference
+counts are not leaked very difficult.
+

Ryan Anderson
  sometimes Pug Majere

every article i have read (an agreed with) on operating system internals, has stated that the goto is considered taboo in C... _except_ in operating system code where speed is critical, and goto can increase readability. i taught myself how to program by single stepping through assembly code on a DOS machine. i have found that too much structure leads not to modular code that is easy to maintain, but a nightmare of conditionals that cause your head to throb trying to trace the state of an execution. being that i am partial to assembly, perhaps i am biased in the matter.

br

20,000+ boxes here brother. constructive argument helps to drive innovation. this list was founded upon it, was it not?

br

Hm, I just did, and it seems to work for me. I ran a bunch of different usb-serial drivers through some tests, but these worked for me without this patch. I don't know what stress tests Alan was running to show up a problem.

Anyway, here's a patch with your new lock, if you want to apply it.

thanks,

greg k-h

diff -Nru a/drivers/char/tty_io.c b/drivers/char/tty_io.c
@@ -159,6 +159,58 @@
 extern void tx3912_rs_init(void);
 extern void hvc_console_init(void);
 
+
+/*
+* This isn't even _trying_ to be fast!
+*/
+struct recursive_spinlock {
+	spinlock_t lock;
+	int lock_count;
+	struct task_struct *lock_owner;
+};
+
+static struct recursive_spinlock tty_lock = {
+	.lock = SPIN_LOCK_UNLOCKED,
+	.lock_count = 0,
+	.lock_owner = NULL
+};
+
+unsigned long tty_spin_lock(void)
+{
+	unsigned long flags;
+	struct task_struct *tsk;
+
+	local_irq_save(flags);
+	preempt_disable();
+	tsk = current;
+	if (spin_trylock(&tty_lock.lock))
+		goto got_lock;
+	if (tsk == tty_lock.lock_owner) {
+		WARN_ON(!tty_lock.lock_count);
+		tty_lock.lock_count++;
+		return flags;
+	}
+	spin_lock(&tty_lock.lock);
+got_lock:
+	WARN_ON(tty_lock.lock_owner);
+	WARN_ON(tty_lock.lock_count);
+	tty_lock.lock_owner = tsk;
+	tty_lock.lock_count = 1;
+	return flags;
+}
+
+void tty_spin_unlock(unsigned long flags)
+{
+	WARN_ON(tty_lock.lock_owner != current);
+	WARN_ON(!tty_lock.lock_count);
+	if (!--tty_lock.lock_count) {
+		tty_lock.lock_owner = NULL;
+		spin_unlock(&tty_lock.lock);
+	}
+	preempt_enable();
+	local_irq_restore(flags);
+}
+
 static struct tty_struct *alloc_tty_struct(void)
 {
 	struct tty_struct *tty;

@@ -460,7 +512,7 @@
 	{
 		unsigned long flags;
 
-		local_irq_save(flags); // FIXME: is this safe?
+		flags = tty_spin_lock();
 		if (tty->ldisc.flush_buffer)
 			tty->ldisc.flush_buffer(tty);
 		if (tty->driver.flush_buffer)

@@ -468,7 +520,7 @@
 		if ((test_bit(TTY_DO_WRITE_WAKEUP, &tty->flags)) &&
 		    tty->ldisc.write_wakeup)
 			(tty->ldisc.write_wakeup)(tty);
-		local_irq_restore(flags); // FIXME: is this safe?
+		tty_spin_unlock(flags);
 	}
 
 	wake_up_interruptible(&tty->write_wait);

@@ -1926,7 +1978,7 @@
 		fp = tty->flip.flag_buf + TTY_FLIPBUF_SIZE;
 		tty->flip.buf_num = 0;
 
-		local_irq_save(flags); // FIXME: is this safe?
+		flags = tty_spin_lock();
 		tty->flip.char_buf_ptr = tty->flip.char_buf;
 		tty->flip.flag_buf_ptr = tty->flip.flag_buf;
 	} else {

@@ -1934,13 +1986,13 @@
 		fp = tty->flip.flag_buf;
 		tty->flip.buf_num = 1;
 
-		local_irq_save(flags); // FIXME: is this safe?
+		flags = tty_spin_lock();
 		tty->flip.char_buf_ptr = tty->flip.char_buf + TTY_FLIPBUF_SIZE;
 		tty->flip.flag_buf_ptr = tty->flip.flag_buf + TTY_FLIPBUF_SIZE;
 	}
 	count = tty->flip.count;
 	tty->flip.count = 0;
-	local_irq_restore(flags); // FIXME: is this safe?
+	tty_spin_unlock(flags);
 	
 	tty->ldisc.receive_buf(tty, cp, fp, count);
 }

*plonk*

Jens Axboe

That document is short for several reasons.

- It has been written for particular needs, and updated rarely

- Most long-time kernel coders really don't need detailed guidelines, although newcomers (like yourself) apparently want something..

Things you need to understand include at least:

- Linux kernel is one of the most complicated codes that gcc compiler is ever put to work on, and over the years we have unearthed tons of
optimizer bugs. Many of somewhat odd looking coding details do
originate from circumventions of those compiler bugs.

- Advanced optimizer hinting features, like unlikely() attribute
are very new in (this) compiler, and while they in theory move the "unlikely" codes out of the fast-path, such things have been buggy in the past, and we are worried of bug effects...

- Why code in a manner, where the optimizer needs to work very hard to produce fast code, when simplified structures, like those with 'goto' in them, can result the same with much less effort ?

- Knowing effects of those optimizations requires profiling, and studying produced assembly code on different target systems.

- Linux is multi-CPU-architecture kernel, looking at it via "intel-only, lattest Pentium-XIV" viewpoint is not going to cover all cases. Making changes that bloat code will make system that much harder to fit into smaller embedded machines.

- Sometimes you need to code differently to achieve higher performance
at different processors. See drivers/md/xor.c and header files
it includes. Especially all include/asm-*/xor.h files, including
include/asm-generic/xor.h ... (That shows to you how different
approaches work at different systems. What works fast in register- rich processors does not necessarily be fast in register-poor things, like i386 series.)

- Adding function classifiers like "static inline" do change rules somewhat. (Especially things like "mid-function return".)

- Larger code, either with manually replicated exit cleanup (which are pain to maintain, when some large-scale change is needed), or via excessive use of "static inline", will pressure caches, and makes it more likely to drop soon to be again needed code (or data)
from cache. Cases where cache-miss costs your tens, or hundreds
of processor clock cycles that is really important question.

- Explaining things like GCC asm() statement syntaxes isn't a thing for Linux kernel documentation. (Those vary from target processor to another!)

I repeat:

To understand effects of various coding details, you need to study produced assembly code, and keep in mind that in modern processors a branch out of straight-line execution path (after optimizations) is expensive (in time), and cache-misses are even more expensive.

Then you need to benchmark those codes with different loads (where applicable) to find out what caches affect them -- and when you must bypass caches (they are limited resource, after all) in order to give overall improved system performance, when your code does not cause actively used code or data to be evicted from caches unnecessarily.

/Matti Aarnio

My, my, my, an anti-goto zealot now.

It just to happens that sometimes the compiler generates stupid code for goto-less solutions. While the famous "no goto needed" theorem is certainly true, it duplicates lots of code to get rid of gotos, and that is a no - never - only over my dead body proposition in a kernel that tries to be as fast as humanly possible.

And if used with care and good taste, a goto can lead to clearer, more understandable (and thus more probably correct) code. Just look up what sort of "programming style" Dijkstra was complaining about when asking to ban gotos, and what D. E. Knuth has to say on structured programming with gotos.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

You did not live through the horror that was FORTRAN IV, I learned programming in it (no structure except DO, a primitive for). Sure, Pascal strictures are overkill, but in a sense they were needed to implant a bit of structure into the mess that usually came before.

And you do break structure only when necessary, so the dosis of Pascal did you some good after all ;-)
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

If you like "structure" so much, consider the fact that gotos are used in a very structured way in the kernel. Books won't list goto as a "structured keyword" but that don't prevent it from being used in a structured and diciplined manner.

"Avoid gotos" is only a rule of thumb, for those that don't know the finer points. Gotos have a enormous potential for abuse, but it isn't abused in the kernel because it is used by experts who limit themselves to only using it right. (Well, most of the time, but that isn't what you complain about. :-)

One cannot expect a newbie to get this right while learning the language,
so beginners get a "don't use gotos" rule. And therefore it takes time before they learn to read code containing gotos too - even _good_ code.

Please note that rules of thumb aren't absolute. There is another well known - don't play with fire. Generally good, but some people have to do a lot of it anyway in order to design better fire extinguishers
and train firefighters.

Sometimes using gotos makes things clearer, _for those that have some experience with this particular way of using gotos_.

_Of course_ it isn't the clearest to _you_, because you, as a newbie, have noe training or experience in this. Get experience, learn to recognise the very limited use of goto in the kernel, and you'll probably agree.

Consider someone who takes a C course where they don't teach "switch" because "if" can do the same thing. He would consider "switch" unnecessary. And hard to read, due to lack of experience. And just like
you, he would urge people to not use switch because _he_ finds it harder to read. That doesn't make avoiding switch the right thing to do though.

The same applies to goto. It is a useful thing - if used right. [...]

Again, switch is as unnecessary, yet nobody wants to remove it. And yes,
switch can be abused too (replace all ifs with switch for example.) The rule against goto is a beginners simplification, because the real rules for using goto are harder to express. They are wasted on people who struggle with "for" and pointers - and then the beginners course ends.

Readable for who, is the question. Some limited use of goto don't take that long to learn. I used to simply think "urgh, a goto" but didn't complain - it wasn't _my_ kernel. Now I understand that kind of code and approve. And I shudder thinking about some code I've written for pay - doing ten allocations in a row, testing each, and freeing everything in a nested fashion upon possible failure.

Now, if we can avoid that extra work _without_ harm, then it is certainly worth it, no?

What you describe is the problem with undiciplined use of goto. Kernel code don't use gotos in any arbitrary way. Check, and you'll see that 99% of it it is very diciplined, using gotos in one well-defined way. Much of it is explicitly coded function-internal "exceptions", a structured concept newer than C.

(Yyou can surely find some bad examples too. Either hacks with a special reason, or things that really ought to be cleaned up.)

Making it better is interesting. Note that performance sometimes overrules style, and yes - there are cases where goto wins on raw performance. And that might pay off if it is a very often executed piece of code.

Also, avoiding goto at all cost is extra work for programmers _every time_. Learning to use gotos "right" (I.e. advanced use of C) is one-time learning and then it is free - everytime.

The use of gotos may be a learning curve for every kernel newbie, but so is understanding the VFS or the VM system or any other big complicated piece. Wether or not that piece uses gotos. :-)

Helge Hafting

Rob Wilkens <[email protected]> wrote:
[...]

    error = -EINVAL;
    if (length < 0) /* sorry, but loff_t says... */
        break;
    error = user_path_walk(path, &nd);
    if (error)
        break;
    inode = nd.dentry->d_inode;

    switch(0==0) {
    default:
        /* For directories it's -EISDIR, for other non-regulars - -EINVAL */
        error = -EISDIR;
        if (S_ISDIR(inode->i_mode))
	    break;
        error = -EINVAL;
        if (!S_ISREG(inode->i_mode))
            break;

        error = permission(inode,MAY_WRITE);
        if (error)
            break;

        error = -EROFS;
        if(IS_RDONLY(inode))
            break;

        /* the rest omitted - the pattern should be clear */

        put_write_access(inode);
        break;
    }
    path_release(&nd);
    break;
}

    for(;;) {
        <do something>
        if(i_want_to_go_back)
            continue;
        <do something_else>
        break;
    }

Bernd Petrovitsch                              Email : [email protected]
g.a.m.s gmbh                                  Fax : +43 1 205255-900
Prinz-Eugen-Straße 8                    A-1040 Vienna/Austria/Europe
                     LUGA : http://www.luga.at

Actually Edsger Dijkstra wrote a paper entitled "Goto considered Harmful" He never called them evil. And the title was more for shock value to grab peoples attention. For the beginners Dijkstra did not distinguish between goto, break, return, and continue.

You can find many of his papers at:
http://www.cs.utexas.edu/users/EWD/

What he was after was simple and maintainable code, and from everything I have read, I think he would have no major problems with the Linux kernel code.

In the category of maintainability, and simplicity Dijkstra made certain the first hardware implementation of an interrupt handler he worked with had the ability to completely save the interrupt state so he could later return to the interrupted code. To make writing to a printer a non-realtime task he invented the semaphore.

Linus I think if he was alive you would have enjoyed talking to him, your view points seem to mesh quite well.

Now that is something worth criticizing!

Though standard Pascal was not unusable because of the lack of a goto, that was the one feature it actually had. But I suspect a lot of teachers failed to mention it.

Well you seem to be coping well. Just a little Pascal phobia there...

Eric

Someone want to add this one to the lkml faq (does anyone actually read that these days?) or maybe http://www.kernelnewbies.org/faq/

Wow, one week later, and this would tie in with the fourth anniversary of someone else[2] making an ass of himself on this issue[1]

Dave

[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/9901.2/0939.html
[2] Complete with quaint 'cool' l33t handle. How 90s! *bows head in shame*

| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

I find linux-kernel works best if you read it with a positive list in .procmailrc rather than using it as a killfile. This would work even better if y'all didn't feed the trolls.

Bernd

Well well. Who'd have thought! Idealistic youth; those were the days; etc etc ;)

Am Montag, 13. Januar 2003 14:08 schrieb Dave Jones:

So let us rejoice in a story of human growth.
In the exuberant spirit of this joyfull occasion, I'd like you to find a place for this memorative piece of code:

if (a->sibling->present)

	goto your_place;
else
	goto my_place;

	Regards
		Oliver

http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF
to be exact. Reading it you can tell exactly how much of an mathematician Dijkstra really was. At these times It's best to keep in mind a quote:

"I used to understand the Theory of Relativity, but then the mathematicians got hold of it."
-- Albert Einstein

Well, in the formentioned paper he made the case that while - do, and do-while are superfluous; we should all use recursion instead. Out of respect of the dead, I'm not going to say what I think of that.

Since C don't allow goto beyond it's function, most of what was problematic of goto's aren't legal anyway.
But I submit that those that think goto's are evil never had to deal with smp locks.

Most goto's I've seen deal with error handling, and I guess much could be "solved/hidden" with a "on_return { };" clause, but...
An on_return would be a simplified try/trow/catch that is limited to the function.
IMHO: a trow that is catch'ed somewhere up the call stack, is just as much an evil as goto.

Considering that students are bottled on Java these day, they're still learning a language unusable for real work.

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

I pick out _one_ piece of code that _one_ random person posts publicly (so, it happens to be one of the leaders of the free open source world)
and suddenly I'm a zealot. I'm a nobody and proud of that fact. I was
just explaining my dislike of a particular code structure based on my earlier training and experience.

In the time since my writing of that post and your response, though, I have since been "Enlightenned" by all of the wonderful people on this discussion forum.

-Rob

Yeah, but..

My changes won't actually be incorporated (i hope) into the kernel. I've since learned that a goto will optimize to be just as quick as what I wrote (by studying the optimized assembler output at other suggestion). Therefore, it was silly and pointless for me to spend the 10-12 minutes I did changing the code and testing it and e-mailing back the changes.

So, there's nothing to worry about. Goto's are here forever.

-Rob

I'm sure Linus can hold his own on this one, but this has become a FAQ or FSB (Frequently stated bitch).

Programming 101:
All known microprocessors execute instructions called "op-codes". The logic of program-flow is implemented by testing condition "flags" and jumping somewhere else, based upon the condition. These jumps are "GOTOs".

To implement logic, you have three, and only three choices. You can jump to some code that's earlier in the instruction stream, you can jump to some code that's later in the instruction-stream, or you can just keep executing the current instruction stream.

Assemblers generate op-codes that programmers program. They are not allowed to change anything a programmer inputs. For all practical purposes, they simply change programmer- defined names to processor-specific op-codes.

Compilers have more latitude. Compilers, including 'C' compilers attempt to convert logic that a programmer defines to op-codes. Since a compiler needs to generate code that will give the correct logic, regardless of the previous logic or the following logic, it is constrained in its code generation capabilities in a manner that an assembly-language programmer would not necessarily be. However, an astute programmer can, using the tools provided by the compiler, including 'goto', cause code-generation in which the usual case allows the processor to continue executing the current execution-stream without jumping.

When the processor is forced to jump on a condition, this usually costs CPU cycles. An astute kernel programmer may spend hours mucking with a single piece of code trying to make it execute as fast as possible. When a new-be comes along and complains about the methods used, he is going to get his feet wet real quickly!

Here is an example of how some junior instructors in college teach...

        if(...){
        {
            if(...){
            {
                if(...){
                 {

They just don't get it. When you get to something that's not true you can't readily "get out". Further, the normal program- flow ends up with all those "ifs". The above code should be:

         if(!...) goto get_out;
         if(!...) goto get_out;
         if(!...) goto get_out;
         {do something()...}
         get_out:

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

1) newbies has made the very same "minor" suggestion before; and had their heads summarily chopped of.
2) It's not a minor suggestion.
3) and more to the point, you proved your selv why it's a dumb idea to remove them, when you had to correct you own code 2 minutes after you posted it.

-------------------- begin quote ---------------------------------

oops - Yes, I forgot to add one line here (my point remains the same:

                          spin_lock(&tty_lock.lock);

-------------------- end quote ---------------------------------

OF all the reasons to use goto, spinlocks are alone reason enough. By omitting the very little line you did
you created a race condition. Now I'm assuming that you know what a race condition is.
IF YOU DON'T: DO NOT ASK! L-O-O-K I-T U-P !!!!

Now since races are the worst kind of problems, in that they causes seemingly random data corruption, or of you forget a spinunlock you get a hung machine, minimize them is of paramount importance.

Considering that doing kernel development is hard enough, new development is almost always done on uni processors kernels that do only one thing at the time. Then when you base logic is OK, you move to a SMP, which means (adding and) debugging you spin locks.

Considering that fucking up spin locks are prone to corrupting your machine, one very simple trick to makeing fewer mistakes to to have one, and only one, unlock for every lock.

In order to achive that you write your function to have one entry point (which all C functions have) and one exit point, thus one and only one return.

In order to do that you can either concoct a set of if-then-else-orelse logic that is incomprehensible, or you use goto!

Now you may look at Linus's code you buggified, and point out that the lock and unlock are not in the same function, then read Linus's original post CAREFULLY! And UNDERSTAND how these functions are used.

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

Goto's aside, I find the above extremely bad advise. You should _always_ develop with smp and for smp from the very start, or you will most likely not get it right later on. With preempt, this becomes even more important.

Taking a spin lock twice will hard lock the machine, however on smp you will typically have the luxury of an nmi watchdog which will help you solve this quickly. Double unlock will oops immediately if you run with spin lock debugging (you probably should, if you are developing kernel code).

Jens Axboe

I'm sure

THat's NOT why we're here. People are on this list to do work, not to be teaching assistants. That's why You're considered disrespectful.

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

You should, and I do, *design* with smp in mind, and I throw in smplock/unlonk as I go, but I tend to make first runs on a UP.

I see your point on preemt, though.
You do first runs on SMP?

I have the console on a serial port, and a terminal server. With kdb, you can enter the kernel i kdb even when deadlocked.

TJ

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

Always, if for nothing else than the benefit of a better debugging environment.

Even if spinning with interrupt disabled?

Jens Axboe

I'd like to have some verification (or some test-suite) to see whether it makes any difference at all before applying it.

Alan, what's your load?

Linus

Haven't painted myself into that corner yet. Doubt it, very much.

_________________________________________________________________________

Terje Eggestad                  mailto:[email protected]
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________

These are the nasty hangs, total lockup and no info at all if it wasn't for the nmi watchdog triggering. That alone is reason enough for me :-)

Jens Axboe

:)

As much as I absolutely love the utility of this piece of code you really do have to admit that it _is_ rather difficult to understand :)

Is it so flawed of me to expect that some day this code could be rewritten in an extremely clean fashion and compilers made to do the work that was put in to make this fast?

mvg,
Alex

"[...] Konqueror open source project. Weighing in at less than
            one tenth the size of another open source renderer"
Apple,  Jan 2003 (http://www.apple.com/safari/)

You think Relativity is outdated ?!? I can't beleave !

Emiliano Gabrielli

dip. di Fisica
2° Università di Roma "Tor Vergata"

It uses NMI's to break into the debugger, so it would also work with interrupts disabled and spinning on a lock, the same is also true for kgdb.

Zwane

function.linuxpower.ca

Lots of serial activity (standard PC serial ports) with carrier drops present and random oopses appear. I've seen ppp oopses too but don't know if they are related. I tried duplicating it with pty/tty traffic on a dual PPro200 and suprisingly that did the same.

Ages ago I chased serial bugs down by doing data transfers between two PC's while one of them was strobing the carrier up and down on the test PC with varying frequencies

I've not had time to try that paticular abuse again alas.

Alan

Well, that would kind of match the locking place - the hangup might well race with IO activity on another CPU. That's exactly the sequence that was protected by the global irq lock.

Just regular IO on its own shouldn't trigger this, I _think_ (no hangup event).

Although I can actually imagine the "flush_to_ldisc()" racing with itself on a pty (with the master flushing the slave as the slave flushes itself), so maybe it could actually happen.. But if your pty tests closed the master and forced hangups that way, the race would be more likely.

Do you still have the pty stress-test program?

Yeah, that hangup path is one of the nastier tty events, and it's also oen that doesn't get much testing in many "normal" loads.

Linus

But still requiring up-apic, or smp with apic, right?

Jens Axboe

I believe I may have seen it on 2.5.53 just surfing on an Alcatel Speedtouch DSL modem (using PPPoATM) while compiling in a background gnome-terminal (and probably running a few other things, maybe including top, in terminals). I'll try to confirm that.

Andrew

I'm still getting messages in my inbox about it, but I'm dropping this whole goto thread nonsense.

Some people (ok, at least 4 on this thread) have accused me of being "an arrogant beginner" (some by private e-mail, some with less friendly words but with the same basic meaning).. (about 2 or 3 others told me "not to leave" but rather to "tone down")

I must apologize, but also comment that arrogance is not my intention. It's a de facto symptom of a biological illness I have. I hope you wouldn't hold it against me. I am taking medications to control it (maybe not so succssfully, but I'm up to 14 pills a day now), and apologize when it gets in the way of the normal flow of discussions here.

It (The symptom in question) is called "Grandiosity" or "Inflated Sense of Self Worth" depending on the reference but here's some places where you can find the symptoms listed:

http://bipolar.about.com/library/weekly/aa980408.htm
Refers to "Grandiose Thinking", "Inflated Self Esteem", and something
others may have seen on thist list, "Lack of insight"...

http://www.frii.com/~parrot/dsm.html
Refers more officially to "inflated self-esteem or grandiosity", and is
listed as the first symptom under "mania"

I'd suggest reading to educate yourself on the fact that you should no more make fun of me for being grandiose than you should make fun of a retarded person for being slow. It's a legitimate disabiliity, and I can actually collect social secutiy for it (and might go that route, it pays around $1500/month to stay home).

Anyway, my point is that if I seem all that high and mighty in my tone, I'm not really that way in general (I'm really a nice guy). I don't know how to communicate that effectively, and I don't know that it matters.

I also thank those who have pointed out the arrogance in my tone if indeed it was there. I have a therapist appointment in three hours and will definitely bring it up.

Please do _not_ respond to this message on the list -- or if you do, don't quote it, it's off topic. I just wanted to generally send an apology to the few people who haven't already filterred me out as a result of my behavior.

-Rob

p.s. If I've gotten "black listed" (filtered,. procmailed, etc) so quickly by so many on this list so quickly, can you imagine how quickly I've probably (before even getting on this list) I've been blacklisted in the job market by former employers based on my behaviors there prior to quitting (they could not fire me for same behaviors due to the americans with disabilities act). A friend of mine claims he's seen my name on a corporate blacklist. I didn't ask for proof, but presumed he was right. It's only fair that social security exists to protect people like me from becoming completely homeless, and that they offer section 8 housing for mentally ill folk like myself whch one day (after my parents grow old and die) I will probably have to take advantage of..

p.p.s. I'm writing from window now as anyone looking at headers might figure out.. I know, "bad".. But I'm spending about 80% of my time in linux and 20% in windows which I think is fair. The thought of apologizing came to me now, and I happenned to have been in windows, so this is where I'm writing from.

To the tune of "Teen Angst" from Cracker:

Cause, what the world needs now,
is another theoretical optimizer
like I need a hole in my head.

You'd think I'd be resigned to the l-k tradition of the unbenchmarked "optimization" patch, but apparently not yet...

-VAL

nmi_watchdog=2 - uses performance counters, not apic.

which requires a local APIC to set up NMI delivery mode like Jens said

regards
john

Khendon's Law: If the same point is made twice by the same person,
the thread is over.

Well UP with Local APIC will suffice. So that works on a lot of i686 machines.

Zwane

function.linuxpower.ca

This mean those of us that have a 'local_apic_kills_bios' flag in dmi_scan.c are still out of luck, correct?

Yep, blacklisted systems still won't work.

Zwane

function.linuxpower.ca

In message <[email protected]>, Eric W. Biederman writes:

[snip]

If my memory serves me, Niklaus Wirth invented Pascal as a teaching language not meant for production work. Modula, I think, was meant for production work. I don't care for either also.

[snip]

Bob

+---------------------------------------------------------------+
| Bob Taylor             Email: [email protected]       |
|---------------------------------------------------------------|
| Like the ad says, at 300 dpi you can tell she's wearing a     |
| swimsuit. At 600 dpi you can tell it's wet. At 1200 dpi you   |
| can tell it's painted on. I suppose at 2400 dpi you can tell  |
| if the paint is giving her a rash. (So says Joshua R. Poulson)|
+---------------------------------------------------------------+

[re OSS vs ALSA audio drivers]

Linus> So I don't see a huge reason to remove them from the sources, Linus> but we might well make them harder to select by mistake, for Linus> example. Right now the config help files aren't exactly helpful, Linus> and the OSS choice is before the ALSA one, which looks wrong.

Linus> They should probably be marked deprecated, and if they don't Linus> get a lot of maintenance, that's fine.

Like this?

Also available from:

bk://cloos.bkbits.net/alsa-oss

[email protected], 2003-01-13 20:05:11-05:00, [email protected]
Move ALSA before OSS

 sound/Kconfig          |   26 ++++++++++++--------------
 arch/i386/defconfig    |   10 +++++-----
 arch/ia64/defconfig    |   10 +++++-----
 arch/parisc/defconfig  |    8 ++++----
 arch/sparc64/defconfig |   10 +++++-----
 5 files changed, 31 insertions(+), 33 deletions(-)

diff -Nru a/sound/Kconfig b/sound/Kconfig
@@ -1,20 +1,6 @@
 # sound/Config.in
 #
 
-menu "Open Sound System"
-	depends on SOUND!=n
-
-config SOUND_PRIME
-	tristate "Open Sound System"
-	depends on SOUND
-	help
-	  Say 'Y' or 'M' to enable Open Sound System drivers.
-
-source "sound/oss/Kconfig"
-
-endmenu
-
-
 menu "Advanced Linux Sound Architecture"
 	depends on SOUND!=n
 

@@ -42,3 +28,15 @@
 
 endmenu
 
+menu "Open Sound System"
+	depends on SOUND!=n
+
+config SOUND_PRIME
+	tristate "Open Sound System (DEPRECATED)"
+	depends on SOUND
+	help
+	  Say 'Y' or 'M' to enable Open Sound System drivers.
+
+source "sound/oss/Kconfig"
+
+endmenu

diff -Nru a/arch/i386/defconfig b/arch/i386/defconfig
@@ -839,11 +839,6 @@
 CONFIG_SOUND=y
 
 #
-# Open Sound System
-#
-# CONFIG_SOUND_PRIME is not set
-
-#
 # Advanced Linux Sound Architecture
 #
 CONFIG_SND=y

@@ -922,6 +917,11 @@
 # ALSA USB devices
 #
 # CONFIG_SND_USB_AUDIO is not set
+
+#
+# Open Sound System
+#
+# CONFIG_SOUND_PRIME is not set
 
 #
 # USB support

diff -Nru a/arch/ia64/defconfig b/arch/ia64/defconfig
@@ -657,6 +657,11 @@
 CONFIG_SOUND=y
 
 #
+# Advanced Linux Sound Architecture
+#
+# CONFIG_SND is not set
+
+#
 # Open Sound System
 #
 CONFIG_SOUND_PRIME=y

@@ -679,11 +684,6 @@
 # CONFIG_SOUND_VIA82CXXX is not set
 # CONFIG_SOUND_OSS is not set
 # CONFIG_SOUND_TVMIXER is not set
-
-#
-# Advanced Linux Sound Architecture
-#
-# CONFIG_SND is not set
 
 #
 # USB support

diff -Nru a/arch/parisc/defconfig b/arch/parisc/defconfig
@@ -643,14 +643,14 @@
 CONFIG_SOUND=y
 
 #
-# Open Sound System
+# Advanced Linux Sound Architecture
 #
-# CONFIG_SOUND_PRIME is not set
+# CONFIG_SND is not set
 
 #
-# Advanced Linux Sound Architecture
+# Open Sound System
 #
-# CONFIG_SND is not set
+# CONFIG_SOUND_PRIME is not set
 
 #
 # USB support

diff -Nru a/arch/sparc64/defconfig b/arch/sparc64/defconfig
@@ -710,11 +710,6 @@
 CONFIG_SOUND=m
 
 #
-# Open Sound System
-#
-# CONFIG_SOUND_PRIME is not set
-
-#
 # Advanced Linux Sound Architecture
 #
 CONFIG_SND=m

@@ -777,6 +772,11 @@
 #
 CONFIG_SND_SUN_AMD7930=m
 CONFIG_SND_SUN_CS4231=m
+
+#
+# Open Sound System
+#
+# CONFIG_SOUND_PRIME is not set
 
 #
 # USB support

I think this is generally marketed under the term "code reuse"

cheers,

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

So does that mean that we can look forward to Rob being a very productive leading Linux developer in four years time?

Naaaah.... ;)

What's happened to Rob??? He's been unusually quiet today! Too many tranquilizers? He must have passed out face down on his keyboard and the drool shorted it out ;)

Brian Tinsley
Chief Systems Engineer
Emageon

[...]

I guess in Chile it's "No hay peor sordo que el que no quiere oir".

There is no worse deaf than the one who refuses to listen. --
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

Alexander Kellett wrote:
[...]

It is hard for everybody - until we get used to it. Then it is just another normal thing. :-)

This is not flawed - but we actually need that compiler to exist, and become _common_ before replacing hand-optimizations with clean code. Feel free to join the gcc team and make the world better...

Helge Hafting

I should have changed the subject when I first sent this....

[re OSS vs ALSA audio drivers]
Linus> So I don't see a huge reason to remove them from the sources, Linus> but we might well make them harder to select by mistake, for Linus> example. Right now the config help files aren't exactly helpful, Linus> and the OSS choice is before the ALSA one, which looks wrong.

Linus> They should probably be marked deprecated, and if they don't Linus> get a lot of maintenance, that's fine.

Like this?

Also available from:

bk://cloos.bkbits.net/alsa-oss

[email protected], 2003-01-13 20:05:11-05:00, [email protected]
Move ALSA before OSS

 sound/Kconfig          |   26 ++++++++++++--------------
 arch/i386/defconfig    |   10 +++++-----
 arch/ia64/defconfig    |   10 +++++-----
 arch/parisc/defconfig  |    8 ++++----
 arch/sparc64/defconfig |   10 +++++-----
 5 files changed, 31 insertions(+), 33 deletions(-)

diff -Nru a/sound/Kconfig b/sound/Kconfig
@@ -1,20 +1,6 @@
 # sound/Config.in
 #
 
-menu "Open Sound System"
-	depends on SOUND!=n
-
-config SOUND_PRIME
-	tristate "Open Sound System"
-	depends on SOUND
-	help
-	  Say 'Y' or 'M' to enable Open Sound System drivers.
-
-source "sound/oss/Kconfig"
-
-endmenu
-
-
 menu "Advanced Linux Sound Architecture"
 	depends on SOUND!=n
 

@@ -42,3 +28,15 @@
 
 endmenu
 
+menu "Open Sound System"
+	depends on SOUND!=n
+
+config SOUND_PRIME
+	tristate "Open Sound System (DEPRECATED)"
+	depends on SOUND
+	help
+	  Say 'Y' or 'M' to enable Open Sound System drivers.
+
+source "sound/oss/Kconfig"
+
+endmenu

diff -Nru a/arch/i386/defconfig b/arch/i386/defconfig
@@ -839,11 +839,6 @@
 CONFIG_SOUND=y
 
 #
-# Open Sound System
-#
-# CONFIG_SOUND_PRIME is not set
-
-#
 # Advanced Linux Sound Architecture
 #
 CONFIG_SND=y

@@ -922,6 +917,11 @@
 # ALSA USB devices
 #
 # CONFIG_SND_USB_AUDIO is not set
+
+#
+# Open Sound System
+#
+# CONFIG_SOUND_PRIME is not set
 
 #
 # USB support

diff -Nru a/arch/ia64/defconfig b/arch/ia64/defconfig
@@ -657,6 +657,11 @@
 CONFIG_SOUND=y
 
 #
+# Advanced Linux Sound Architecture
+#
+# CONFIG_SND is not set
+
+#
 # Open Sound System
 #
 CONFIG_SOUND_PRIME=y

@@ -679,11 +684,6 @@
 # CONFIG_SOUND_VIA82CXXX is not set
 # CONFIG_SOUND_OSS is not set
 # CONFIG_SOUND_TVMIXER is not set
-
-#
-# Advanced Linux Sound Architecture
-#
-# CONFIG_SND is not set
 
 #
 # USB support

diff -Nru a/arch/parisc/defconfig b/arch/parisc/defconfig
@@ -643,14 +643,14 @@
 CONFIG_SOUND=y
 
 #
-# Open Sound System
+# Advanced Linux Sound Architecture
 #
-# CONFIG_SOUND_PRIME is not set
+# CONFIG_SND is not set
 
 #
-# Advanced Linux Sound Architecture
+# Open Sound System
 #
-# CONFIG_SND is not set
+# CONFIG_SOUND_PRIME is not set
 
 #
 # USB support

diff -Nru a/arch/sparc64/defconfig b/arch/sparc64/defconfig
@@ -710,11 +710,6 @@
 CONFIG_SOUND=m
 
 #
-# Open Sound System
-#
-# CONFIG_SOUND_PRIME is not set
-
-#
 # Advanced Linux Sound Architecture
 #
 CONFIG_SND=m

@@ -777,6 +772,11 @@
 #
 CONFIG_SND_SUN_AMD7930=m
 CONFIG_SND_SUN_CS4231=m
+
+#
+# Open Sound System
+#
+# CONFIG_SOUND_PRIME is not set
 
 #
 # USB support

-
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/

perl has a pretty nice one... you can label each construct to which break is applicable (ie, loop or whatever) then say "break foo" to escape that struture (and any others you happen to be inside.

TS> Whom do I pay to have this annoying clueless asshole shot? TS> OH MY GOD, I really can't take any more.

Well well well, is that how we act these days if we see something we don't like?

Anyway, I totally agree with Rob: if the code can be written without a goto and produce the same efficient assembly (or better, see Robs change) it should be written without it.
goto's are for lazy people

*judicious*

There's always the construction:

	for(;;)
	{
		/* do something */

		if (something_failed)
			break;

		/* do something */

		if (something_failed)
			break;

		...

		break;	/* the final break */
	}

	etc.