Currently the Linux kernel has a cryptic api namespace that confuses
many people when trying to code for the Linux kernel. People can't know
by direct examination of a symbol to what package belongs. Also symbols
can't be easily sorted by package.
I'm suggesting to use a cleaner namespace like
package_object_method and package_function
If this is accepted, symbols from new code should follow this
naming, and current symbols should start the transition to this cleaner
namespace.
If anybody like me think that this would help people to code for the
Linux kernel it would be a good idea to start this transition to a
cleaner namespace.
Most drivers and new core kernel api have a very clean namespace but
some old api don't.
What are your thoughts about this ?
Eduardo P?rez wrote:
>
> Currently the Linux kernel has a cryptic api namespace that confuses
> many people when trying to code for the Linux kernel. People can't know
> by direct examination of a symbol to what package belongs. Also symbols
> can't be easily sorted by package.
>
> I'm suggesting to use a cleaner namespace like
> package_object_method and package_function
> If this is accepted, symbols from new code should follow this
> naming, and current symbols should start the transition to this cleaner
> namespace.
>
> If anybody like me think that this would help people to code for the
> Linux kernel it would be a good idea to start this transition to a
> cleaner namespace.
>
> Most drivers and new core kernel api have a very clean namespace but
> some old api don't.
>
> What are your thoughts about this ?
Then if it is a static symbol, one could use anything? I.e.
static symbols would not follow the rule, right?
--
George Anzinger [email protected]
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
On 2002-10-07 08:16:02 -0700, george anzinger wrote:
> Eduardo P?rez wrote:
> > Currently the Linux kernel has a cryptic api namespace that confuses
> > many people when trying to code for the Linux kernel. People can't know
> > by direct examination of a symbol to what package belongs. Also symbols
> > can't be easily sorted by package.
> >
> > I'm suggesting to use a cleaner namespace like
> > package_object_method and package_function
> > If this is accepted, symbols from new code should follow this
> > naming, and current symbols should start the transition to this cleaner
> > namespace.
> >
> > If anybody like me think that this would help people to code for the
> > Linux kernel it would be a good idea to start this transition to a
> > cleaner namespace.
> >
> > Most drivers and new core kernel api have a very clean namespace but
> > some old api don't.
> >
> > What are your thoughts about this ?
>
> Then if it is a static symbol, one could use anything? I.e.
> static symbols would not follow the rule, right?
Yes, static symbols don't need to be prefixed as they are not public api
It's a good idea to have them prefixed if you want to search for them in
a sorted symbol list or in System.map