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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
