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

Mike Frysinger
2009-11-18T00:18:38Z

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