> > Perhaps you've got lots of patches were people are using internal APIs theyExactly. Or rather it is not defined on the module level. We got "static" of course, but I think we should have a similar mechanism on a module level. It would not be fully supported either -- can still change etc. -- but there is a reasonable expectation that those external APIs will change less often than internal interfaces. That is EXPORT_SYMBOL already. The trouble is just that it covers too much. My patchkit is trying to limit it again for a specific use case -- exporting an "internal" interface to another module. Or rather a set of modules. Standard example is TCP: TCP exports nearly everything and the single user is the TCP code in ipv6.ko. Instead those symbols should be limited to be only accessable to ipv6.ko. The reason I went with the more generic namespace mechanism instead of EXPORT_SYMBOL_TO() is that ipv6 is ever split up it would still work. Also using namespaces doesn't have any more overhead than EXPORT_SYMBOL_TO() and the complexity is about the same (not very much anyways -- just look at the patches) That is another reason. -ANdi -
| Jeff Garzik | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Christoph Hellwig | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Emmanuel Dreyfus | fixing send(2) semantics (kern/29750) |
| Christos Zoulas | Re: Melting down your network [Subject changed] |
| Juan RP | Changing the I/O scheduler on-the-fly |
| Emmanuel Dreyfus | Re: fixing send(2) semantics (kern/29750) |
