[KJ] ruminations on kernel.h

[KJ] ruminations on kernel.h

[Robert P. J. Day]

  just thinking out loud here, but does anyone else think that the
header file include/linux/kernel.h is a little ... unstructured?
IMHO, i would think that it would make more sense to partition a lot
of the content of that file into other (and possibly newer) header
files.

  to begin with, all of the preliminary macros of the form
{INT/LONG_MIN/MAX} would seem to be more at home in limits.h, to more
match the headers for glibc.  (yes, i realize there's no *obligation*
to do it the way glibc does it, but it would at least look more
familiar to userspace programmers.)

  the various utility macros (ARRAY_SIZE, FIELD_SIZE, min/max,
container_of, etc.) might fit better into a file called macros.h or
util.h.

  then there's all the debugging/logging stuff -- the priority macros,
loglevel stuff, pr_debug, pr_info, etc.  why not a new file called
"debug.h"?

  anyway, you get the idea.  there doesn't seem to be much rhyme or
reason for what has been tossed into kernel.h.

  thoughts?  i might whip up a patch just to get some feedback.

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] ruminations on kernel.h

[Matthew Wilcox]

On Sun, Jan 07, 2007 at 03:24:41PM -0500, Robert P. J. Day wrote:
>   the various utility macros (ARRAY_SIZE, FIELD_SIZE, min/max,
> container_of, etc.) might fit better into a file called macros.h or
> util.h.
> 
>   then there's all the debugging/logging stuff -- the priority macros,
> loglevel stuff, pr_debug, pr_info, etc.  why not a new file called
> "debug.h"?
> 
>   anyway, you get the idea.  there doesn't seem to be much rhyme or
> reason for what has been tossed into kernel.h.

Well, kernel.h really is misc.h or util.h ;-)
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] ruminations on kernel.h

[Robert P. J. Day]

On Sun, 7 Jan 2007, Matthew Wilcox wrote:

> On Sun, Jan 07, 2007 at 03:24:41PM -0500, Robert P. J. Day wrote:
> >   the various utility macros (ARRAY_SIZE, FIELD_SIZE, min/max,
> > container_of, etc.) might fit better into a file called macros.h or
> > util.h.
> >
> >   then there's all the debugging/logging stuff -- the priority macros,
> > loglevel stuff, pr_debug, pr_info, etc.  why not a new file called
> > "debug.h"?
> >
> >   anyway, you get the idea.  there doesn't seem to be much rhyme or
> > reason for what has been tossed into kernel.h.
>
> Well, kernel.h really is misc.h or util.h ;-)

but, actually, it isn't.  as i mentioned, there's *plenty* in there
that really *does* seem to belong in other, more appropriate files.
having all that stuff dumped in kernel.h just makes it that much
harder to make an educated guess as to where to find things like
macros and function declarations and the like.

as another example, the function declarations for the
simple_strto[u]l[l] routines are in kernel.h, but their
implementations are in lib/vsprintf.c.  if i was looking for that
stuff, i would never have guessed that.

and there's lots more where that came from.

rday

p.s.  and having stuff scattered around the tree like that also makes
it harder to generate the kernel-doc output, since you typically have
to gather a number of widely-separated files just to generate the
documentation for a single section.
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] ruminations on kernel.h

[Matthew Wilcox]

On Sun, Jan 07, 2007 at 03:55:11PM -0500, Robert P. J. Day wrote:
> On Sun, 7 Jan 2007, Matthew Wilcox wrote:
> > Well, kernel.h really is misc.h or util.h ;-)
> 
> but, actually, it isn't.  as i mentioned, there's *plenty* in there
> that really *does* seem to belong in other, more appropriate files.
> having all that stuff dumped in kernel.h just makes it that much
> harder to make an educated guess as to where to find things like
> macros and function declarations and the like.

By all means move stuff that seems more appropriate elsewhere.
My point was to *not* create a misc.h or util.h

> as another example, the function declarations for the
> simple_strto[u]l[l] routines are in kernel.h, but their
> implementations are in lib/vsprintf.c.  if i was looking for that
> stuff, i would never have guessed that.

I'd suggest <linux/string.h> would be a better place for those.

> and there's lots more where that came from.

Of course.  There's an almost infinite amount of cruft to deal with,
that's why there's this janitor list ...
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] ruminations on kernel.h

[Ahmed S. Darwish]

On Sun, Jan 07, 2007 at 03:24:41PM -0500, Robert P. J. Day wrote:
> 
>   just thinking out loud here, but does anyone else think that the
> header file include/linux/kernel.h is a little ... unstructured?
> IMHO, i would think that it would make more sense to partition a lot
> of the content of that file into other (and possibly newer) header
> files.
> 

I think so too, Kernel.h is just a collection of loosly connected maros.
Even the naming of the header relate nothing to its contents (printk Macros,
container_of, ..).
But will the community accept it easily ?. I mean this will mean patching a very
big number of files to use the new names/header files.

>   thoughts?  i might whip up a patch just to get some feedback.

If the community accepted it, I have some time to handle the task of patching 
the files to use the new header files.

-- 
Ahmed S. Darwish
http://darwish-07.blogspot.com
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] ruminations on kernel.h

[Paul Bonser]

On 1/7/07, Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> I think so too, Kernel.h is just a collection of loosly connected maros.
> Even the naming of the header relate nothing to its contents (printk Macros,
> container_of, ..).
> But will the community accept it easily ?. I mean this will mean patching a very
> big number of files to use the new names/header files.
>
> >   thoughts?  i might whip up a patch just to get some feedback.
>
> If the community accepted it, I have some time to handle the task of patching
> the files to use the new header files.

As a temporary step, kernel.h could be changed to include the files
that the macros are partitioned out into, and then it could be
encouraged to include only the actual needed files in any newly
created files and the existing files that include kernel.h could be
more slowly converted over to just include the files they need.
What does everyone think of this idea? Is it too much of a hack, or a
more graceful way to transition?

-- 
Paul Bonser
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

Re: [KJ] ruminations on kernel.h

[Robert P. J. Day]

On Sun, 7 Jan 2007, Paul Bonser wrote:

> On 1/7/07, Ahmed S. Darwish <darwish.07@gmail.com> wrote:
> > I think so too, Kernel.h is just a collection of loosly connected maros.
> > Even the naming of the header relate nothing to its contents (printk Macros,
> > container_of, ..).
> > But will the community accept it easily ?. I mean this will mean patching a
> > very
> > big number of files to use the new names/header files.
> >
> > >   thoughts?  i might whip up a patch just to get some feedback.
> >
> > If the community accepted it, I have some time to handle the task of
> > patching
> > the files to use the new header files.
>
> As a temporary step, kernel.h could be changed to include the files
> that the macros are partitioned out into, and then it could be
> encouraged to include only the actual needed files in any newly
> created files and the existing files that include kernel.h could be
> more slowly converted over to just include the files they need. What
> does everyone think of this idea? Is it too much of a hack, or a
> more graceful way to transition?

that's exactly the approach i was thinking of, to minimize the
disruption.  and the advantage would be that it might make the
generated kernel-doc output more organized, since you could include
those header files individually and break the kernel-doc into more
independent chunks.

i'll give it some more thought.  there's little point trying anything
like this until 2.6.20 is out.

rday
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors