Messages in this thread | | | Date | Tue, 9 May 2006 09:02:02 -0700 | From | Andrew Morton <> | Subject | Re: [patch 1/17] Infrastructure to mark exported symbols as unused-for-removal-soon |
| |
Arjan van de Ven <arjan@linux.intel.com> wrote: > > As discussed on lkml before; the patch with the infrastructure to deprecate unused symbols > > This is patch one in a series of 17; to not overload lkml the other 16 will be mailed direct; > people who want to see them all can see them at http://www.fenrus.org/unused
A lot of these patches go through major APIs and seemingly-randomly prepare to unexport things based on whether they are presently used within modules.
So, for example, drivers/base/attribute_container.c gets a whole pile of exports scheduled for removal, regardless of whether the resulting module API makes *sense*. Ditto scsi core. And lib/*.
For example this:
EXPORT_SYMBOL(generic_getxattr); -EXPORT_SYMBOL(generic_listxattr); +EXPORT_UNUSED_SYMBOL(generic_listxattr); /* removal in 2.6.19 */ EXPORT_SYMBOL(generic_setxattr); EXPORT_SYMBOL(generic_removexattr);
just seems random to me, and it's setting us up for later churn.
So hum. Don't you think it'd be better to look at each API as a whole, make decisions about what parts of it _should_ be offered to modules, rather then looking empirically at which parts presently _need_ to be exported?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |