Re: [Q] warning BUG() related fixing and janitors question

[Dan Carpenter <dan.carpenter@oracle.com>]

On Mon, Apr 16, 2012 at 04:03:28PM -0300, Ezequiel García wrote:
> Hi Dan,
> 
> I would like to know better about the janitors list, and what kind of
> patches are handled here.

We don't actually handle any patches any more.  It is a place to
help newbies, or if we are working on similar code then we CC the
list so not everyone sends the same patch 7 times, and also it's
for review.  Send patches to the people from
./scripts/get_maintainer.pl and CC kernel-janitors if you want.

> I've found a number of warnings in my building and I'm not sure where to
> send patches and
> what git tree should I take, since the warnings appear in a wide number of
> subsystems.
> 
> 1.
> For instance, in kernel/sched/core.c
> 
> static inline struct task_struct *
> pick_next_task(struct rq *rq)
> {
>     /* snip */
>     BUG(); /* the idle class will always have a runnable task */
> }
> 
> You can see that after BUG there is no return statement, which will produce
> a compilation
> warning you disable BUG() and it gets defined to nothing.
> 
> There are several of these warnings here and there, I guess as a consequence
> of BUG() macro.
> 

Don't start messing in scheduler code if you have any doubts about
what you are doing.  My advise is don't send a patch for this
warning.  Most times people leave BUG() enabled so we don't really
care about the warning.

> ---
> 2.
> Another one is flat_set_persistent() which is only IMO properly defined in
> arch/sh/. The current
> definition produces a warning in other architectures if binary flat format
> is used.
> 
> So, I guess I should send a patch to each arch-specific list, right? using
> arch-specific git trees?
> I would like to have just one git tree, and not ten :)

I'm not sure what you mean here.  What is the warning?  It sounds
like something is wrong in a Kconfig file.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html