[U-Boot] [PATCH] flash.h: pull in common.h for types

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday 17 November 2009 16:56:58 Wolfgang Denk wrote:
> Scott Wood wrote:
> > > My question: is there a definitive position  somewhere  (for  example
> > > for  the  Linux kernel; I'm sure we don't have one for U-Boot [yet]),
> > > whether system headers should be self-sufficient?
> >
> > I'd say they should be self-sufficient, in that the inclusion of the
> > header itself should not fail if I haven't included some arbitrary other
> > header.  I don't see what the argument would be for not doing this.
> 
> Well, Theo de Raadt says for example "... people would be able to
> include less files; indeed, almost be careless about what they
> include. But this would not increase portability in any way. And
> 'make build' would probably, if it was taken the nth degree, take
> twice as long. Therefore there is no benefit for the crazy rule you
> suggest..." - see
> http://www.mail-archive.com/tech at openbsd.org/msg00425.html

i disagree with this using, ironically, the same base logic, but a different 
conclusion:
http://sourceware.org/ml/libc-alpha/2006-08/msg00064.html

also, i think a self contained system like u-boot which has full control at 
the api level can be better at this than a user interface which really sits on 
top of an abi and has to deal with a lot of crap from user code.

while i'm not asking for you or anyone else to audit header paths here as i 
think that level of enforcement will bog things down, small patches from 
people who choose to fix things should be merged.

> > I don't know whether Linux has a specific policy on this, but I haven't
> > noticed many problems in this regard, and when I did find one in the
> > kernel a few years back I didn't get any argument when I submitted a
> > patch to fix it.

ive semi-frequently post fixes to linux headers so that you can include just 
that header and have it work.  i have yet to hear anyone complain; rather 
every one has been merged (ignoring issues unrelated to the original purpose).

> > Which man pages are you looking at?
> 
> Well, for example:
> 
> open(2):
> 	SYNOPSIS
> 	       #include <sys/types.h>
> 	       #include <sys/stat.h>
> 	       #include <fcntl.h>
> 
> mknod(2):
> 	SYNOPSIS
> 	       #include <sys/types.h>
> 	       #include <sys/stat.h>
> 	       #include <fcntl.h>
> 	       #include <unistd.h>
> 
> stat(2):
> 	SYNOPSIS
> 	       #include <sys/types.h>
> 	       #include <sys/stat.h>
> 	       #include <unistd.h>
> 
> Why do we need these lists of #includes? WHy doe - for example -
> <sys/stat.h> not auto-include anything it might need?
> 
> To me this seems to be an indication that there is no intention to
> make headers self-sufficent, but I am absolutely not sure.

i'm pretty sure your man page example is an unrelated issue.  the include list 
does not imply that any one of those headers cannot be included by itself 
first.  if you read the full text of the man page, there are many 
defines/options which may be utilized.  if you want to use different pieces, 
you might have to include the related header.  so the full header list is 
given to cover any one piece of code in the man page by itself.

going by my point, none of these will result in a build failure:
for h in sys/types.h sys/stat.h unistd.h fcntl.h ; do
	gcc -include $h -x c -c - -o /dev/null < /dev/null
done

going by the man page point of open(2), this code will compile:
#include <fcntl.h>
main() { open("foo", O_RDONLY); }
but if you want to create a file with symbolic perms, you need sys/stat.h:
#include <fcntl.h>
#include <sys/stat.h>
main() { open("foo", O_CREAT, S_IRWXG); }
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091117/330b1a78/attachment.pgp