Re: [linuxsh-dev] Drop-In tree updates

[Robert L. <rm...@te...>]

On Wed, 2001-12-05 at 13:03, Jeremy Siegel wrote:

> ...I think that to encourage a general API rewrite the ugliness has to be in
> the kernel.org tree; if it's only in the linuxsh tree only we will care.  If
> I had
> to compare #if 0 and #ifndef CONFIG_SUPERH I'd guess the latter would
> be more likely to be accepted.  (I know it's generally frowned upon anyway,
> but it might get someone thinking; the #if 0 submission would probably be
> banned outright.)

I think the #if !defined(CONFIG_SH) is still enough to show a rewrite is
needed.  We should really aim for no ifdefs in code if at all possible
-- the function/define definitions should provide the conditional
compiling.

> Another minor point: even in the linuxsh tree itself, using CONFIG helps
> make it clear that this is deliberate, and not leftover/experimental hackery.
> (Maybe that's one of the other "multiple reasons" Robert refers to;-)

Exactly.  That is one reason.  Another is that the #if 0 makes the tree
instantly incompatible with any arch other than SH.  The SH tree should
be fully compatible with all arches, so that we can resync with each
other.  For instance, we can push the #if defined to the mainline
kernel.  We would have to wear a brown paper bag for a month if we sent
the #if 0 off.

Which brings me to the next point ... the trees are way out of sync. 
When was the last time someone pushed an SH merge off to the official
kernel?  Thankfully, Jeremy just merged official into SH but we need it
the other way around now.

I would be happy to put together a diff against the latest 2.4 and 2.5
and send it off to Marcelo and Linus for merging into their tree.  I
suspect it will take some work to make sure we keep the code correct
(ie, nothing like the #if 0 stuff).  I would want the maintainer's
permission before I do this.

Second, with 2.5 starting, we need conversion to both CML2 and
kbuild-2.5.  Both are non-trivial changes.  The SH port is the _only_
piece of the kernel non-synced with CML2, supposedly at the maintainer's
request that he do it?  Also, SH items in Configure.help are very
lacking.  CML2 will _not_ allow an item to be selected if in non-expert
mode if it has no configure help!  And kbuild-2.5 will require a rewrite
of our makefiles...

I'm offering my help.  Comments?

	Robert Love