Phil Schwan wrote:
> On May 18, Russell Cattelan wrote:
> > Phil Schwan wrote:
> >
> > > While hacking files from scratch, I noticed the huge number of
> > > dependencies that #includes don't resolve for themselves. Is there
> > > some reason for this, or did it just happen over time? Does anyone
> > > mind if I apply this patch? It doesn't fix them all, but it gets the
> > > ones that I've run into so far.
> >
> > What does this fix?
>
> It fixes insane scenarios like this, which was previously in dump.h:
>
> # include <sys/uuid.h> /* resolve xfs_dinode and xfs_sb deps */
> # include "xfs_inum.h" /* resolve xfs_dinode and xfs_sb deps */
> # include "xfs_types.h" /* resolve xfs_attr_sf, xfs_bmap_btree, and
> xfs_dir_sf deps */
> # include "xfs_buf.h" /* resolve xfs_bmap_btree dep */
> # include "xfs_bmap_btree.h" /* resolve xfs_dinode dep */
> # include "xfs_dir_sf.h" /* resolve xfs_attr_sf dep */
> # include "xfs_attr_sf.h" /* resolve xfs_dinode dep */
> # include "xfs_dir2_sf.h" /* resolve xfs_dinode dep */
> # include "xfs_dinode.h" /* resolve xfs_sb dep */
> # include "xfs_sb.h" /* resolve xfs_mount dep */
> # include "ksys/behavior.h" /* resolve xfs_mount dep */
> # include "xfs_log.h" /* resolve xfs_trans dep */
> # include "xfs_trans.h" /* resolve xfs_mount dep */
> # include "xfs_dir.h" /* resolve xfs_mount dep */
> #include "xfs_mount.h" /* for xfs_mount_t */
>
> > The rest shouldn't really matter, as long as it doesn't break either
> > one of the build paths.
>
> By this do you mean the module and non-module build path, or the
> native and non-native build path, or the delalloc and non-delalloc
> build path...?
pagebuf_meta_data on and off.
if thinks look like they should go in xfs_os_defs.h do that
>
>
> -Phil
|