found __[us]{8,16,32,64} type without #include <linux/types.h>

All noticed while compiling 3.1-r5:

linux/usr/include/drm/drm_mode.h:85: found __[us]{8,16,32,64} type without #include <linux/types.h> linux/usr/include/drm/i915_drm.h:120: found __[us]{8,16,32,64} type without #include <linux/types.h> linux/usr/include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include <linux/types.h> linux/usr/include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include <linux/types.h> linux/usr/include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include <linux/types.h>

linux/usr/include/scsi/scsi_netlink.h:108: found __[us]{8,16,32,64} type without #include <linux/types.h>

linux/usr/include/linux/mmc/ioctl.h:10: found __[us]{8,16,32,64} type without #include <linux/types.h>

-JimC

James Cloos <[email protected]>         OpenPGP: 1024D/ED7DAEA6

This has been around for a long time, I think. I agree that we should do something about it, but I think we're still looking for a solution that makes everyone happy.

The script only checks for direct inclusions of types.h, while the drm headers get it from drm.h. One solution would be to make the script smart enough to evaluate all indirect header inclusions as well. A more hacky workaround would be to just treat "drm.h" the same as <linux/types.h>.

Arnd

AB> The script only checks for direct inclusions of types.h, while the AB> drm headers get it from drm.h.

I see. It had been quite some time since I last did a make 1>/dev/null, long enough that I hadn't noticed that message before.

It is good to know that it is a false positive.

-JimC

James Cloos <[email protected]>         OpenPGP: 1024D/ED7DAEA6