Kconfig variable "COBALT" is not defined anywhere

Kconfig variable "COBALT" is not defined anywhere

[Robert P. J. Day]

  (no one's listed as the official cobalt maintainer so i thought i'd
just throw this out there.)

  there is no Kconfig file which defines the selectable option
"COBALT", which means that this snippet from drivers/char/nvram.c:

#  if defined(CONFIG_COBALT)
#    include <linux/cobalt-nvram.h>
#    define MACH COBALT
#  else
#    define MACH PC
#  endif

never evaluates to true, therefore making <linux/cobalt-nvram.h>
fairly useless, at least under the circumstances.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: Kconfig variable "COBALT" is not defined anywhere

[Randy Dunlap]

On Sun, 3 Jun 2007 13:17:48 -0400 (EDT) Robert P. J. Day wrote:

> 
>   (no one's listed as the official cobalt maintainer so i thought i'd
> just throw this out there.)
> 
>   there is no Kconfig file which defines the selectable option
> "COBALT", which means that this snippet from drivers/char/nvram.c:
> 
> #  if defined(CONFIG_COBALT)
> #    include <linux/cobalt-nvram.h>
> #    define MACH COBALT
> #  else
> #    define MACH PC
> #  endif
> 
> never evaluates to true, therefore making <linux/cobalt-nvram.h>
> fairly useless, at least under the circumstances.

Maybe it should be MIPS_COBALT ?


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: Kconfig variable "COBALT" is not defined anywhere

[Robert P. J. Day]

On Sun, 3 Jun 2007, Randy Dunlap wrote:

> On Sun, 3 Jun 2007 13:17:48 -0400 (EDT) Robert P. J. Day wrote:
>
> >
> >   (no one's listed as the official cobalt maintainer so i thought i'd
> > just throw this out there.)
> >
> >   there is no Kconfig file which defines the selectable option
> > "COBALT", which means that this snippet from drivers/char/nvram.c:
> >
> > #  if defined(CONFIG_COBALT)
> > #    include <linux/cobalt-nvram.h>
> > #    define MACH COBALT
> > #  else
> > #    define MACH PC
> > #  endif
> >
> > never evaluates to true, therefore making <linux/cobalt-nvram.h>
> > fairly useless, at least under the circumstances.
>
> Maybe it should be MIPS_COBALT ?

that's the first thing that occurred to me, but that header file is
copyright sun microsystems and says nothing about MIPS, so that didn't
really settle the issue.  that's why i'd rather someone else resolve
this one way or the other.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: Kconfig variable "COBALT" is not defined anywhere

[Roland Dreier]

 > > >   there is no Kconfig file which defines the selectable option
 > > > "COBALT", which means that this snippet from drivers/char/nvram.c:
 > > >
 > > > #  if defined(CONFIG_COBALT)
 > > > #    include <linux/cobalt-nvram.h>
 > > > #    define MACH COBALT
 > > > #  else
 > > > #    define MACH PC
 > > > #  endif
 > > > never evaluates to true, therefore making <linux/cobalt-nvram.h>
 > > > fairly useless, at least under the circumstances.

 > > Maybe it should be MIPS_COBALT ?

 > that's the first thing that occurred to me, but that header file is
 > copyright sun microsystems and says nothing about MIPS, so that didn't
 > really settle the issue.  that's why i'd rather someone else resolve
 > this one way or the other.

Actually, looking through the old kernel history, it looks like this
was added by Tim Hockin's (CCed) patch "Add Cobalt Networks support to
nvram driver".  Which added this to drivers/cobalt:

+bool 'Support for Cobalt Networks x86 servers' CONFIG_COBALT

I guess Tim can clear up what's intended...

Re: Kconfig variable "COBALT" is not defined anywhere

[Tim Hockin]

There were other patches which added more COBALT support, but they
were dropped or lost or whatever.

I would not balk at having that code yanked.  I never got around to
doing proper Cobalt support for modern kernels. :(

On 6/3/07, Roland Dreier <rdreier@cisco.com> wrote:
>  > > >   there is no Kconfig file which defines the selectable option
>  > > > "COBALT", which means that this snippet from drivers/char/nvram.c:
>  > > >
>  > > > #  if defined(CONFIG_COBALT)
>  > > > #    include <linux/cobalt-nvram.h>
>  > > > #    define MACH COBALT
>  > > > #  else
>  > > > #    define MACH PC
>  > > > #  endif
>  > > > never evaluates to true, therefore making <linux/cobalt-nvram.h>
>  > > > fairly useless, at least under the circumstances.
>
>  > > Maybe it should be MIPS_COBALT ?
>
>  > that's the first thing that occurred to me, but that header file is
>  > copyright sun microsystems and says nothing about MIPS, so that didn't
>  > really settle the issue.  that's why i'd rather someone else resolve
>  > this one way or the other.
>
> Actually, looking through the old kernel history, it looks like this
> was added by Tim Hockin's (CCed) patch "Add Cobalt Networks support to
> nvram driver".  Which added this to drivers/cobalt:
>
> +bool 'Support for Cobalt Networks x86 servers' CONFIG_COBALT
>
> I guess Tim can clear up what's intended...
>

Re: Kconfig variable "COBALT" is not defined anywhere

[Robert P. J. Day]

On Sun, 3 Jun 2007, Tim Hockin wrote:

> There were other patches which added more COBALT support, but they
> were dropped or lost or whatever.
>
> I would not balk at having that code yanked.  I never got around to
> doing proper Cobalt support for modern kernels. :(
>
> On 6/3/07, Roland Dreier <rdreier@cisco.com> wrote:
> >  > > >   there is no Kconfig file which defines the selectable option
> >  > > > "COBALT", which means that this snippet from drivers/char/nvram.c:
> >  > > >
> >  > > > #  if defined(CONFIG_COBALT)
> >  > > > #    include <linux/cobalt-nvram.h>
> >  > > > #    define MACH COBALT
> >  > > > #  else
> >  > > > #    define MACH PC
> >  > > > #  endif
> >  > > > never evaluates to true, therefore making <linux/cobalt-nvram.h>
> >  > > > fairly useless, at least under the circumstances.
> >
> >  > > Maybe it should be MIPS_COBALT ?
> >
> >  > that's the first thing that occurred to me, but that header file is
> >  > copyright sun microsystems and says nothing about MIPS, so that didn't
> >  > really settle the issue.  that's why i'd rather someone else resolve
> >  > this one way or the other.
> >
> > Actually, looking through the old kernel history, it looks like this
> > was added by Tim Hockin's (CCed) patch "Add Cobalt Networks support to
> > nvram driver".  Which added this to drivers/cobalt:
> >
> > +bool 'Support for Cobalt Networks x86 servers' CONFIG_COBALT
> >
> > I guess Tim can clear up what's intended...

ok, that sounds like it might be a bigger issue than just a dead
CONFIG variable.  if that's all it is, i can submit a patch.  if it's
more than that, i'll leave it to someone higher up the food chain to
figure out what cobalt-related stuff should be yanked.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: Kconfig variable "COBALT" is not defined anywhere

[Tim Hockin]

I think the nvram is the only place left that uses CONFIG_COBALT

On 6/3/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
> On Sun, 3 Jun 2007, Tim Hockin wrote:
>
> > There were other patches which added more COBALT support, but they
> > were dropped or lost or whatever.
> >
> > I would not balk at having that code yanked.  I never got around to
> > doing proper Cobalt support for modern kernels. :(
> >
> > On 6/3/07, Roland Dreier <rdreier@cisco.com> wrote:
> > >  > > >   there is no Kconfig file which defines the selectable option
> > >  > > > "COBALT", which means that this snippet from drivers/char/nvram.c:
> > >  > > >
> > >  > > > #  if defined(CONFIG_COBALT)
> > >  > > > #    include <linux/cobalt-nvram.h>
> > >  > > > #    define MACH COBALT
> > >  > > > #  else
> > >  > > > #    define MACH PC
> > >  > > > #  endif
> > >  > > > never evaluates to true, therefore making <linux/cobalt-nvram.h>
> > >  > > > fairly useless, at least under the circumstances.
> > >
> > >  > > Maybe it should be MIPS_COBALT ?
> > >
> > >  > that's the first thing that occurred to me, but that header file is
> > >  > copyright sun microsystems and says nothing about MIPS, so that didn't
> > >  > really settle the issue.  that's why i'd rather someone else resolve
> > >  > this one way or the other.
> > >
> > > Actually, looking through the old kernel history, it looks like this
> > > was added by Tim Hockin's (CCed) patch "Add Cobalt Networks support to
> > > nvram driver".  Which added this to drivers/cobalt:
> > >
> > > +bool 'Support for Cobalt Networks x86 servers' CONFIG_COBALT
> > >
> > > I guess Tim can clear up what's intended...
>
> ok, that sounds like it might be a bigger issue than just a dead
> CONFIG variable.  if that's all it is, i can submit a patch.  if it's
> more than that, i'll leave it to someone higher up the food chain to
> figure out what cobalt-related stuff should be yanked.
>
> rday
> --
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
>
> http://fsdev.net/wiki/index.php?title=Main_Page
> ========================================================================
>

Re: Kconfig variable "COBALT" is not defined anywhere

[Robert P. J. Day]

On Sun, 3 Jun 2007, Tim Hockin wrote:

> I think the nvram is the only place left that uses CONFIG_COBALT

sure, but once you remove this snippet near the top of
drivers/char/nvram.c:

...
#  if defined(CONFIG_COBALT)
#    include <linux/cobalt-nvram.h>
#    define MACH COBALT
#  else
#    define MACH PC
#  endif
...

then everything else COBALT-related in that file should be tossed as
well, which would include stuff conditional on:

  #if MACH == COBALT

and so on.  just making sure that what you're saying is that *all*
COBALT-related content in that file can be thrown out.  i'll submit a
patch shortly and you can pass judgment.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: Kconfig variable "COBALT" is not defined anywhere

[Tim Hockin]

That sounds correct.

On 6/3/07, Robert P. J. Day <rpjday@mindspring.com> wrote:
> On Sun, 3 Jun 2007, Tim Hockin wrote:
>
> > I think the nvram is the only place left that uses CONFIG_COBALT
>
> sure, but once you remove this snippet near the top of
> drivers/char/nvram.c:
>
> ...
> #  if defined(CONFIG_COBALT)
> #    include <linux/cobalt-nvram.h>
> #    define MACH COBALT
> #  else
> #    define MACH PC
> #  endif
> ...
>
> then everything else COBALT-related in that file should be tossed as
> well, which would include stuff conditional on:
>
>   #if MACH == COBALT
>
> and so on.  just making sure that what you're saying is that *all*
> COBALT-related content in that file can be thrown out.  i'll submit a
> patch shortly and you can pass judgment.
>
> rday
> --
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
>
> http://fsdev.net/wiki/index.php?title=Main_Page
> ========================================================================
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>