Re: ore: FIX breakage when MISC_FILESYSTEMS is not set

[Trond Myklebust]

On Tue, 2011-11-29 at 17:36 -0500, Trond Myklebust wrote: 
> On Tue, 2011-11-29 at 14:22 -0800, Boaz Harrosh wrote: 
> > On 11/29/2011 09:33 AM, Trond Myklebust wrote:
> > > On Tue, 2011-11-29 at 14:21 +0200, Benny Halevy wrote: 
> > >> On 2011-11-29 02:13, Boaz Harrosh wrote:
> > 
> > >>>
> > >>> The solution is to force all users of ORE (exofs, nfs) to manually
> > >>> select everything auto-magically selected before.
> > >>
> > >> How about using "depend ORE" rather than "select ORE"?
> > > 
> > > Right. Make PNFS_OBJLAYOUT and EXOFS_FS depend on ASYNC_XOR (or select
> > > it) and then make ORE depend on EXOFS_FS || PNFS_OBJLAYOUT.
> > > 
> > > There should be no need to add the 'select ORE'...
> > > 
> > 
> > No! guys!
> > 
> > One it will not solve my problem because any
> > solution that needs to inspect exofs/Kconfig file will
> > not work if MISC_FILESYSTEMS is not selected and your
> > solutions involve that.
> 
> Then move ORE _out_ of MISC_FILESYSTEMS. There is no reason why it needs
> to be there as long as the things it depends on are there.

Should read:
There is no reason why ORE needs to depend on MISC_FILESYSTEMS. Only
EXOFS_FS needs that...


> > And two:
> > All the user needs to do is Select NFS4.1 everything
> > else should be done automatically. He should not need
> > to go to misc-filesystems and select ORE so he can have
> > pnfs-objects. That's a nightmare.
> 
> The solution I proposed didn't involve having the user select anything
> other than NFSv4.1 and possibly ASYNC_XOR.
> 
> > And anyway the current Kernel rule is that a user of a library
> > needs to select it and all it's dependencies, because select
> > is not recursive. Now I devised a little skim that can avoid
> 
> ...and this is _my_ nightmare. I dont' _want_ these selects anywhere in
> the NFS subsystem.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/