Re: [linuxsh-dev] byteorder.h from elf.h

[Greg B. <gb...@po...>]

NIIBE Yutaka wrote:
> 
>  >   Probably because it's easier to create an empty header than fix
>  > all the cruft throughout the kernel.
> 
> Yes.  Technically speaking, adding the file is the wrong thing,

  Yes, agreed.

>  >   Sure, but does the SuperH team have to be the one to feel this
>  > pressure?  It's not a SuperH-specific issue.
> 
> All other ports has asm/segment.h, so, none will notice about the
> issue.  Only SuperH doesn't have the file from the beginning.

  True, but again why us?  Surely this is a job for the kernel janitors?

>  >   But can we wait with removing segment.h until those changes percolate
>  > back through the mainline kernel?
> 
> Well, it's OK to add the file containing some comments ("this file
> should not exist" or something like that).  Please do that if you
> really need it.  

  Hmm, see below.

> Perhaps, I don't send it to mainline.

  Fair enough.  No need to *propagate* cruft.

> I like following implementation, but I guess none agrees :-)
> --------- asm-sh/segment.h
> #error "It is obsolete to include this file.  Please fix."
> ---------

  There's no practical difference between this and not having
the file: in each case the preprocessor spits an error and
the build fails.

> As time permits, I keep removing the inclusion.

  Well, it's really up to you.

  Having these diffs in the SuperH port as we have now, is going
to create a small amount of extra work for the person does the
merges for the drop-in tree (which I expect will eventually be
yourself).  This will be much less work than using the drop-in
tree will save in the first place.

  If you think removing the spurious includes is worth the
extra effort, then fine, we can do it that way.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.