[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bd0f97a0804231059w76592878s3f6bf4a488b3ddea@mail.gmail.com>
Date: Wed, 23 Apr 2008 13:59:05 -0400
From: "Mike Frysinger" <vapier.adi@...il.com>
To: "Will Newton" <will.newton@...il.com>
Cc: "Kyle McMartin" <kyle@...artin.ca>,
"Randy Dunlap" <randy.dunlap@...cle.com>,
"Linux Kernel list" <linux-kernel@...r.kernel.org>,
linux-arch@...r.kernel.org
Subject: Re: [RFC] Introduce __ARCH_WANT_SYS_SYSFS
On Wed, Apr 23, 2008 at 12:05 PM, Mike Frysinger <vapier.adi@...il.com> wrote:
> On Wed, Apr 23, 2008 at 11:50 AM, Will Newton <will.newton@...il.com> wrote:
> > On Wed, Apr 23, 2008 at 4:40 PM, Kyle McMartin <kyle@...artin.ca> wrote:
> > > On Wed, Apr 23, 2008 at 03:36:23PM +0100, Will Newton wrote:
> > > > +config ARCH_HAS_SYS_SYSFS
> > > > + bool
> > > > + default y
> > > > +
> > > > source "init/Kconfig"
> > > >
> > >
> > > Sorry, I meant something more like
> > >
> > >
> > > config ARCH_HAS_SYS_SYSFS
> > > def_bool !BLACKFIN
> > > help
> > > Obsolete sys_sysfs syscall
> > >
> > > in init/Kconfig
> > >
> > > But, it's your patch, you can do it however you like. :)
> >
> > That's definitely shorter - but it feels a bit more like #ifdef
> > CONFIG_BLACKFIN which is explicitly what I don't want to do, because
> > I'm not actually interested in blackfin. ;-)
>
> i'd have to agree that updating asm/unistd.h fits better with existing
> paradigm. if we want to talk about converting *all cases* to Kconfig,
> we can do it in a separate thread. splitting the design between two
> different files is simply confusing to everyone involved as they spend
> their time going "well which way am *i* supposed to do it".
thinking about this some more ... we actually have three choices here,
not just two. checksyscalls.sh introduced a new form in asm/unistd.h:
#define __IGNORE_sysfs
perhaps we should be unifying the __ARCH_WANT_XXX and the __IGNORE_XXX
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists