Skip to contentSkip to conversation

unexport insert_resource

PATCH In review Adrian Bunk 4 participants 7 messages Apr 15, 2005 – May 2, 2005 Documentation

lore
Share & tools
lore

Adrian Bunk

author
#0 lore raw

PATCH 1/1 unexport insert_resource

I didn't find any possible modular usage in the kernel.

Signed-off-by Adrian Bunk <[email protected]>

---

This patch was already sent on:
- 4 Mar 2005

kernel/resource.c renamed from kernel/resource.c.old +0 -2
@@ -371,8 +371,6 @@
 	return result;
 }
 
-EXPORT_SYMBOL(insert_resource);
-
 /*
  * Given an existing resource, change its start and size to match the
  * arguments.  Returns -EBUSY if it can't fit.  Existing children of
#1 lore raw
Quoted 3 lines · Adrian Bunk

I didn't find any possible modular usage in the kernel.

True, but this looks like something which out-of-tree code could possibly be using. I'd prefer to see this one get the deprecated_for_modules twelve-month treatment.

Or we just leave it as-is. It depends whether insert_resource is a sensible part of the resource management API (I think it is). If so, then we should just leave it exported, whether or not any in-kernel moduels happen to be using it at this point in time.

Quoted 12 lines
kernel/resource.c renamed from kernel/resource.c.old +0 -2
@@ -371,8 +371,6 @@
 	return result;
 }
 
-EXPORT_SYMBOL(insert_resource);
-
 /*
  * Given an existing resource, change its start and size to match the
  * arguments.  Returns -EBUSY if it can't fit.  Existing children of
#2 lore raw
Quoted 5 lines

Or we just leave it as-is. It depends whether insert_resource is a sensible part of the resource management API (I think it is). If so, then we should just leave it exported, whether or not any in-kernel moduels happen to be using it at this point in time.

well it's sensible for platform code to announce resources sure. Drivers generally only consume resources though and don't introduce them...

#3 lore raw
In reply to Andrew Morton
Quoted 8 lines · Andrew Morton
Quoted 3 lines · Adrian Bunk

I didn't find any possible modular usage in the kernel.

True, but this looks like something which out-of-tree code could possibly be using. I'd prefer to see this one get the deprecated_for_modules twelve-month treatment.

Don't you think twelve month is damn long? Two kernel releases seem like a better policy - extremly long deprecation periods only encourage people to never look at mainline kernels but just ad vendor trees.

Quoted 4 lines

Or we just leave it as-is. It depends whether insert_resource is a sensible part of the resource management API (I think it is). If so, then we should just leave it exported, whether or not any in-kernel moduels happen to be using it at this point in time.

It makes sense for plattforms or bus implementations. So for typical drivers it doesn't make sense at all. It might make sense for bus providers, and in case a modular one that wants this symbol appears we could re-export it as _GPL, clearly marking it internal.

Note that you're not really helping driver authors by exporting random kernel symbols - that way we can never guarantee a semi-stable API as random internals are exported. Compare that with e.g. the scsi subsystem where we're trying to make sure to only export sensible primitives that operate on higher-level object to the driver and make sure they're moving off old and ill-specified APIs.

#4 lore raw
Quoted 7 lines · Christoph Hellwig
Quoted 5 lines · Andrew Morton
Quoted 3 lines · Adrian Bunk

I didn't find any possible modular usage in the kernel.

Quoted 7 lines
Quoted 3 lines

True, but this looks like something which out-of-tree code could possibly be using. I'd prefer to see this one get the deprecated_for_modules twelve-month treatment.

Don't you think twelve month is damn long? Two kernel releases seem like a better policy - extremly long deprecation periods only encourage people to never look at mainline kernels but just ad vendor trees.

A year ago we were at 2.6.6. It's not that long, really.

Quoted 2 lines

Note that you're not really helping driver authors by exporting random kernel symbols

We can mark these things as deprecated-in-modules today, to avoid new usages.

author
#5 lore raw

PATCH 1/1 __deprecated_for_modules insert_resource

In reply to Andrew Morton
Quoted 9 lines · Andrew Morton
Quoted 3 lines · Adrian Bunk

I didn't find any possible modular usage in the kernel.

True, but this looks like something which out-of-tree code could possibly be using. I'd prefer to see this one get the deprecated_for_modules twelve-month treatment.
...

Patch below.

cu
Adrian

<-- snip -->

Documentation/feature-removal-schedule.txt renamed from Documentation/feature-removal-schedule.txt.old +8 -0
@@ -57,0 +58,8 @@
+
+---------------------------
+
+What:	remove EXPORT_SYMBOL(insert_resource)
+When:	April 2006
+Files:	kernel/resource.c
+Why:	No modular usage in the kernel.
+Who:	Adrian Bunk <[email protected]>
include/linux/ioport.h renamed from include/linux/ioport.h.old +1 -1
@@ -97 +97 @@
-extern int insert_resource(struct resource *parent, struct resource *new);
+extern __deprecated_for_modules int insert_resource(struct resource *parent, struct resource *new);
#6 lore raw

Re: [2.6 patch] __deprecated_for_modules insert_resource

Documentation/feature-removal-schedule.txt line 63

Quoted 10 lines
Documentation/feature-removal-schedule.txt renamed from Documentation/feature-removal-schedule.txt.old +6 -0
@@ -57,0 +58,8 @@
+
+---------------------------
+
+What:	remove EXPORT_SYMBOL(insert_resource)
+When:	April 2006
+Files:	kernel/resource.c

12 months is a really long time for something that's quite unlikely to be used; how about 3 to 6 months?