(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
========================================================================
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 ***
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
========================================================================
> > > 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...
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 <[email protected]> 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...
>
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 <[email protected]> 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
========================================================================
I think the nvram is the only place left that uses CONFIG_COBALT
On 6/3/07, Robert P. J. Day <[email protected]> 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 <[email protected]> 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
> ========================================================================
>
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
========================================================================
That sounds correct.
On 6/3/07, Robert P. J. Day <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>