remove unimplemented syscalls noise

Hi guys, this is a simple patch which removes the really irritating sc<> messages that appear in logs. I haven't seen any reason to keep the messages, as they appear to be superfluous since the fact that some processes spit it doesn't effect their operation.

Regards,
--
Kyle McMartin <[email protected]>
System Administrator, The EngSoc Project
Faculty of Engineering, Carleton University

@@ -225,10 +225,6 @@
 		 unsigned long arg4, unsigned long arg5, unsigned long arg6, unsigned long arg7,
 		 unsigned long stack)
 {
-	struct pt_regs *regs = (struct pt_regs *) &stack;
-
-	printk(KERN_DEBUG "%s(%d): <sc%ld(%lx,%lx,%lx,%lx)>\n", current->comm, current->pid,
-	       regs->r15, arg0, arg1, arg2, arg3);
 	return -ENOSYS;
 }
 

Kyle> Hi guys, this is a simple patch which removes the really Kyle> irritating sc<> messages that appear in logs.

What's wrong with dmesg -n4? Those messages are marked KERN_DEBUG for a reason. BTW: Red Hat does this by default, but Debian doesn't. In my opinion, Red Hat does the right thing here: by default, most user's don't care about such messages, but they're invaluable when tracking down problems.

	--david

This is the same thing as printing the user unaligned exceptions. It's something no other architecture does, and for a reason, which has been explained to you before, but you don't want to fix it. *sigh*.

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Matthew> This is the same thing as printing the user unaligned Matthew> exceptions. It's something no other architecture does, and Matthew> for a reason, which has been explained to you before, but Matthew> you don't want to fix it.

And yet both features are incredibly useful when debugging, something you seem to ignore.

The printk-level is there for a _reason_. Why not use it?

	--david

Well, in the case of unaligned faults, there is no other way for an application to know that there were unaligned faults. Whereas for unsupported system calls, the kernel will return ENOSYS and thus the application gets the required notification (so that it can take any action it wants). It does not need to depend on dmesg stuff to find that information out.

So, it does make sense to remove this printk (even though it is _debug_) in this path.

for

In

user's

or

Robert

in

No, it *isn't*. The majority of systems in use are not being debugged (regardless of how you & I spend most of our time). Having these messages constantly stream past in dmesg (which no other architecture does) serves only to potentially mask other, useful pieces of information and confuse the customer.

Every time we emit something to the system log, it's a potential support call. Our friends in other parts of HP are already unhappy with how much output Linux produces even when everything's OK. It's also a sysadmin hassle as logfiles fill up more quickly when this kind of junk goes by.

I'm sure this was useful for debugging once, but those days are gone. We need to print less of this stuff. Something a lot of places do is:

#undef DEBUG

#ifdef DEBUG
#define DBG(x...) printk(x)
#else
#define DBG(x...)
#endif

Would it mollify you if these printks were turned into DBGs?

Or perhaps better, we could use pr_debug() from <linux/kernel.h>.

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Rohit> Well, in the case of unaligned faults, there is no other way Rohit> for an application to know that there were unaligned faults. Rohit> Whereas for unsupported system calls, the kernel will return Rohit> ENOSYS and thus the application gets the required Rohit> notification (so that it can take any action it wants). It Rohit> does not need to depend on dmesg stuff to find that Rohit> information out.

True in principle, but in practice, you can't always run strace to find out what's going on, either because the problem starts in early boot or because the problem is triggered indirectly through daemons etc.

Rohit> So, it does make sense to remove this printk (even though it Rohit> is _debug_) in this path.

I really much favor for distro's to make dmesg -n4 the default. There is no reason to bother average users with KERN_{NOTICE,INFO,DEBUG} stuff unless they ask for it.

	--david

Matthew> No, it *isn't*. The majority of systems in use are not Matthew> being debugged (regardless of how you & I spend most of our Matthew> time).

Please read my sentence: it's incredibly useful when _debugging_ a problem.

Nobody suggests to print those messages for normal users. dmesg -n4 will take care of them for good.

Matthew> Every time we emit something to the system log, it's a Matthew> potential support call. Our friends in other parts of HP Matthew> are already unhappy with how much output Linux produces Matthew> even when everything's OK. It's also a sysadmin hassle as Matthew> logfiles fill up more quickly when this kind of junk goes Matthew> by.

Can I say dmesg -n4??

Matthew> I'm sure this was useful for debugging once, but those days Matthew> are gone. We need to print less of this stuff. Something Matthew> a lot of places do is:

Matthew> #undef DEBUG

Matthew> #ifdef DEBUG #define DBG(x...) printk(x) #else #define Matthew> DBG(x...) #endif

Matthew> Would it mollify you if these printks were turned into Matthew> DBGs?

Nope. dmesg -n4 is adequate.

	--david

No, you can't. Users check their logfiles.

"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

I don't have an answer here, but some perspective to offer. Over the years we have found that customers will react to any message in the SYSLOG file. That is, you get the least grief by having messages appear there when you want the customer/administrator to take an action. If they are not to take an action, then don't show the message.

For debugging, we have used schemes which don't raise the debug data to the "normal system administration" procedures. Such as a private kernel logging buffer, dumped together with a kernel core dump, or viewable by a kernel debugger if you know where to look, etc. But not part of normal documented system admin procedures.

Of course for debugging we like good data...
FYI, Rich

Matthew> On Wed, Nov 19, 2003 at 12:33:17PM -0800, David Mosberger Matthew> wrote: Every time we emit something to the system log, it's Matthew> a potential support call. Our friends in other parts of HP Matthew> are already unhappy with how much output Linux produces Matthew> even when everything's OK. It's also a sysadmin hassle as Matthew> logfiles fill up more quickly when this kind of junk goes Matthew> by.

Matthew> No, you can't. Users check their logfiles.

syslog.conf?

I don't see how you can argue that debug/informational messages _shouldn't_ be displayed/logged for ordinary users under normal circumstances yet argue _for_ configuring syslog.conf to log precisely such messages.

I'm quite certain there are countless other ways for user-space to trigger lots of KERN_INFO/KERN_DEBUG messages. See kernel/sysctl.c or security/security.c, for example.

Having said that, I now realize that there is a problem:
ia64_ni_syscall() is/was intended for syscalls that were supposed to be implemented but were missing for some reason. Everything else should be handled by sys_ni_syscall. There are no such syscalls anymore, so I think what we should do is change entry.S from using ia64_ni_syscall to sys_ni_syscall (and if there are no callers of ia64_ni_syscall left, delete it). Want to send a patch?

	--david

Actually, in the interest of keeping the patch small, it's better to remove the printk message in ia64_ni_syscall() for 2.6.0 and then we can do the proper cleanup for 2.6.1.

	--david

I guess I agree that it is very useful for debugging. But maybe a different mechanism could be used. Instead of sending this to the general SYSLOG, why not use a signal (default being off). This would help interested users to catch the exception in the execution context.

If a user is debugging a problem, he can simply install a signal handler

Thanks

Matthias Fouquet-Lapar  Core Platform Software    [email protected]  VNET 521-8213
Principal Engineer      Silicon Graphics          Home Office (+33) 1 3047 4127