Skip to contentSkip to conversation

more deprectation bits

PATCH In review Christoph Hellwig 4 participants 8 messages Dec 29, 2002 – Dec 31, 2002

Subsystems (3)
Scheduler Sparse checker Module support
lore
Share & tools
lore

Christoph Hellwig

author
#0 lore raw

PATCH 1/1 more deprectation bits

Rename the deprecated attribute to __deprecated to make it obvious this is something special and to avoid namespace clashes.

Mark more functionality deprecated:

- sleep_on & friends
- old module interfaces

This gives quite a lot warnings, I'll start to fix the ones in core code and stuff I maintain now..

include/linux/compiler.h +2 -2
@@ -21,9 +21,9 @@
  * and then gcc will emit a warning for each usage of the function.
  */
 #if __GNUC__ >= 3
-#define deprecated	__attribute__((deprecated))
+#define __deprecated	__attribute__((deprecated))
 #else
-#define deprecated
+#define __deprecated
 #endif
 
 /* This macro obfuscates arithmetic on a variable address so that gcc
include/linux/ioport.h +1 -1
@@ -108,7 +108,7 @@
 #define check_mem_region(start,n)	__check_region(&iomem_resource, (start), (n))
 #define release_mem_region(start,n)	__release_region(&iomem_resource, (start), (n))
 
-extern int deprecated __check_region(struct resource *, unsigned long, unsigned long);
+extern int __deprecated __check_region(struct resource *, unsigned long, unsigned long);
 extern void __release_region(struct resource *, unsigned long, unsigned long);
 
 #define get_ioport_list(buf)	get_resource_list(&ioport_resource, buf, PAGE_SIZE)
include/linux/module.h +26 -9
@@ -296,9 +296,20 @@
 #define symbol_request(x) try_then_request_module(symbol_get(x), "symbol:" #x)
 
 /* BELOW HERE ALL THESE ARE OBSOLETE AND WILL VANISH */
-#define __MOD_INC_USE_COUNT(mod) \
-	do { __unsafe(mod); (void)try_module_get(mod); } while(0)
-#define __MOD_DEC_USE_COUNT(mod) module_put(mod)
+static inline void __deprecated __MOD_INC_USE_COUNT(struct module *module)
+{
+	__unsafe(module);
+	/*
+	 * Yes, we ignore the retval here, that's why it's deprecated.
+	 */
+	try_module_get(module);
+}
+
+static inline void __deprecated __MOD_DEC_USE_COUNT(struct module *module)
+{
+	module_put(module);
+}
+
 #define SET_MODULE_OWNER(dev) ((dev)->owner = THIS_MODULE)
 
 struct obsolete_modparm {

@@ -319,14 +330,21 @@
 /* People do this inside their init routines, when the module isn't
    "live" yet.  They should no longer be doing that, but
    meanwhile... */
+static inline void __deprecated _MOD_INC_USE_COUNT(struct module *module)
+{
+	__unsafe(module);
+
 #if defined(CONFIG_MODULE_UNLOAD) && defined(MODULE)
-#define MOD_INC_USE_COUNT	\
-	do { __unsafe(THIS_MODULE); local_inc(&THIS_MODULE->ref[get_cpu()].count); put_cpu(); } while (0)
+	local_inc(&module->ref[get_cpu()].count);
+	put_cpu();
 #else
-#define MOD_INC_USE_COUNT \
-	do { __unsafe(THIS_MODULE); (void)try_module_get(THIS_MODULE); } while (0)
+	try_module_get(module);
 #endif
-#define MOD_DEC_USE_COUNT module_put(THIS_MODULE)
+}
+#define MOD_INC_USE_COUNT \
+	_MOD_INC_USE_COUNT(THIS_MODULE)
+#define MOD_DEC_USE_COUNT \
+	__MOD_DEC_USE_COUNT(THIS_MODULE)
 #define try_inc_mod_count(mod) try_module_get(mod)
 #define EXPORT_NO_SYMBOLS
 extern int module_dummy_usage;

@@ -364,5 +382,4 @@
 extern const void *inter_module_get(const char *);
 extern const void *inter_module_get_request(const char *, const char *);
 extern void inter_module_put(const char *);
-
 #endif /* _LINUX_MODULE_H */
include/linux/wait.h +5 -4
@@ -11,6 +11,7 @@
 #ifdef __KERNEL__
 
 #include <linux/config.h>
+#include <linux/compiler.h>
 #include <linux/list.h>
 #include <linux/stddef.h>
 #include <linux/spinlock.h>

@@ -244,11 +245,11 @@
  * They are racy.  DO NOT use them, use the wait_event* interfaces above.  
  * We plan to remove these interfaces during 2.7.
  */
-extern void FASTCALL(sleep_on(wait_queue_head_t *q));
-extern long FASTCALL(sleep_on_timeout(wait_queue_head_t *q,
+extern void __deprecated FASTCALL(sleep_on(wait_queue_head_t *q));
+extern long __deprecated FASTCALL(sleep_on_timeout(wait_queue_head_t *q,
 				      signed long timeout));
-extern void FASTCALL(interruptible_sleep_on(wait_queue_head_t *q));
-extern long FASTCALL(interruptible_sleep_on_timeout(wait_queue_head_t *q,
+extern void __deprecated FASTCALL(interruptible_sleep_on(wait_queue_head_t *q));
+extern long __deprecated FASTCALL(interruptible_sleep_on_timeout(wait_queue_head_t *q,
 						    signed long timeout));
 
 /*
kernel/resource.c +1 -1
@@ -237,7 +237,7 @@
 	return res;
 }
 
-int deprecated __check_region(struct resource *parent, unsigned long start, unsigned long n)
+int __deprecated __check_region(struct resource *parent, unsigned long start, unsigned long n)
 {
 	struct resource * res;

===== kernel/sched.c 1.145 vs edited =====

kernel/sched.c +4 -4
@@ -1238,7 +1238,7 @@
 	__remove_wait_queue(q, &wait);				\
 	spin_unlock_irqrestore(&q->lock, flags);
 
-void interruptible_sleep_on(wait_queue_head_t *q)
+void __deprecated interruptible_sleep_on(wait_queue_head_t *q)
 {
 	SLEEP_ON_VAR
 

@@ -1249,7 +1249,7 @@
 	SLEEP_ON_TAIL
 }
 
-long interruptible_sleep_on_timeout(wait_queue_head_t *q, long timeout)
+long __deprecated interruptible_sleep_on_timeout(wait_queue_head_t *q, long timeout)
 {
 	SLEEP_ON_VAR
 

@@ -1262,7 +1262,7 @@
 	return timeout;
 }
 
-void sleep_on(wait_queue_head_t *q)
+void __deprecated sleep_on(wait_queue_head_t *q)
 {
 	SLEEP_ON_VAR
 	

@@ -1273,7 +1273,7 @@
 	SLEEP_ON_TAIL
 }
 
-long sleep_on_timeout(wait_queue_head_t *q, long timeout)
+long __deprecated sleep_on_timeout(wait_queue_head_t *q, long timeout)
 {
 	SLEEP_ON_VAR
#1 lore raw
Quoted 7 lines · Christoph Hellwig

Rename the deprecated attribute to __deprecated to make it obvious this is something special and to avoid namespace clashes.

Mark more functionality deprecated:

- sleep_on & friends

Please do not make sleep_on() generate a warning. Unless you intend to do the same to lock_kernel().

ext3 uses sleep_on(). It is perfectly safe. Weaning ext3 off lock_kernel()
is a large, delicate and thus-far undesigned body of work. I've been working on other stuff and it is quite unlikely that ext3 locking will be redesigned in the 2.5 timeframe.

Quoted 4 lines

- old module interfaces

This gives quite a lot warnings, I'll start to fix the ones in core code and stuff I maintain now..

Sounds like pointless churn to me. How about we fix some real stuff and get this kernel out the door before we all die?

author
#2 lore raw
Quoted 5 lines · Andrew Morton
Quoted 4 lines · Christoph Hellwig

Rename the deprecated attribute to __deprecated to make it obvious this is something special and to avoid namespace clashes.

Quoted 8 lines
Quoted 3 lines

Mark more functionality deprecated:

- sleep_on & friends

Please do not make sleep_on() generate a warning. Unless you intend to do the same to lock_kernel().

ext3 uses sleep_on(). It is perfectly safe.

Even if it's safe in that particular case, most code in the kernel runs without BKL. This patch just makes the deprication of sleep_on explicit.

Quoted 4 lines

Weaning ext3 off lock_kernel()
is a large, delicate and thus-far undesigned body of work. I've been working on other stuff and it is quite unlikely that ext3 locking will be redesigned in the 2.5 timeframe.

Then ext3 has to live with using depricated interfaces during 2.6, what's the point?

#3 lore raw
Quoted 11 lines · Christoph Hellwig
Quoted 9 lines · Andrew Morton
Quoted 7 lines · Christoph Hellwig

Rename the deprecated attribute to __deprecated to make it obvious this is something special and to avoid namespace clashes.

Mark more functionality deprecated:

- sleep_on & friends

Quoted 8 lines
Quoted 4 lines

Please do not make sleep_on() generate a warning. Unless you intend to do the same to lock_kernel().

ext3 uses sleep_on(). It is perfectly safe.

Even if it's safe in that particular case, most code in the kernel runs without BKL. This patch just makes the deprication of sleep_on explicit.

This would be more appropriate:

kernel/sched.c renamed from kernel/sched.c~a +7 -0
@@ -1264,7 +1264,14 @@ long interruptible_sleep_on_timeout(wait
 
 void sleep_on(wait_queue_head_t *q)
 {
+	static int count;
+
 	SLEEP_ON_VAR
+
+	if (count < 10 && !kernel_locked()) {
+		count++;
+		WARN_ON(1);
+	}
 	
 	current->state = TASK_UNINTERRUPTIBLE;
Quoted 7 lines
Quoted 4 lines

Weaning ext3 off lock_kernel()
is a large, delicate and thus-far undesigned body of work. I've been working on other stuff and it is quite unlikely that ext3 locking will be redesigned in the 2.5 timeframe.

Then ext3 has to live with using depricated interfaces during 2.6, what's the point?

We shouldn't generate tons of bogus warnings for something which everyone knows about anyway.

author
#4 lore raw
Quoted 5 lines · Andrew Morton
Quoted 3 lines

Even if it's safe in that particular case, most code in the kernel runs without BKL. This patch just makes the deprication of sleep_on explicit.

This would be more appropriate:

I don't think so. As you said before sleep_on is perfectly fine for the small part of code still covered by BKL, so we should not impose any runtime overhead (i.e. warnings) but rather remind at compile time.

That's what's so nice with the gcc extension (and you won't see it anyway as long as you stay at egcs 1.1 :))

#5 lore raw
Quoted 6 lines · Christoph Hellwig
Quoted 4 lines · Andrew Morton
Quoted 3 lines

Even if it's safe in that particular case, most code in the kernel runs without BKL. This patch just makes the deprication of sleep_on explicit.

Quoted 8 lines
Quoted 1 line

This would be more appropriate:

I don't think so. As you said before sleep_on is perfectly fine for the small part of code still covered by BKL, so we should not impose any runtime overhead (i.e. warnings) but rather remind at compile time.

That's what's so nice with the gcc extension (and you won't see it anyway as long as you stay at egcs 1.1 :))

Others will. It will result in developers being distracted into "fixing" non-bugs. It will introduce risk and it will delay the release of the 2.6 kernel.

Please concentrate on things which *matter*. Focus on getting this piece of software into a deliverable state and do not be distracted into futzing about with stuff which clearly was not addressed at the appropriate time.

#6 lore raw
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines

Even if it's safe in that particular case, most code in the kernel runs without BKL. This patch just makes the deprication of sleep_on explicit.

This would be more appropriate:

I don't think so. As you said before sleep_on is perfectly fine for the small part of code still covered by BKL, so we should not impose any runtime overhead (i.e. warnings) but rather remind at compile time.

Especially as the fact that EXT-3 makes use of it doesn't affect anybody writing user land apps. There isn't much point in warning about things that are only relevant to readers of this list anyway.

Quoted 2 lines
Quoted 2 lines

That's what's so nice with the gcc extension (and you won't see it anyway as long as you stay at egcs 1.1 :))

How long are we staying at 2.95.3 as the recommended compiler? A lot of people have been using 3.x with the 2.5 tree successfully for a while. What will be the recommended compiler for 2.6?

Quoted 3 lines

Others will. It will result in developers being distracted into "fixing" non-bugs. It will introduce risk and it will delay the release of the 2.6 kernel.

featurefreeze()
{

Quoted 3 lines

Please concentrate on things which *matter*. Focus on getting this piece of software into a deliverable state and do not be distracted into futzing about with stuff which clearly was not addressed at the appropriate time.

}

John.

#7 lore raw
In reply to Andrew Morton
Quoted 2 lines · Andrew Morton

We shouldn't generate tons of bogus warnings for something which everyone knows about anyway.

You could make the argument that we don't need to generate ANY bogus warnings. For anything.

My feeling on the issue, there are lots of things in the to-do queue, filling logs with warnings is a good way to get even more "what does this warning mean" messages to the list and newsgroups.

Signature · 3 lines
bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.