<ugh> Forgot to cc linux-kernel
Hi.
I get the following error when trying to compile 2.4.0-test10pre6
without procfs support:
drivers/ide/osb4.c: In function `pci_init_osb4':
drivers/ide/osb4.c:264: `osb4_revision' undeclared (first use in this function)
drivers/ide/osb4.c:264: (Each undeclared identifier is reported only once
drivers/ide/osb4.c:264: for each function it appears in.)
make: *** [drivers/ide/osb4.o] Error 1
The variable, osb4_revision, is inside a #ifdef CONFIG_PROC_FS block but
I was not able to discern if the line where it is referred should be
#ifdef'ed also. The following patch moves the variable declaration out-
side the #ifdef block, as a blind guess...
--- linux-240-t10p6-clean/drivers/ide/osb4.c Sun Oct 29 09:51:10 2000
+++ linux/drivers/ide/osb4.c Sun Oct 29 13:55:23 2000
@@ -56,11 +56,12 @@
#define DISPLAY_OSB4_TIMINGS
+static byte osb4_revision = 0;
+
#if defined(DISPLAY_OSB4_TIMINGS) && defined(CONFIG_PROC_FS)
#include <linux/stat.h>
#include <linux/proc_fs.h>
-static byte osb4_revision = 0;
static struct pci_dev *bmide_dev;
static int osb4_get_info(char *, char **, off_t, int, int);
--
Rasmus([email protected])
There are two major products that come out of Berkeley: LSD and UNIX. We
don't believe this to be a coincidence. -- Jeremy S. Anderson
----- End forwarded message -----
--
Rasmus([email protected])
First snow, then silence.
This thousand dollar screen dies
so beautifully. --- Error messages in haiku
In article <[email protected]> you wrote:
> The variable, osb4_revision, is inside a #ifdef CONFIG_PROC_FS block but
> I was not able to discern if the line where it is referred should be
> #ifdef'ed also. The following patch moves the variable declaration out-
> side the #ifdef block, as a blind guess...
This patch, and a lot of others of a similar nature, are in my test10pre6
compile patch at
http://www.fenrus.demon.nl/t10p6.diff
Greetings,
Arjan van de Ven
> This patch, and a lot of others of a similar nature, are in my test10pre6
> compile patch at
[snip]
(Added a bit to the cc list)
Hi Arjan.
Thanks for the pointer. However my test build still barfs in the final
link phase because we (in t10p6) morphed drivers/pcmcia/cs.c::pcmcia_
request_irq into (the static) cs_request_irq. The rename part
broke the two other places in cs.c where pcmcia_request_irq was
referenced and the static part made its usage in drivers/net/pcmcia/
ray_cs.c a bit awkward.
Since I won't presume to question the decision to rename the function
the following patch propagates the rename to the rest of the kernel.
Furthermore, I presumed to remove the static part so that the ray_cs
driver was free to use it. I have added David Hinds and Corey Thomas
(the raylink driver maintainer) to the cc on this mail so they can
decide what the proper solution is.
Meanwhile, this patch makes my test kernel build:
--- linux-240-t10p6-clean/drivers/pcmcia/cs.c Sun Oct 29 09:51:13 2000
+++ linux/drivers/pcmcia/cs.c Sun Oct 29 22:52:22 2000
@@ -1836,7 +1836,7 @@
======================================================================*/
-static int cs_request_irq(client_handle_t handle, irq_req_t *req)
+int cs_request_irq(client_handle_t handle, irq_req_t *req)
{
socket_info_t *s;
config_t *c;
@@ -2284,7 +2284,7 @@
case RequestIO:
return pcmcia_request_io(a1, a2); break;
case RequestIRQ:
- return pcmcia_request_irq(a1, a2); break;
+ return cs_request_irq(a1, a2); break;
case RequestWindow:
{
window_handle_t w;
@@ -2376,7 +2376,7 @@
EXPORT_SYMBOL(pcmcia_report_error);
EXPORT_SYMBOL(pcmcia_request_configuration);
EXPORT_SYMBOL(pcmcia_request_io);
-EXPORT_SYMBOL(pcmcia_request_irq);
+EXPORT_SYMBOL(cs_request_irq);
EXPORT_SYMBOL(pcmcia_request_window);
EXPORT_SYMBOL(pcmcia_reset_card);
EXPORT_SYMBOL(pcmcia_resume_card);
--- linux-240-t10p6-clean/drivers/net/pcmcia/ray_cs.c Sun Oct 29 09:49:52 2000
+++ linux/drivers/net/pcmcia/ray_cs.c Sun Oct 29 22:52:53 2000
@@ -560,7 +560,7 @@
/* Now allocate an interrupt line. Note that this does not
actually assign a handler to the interrupt.
*/
- CS_CHECK(pcmcia_request_irq, link->handle, &link->irq);
+ CS_CHECK(cs_request_irq, link->handle, &link->irq);
dev->irq = link->irq.AssignedIRQ;
/* This actually configures the PCMCIA socket -- setting up
--
Regards,
Rasmus([email protected])
"God prevent we should ever be twenty years without a revolution."
-- Thomas Jefferson
Rasmus Andersen wrote:
> Thanks for the pointer. However my test build still barfs in the final
> link phase because we (in t10p6) morphed drivers/pcmcia/cs.c::pcmcia_
> request_irq into (the static) cs_request_irq. The rename part
> broke the two other places in cs.c where pcmcia_request_irq was
> referenced and the static part made its usage in drivers/net/pcmcia/
> ray_cs.c a bit awkward.
>
> Since I won't presume to question the decision to rename the function
> the following patch propagates the rename to the rest of the kernel.
> Furthermore, I presumed to remove the static part so that the ray_cs
> driver was free to use it. I have added David Hinds and Corey Thomas
> (the raylink driver maintainer) to the cc on this mail so they can
> decide what the proper solution is.
This is what went to Linus, and David Hinds ack'd it.
http://gtf.org/garzik/kernel/files/patches/2.4/2.4.0-test10/pcmcia-2.4.0.10.6.patch.gz
Jeff
--
Jeff Garzik | "Mind if I drive?" -Sam
Building 1024 | "Not if you don't mind me clawing at the
MandrakeSoft | dash and shrieking like a cheerleader."
| -Max
On Sun, Oct 29, 2000 at 11:12:57PM +0100, Rasmus Andersen wrote:
>
> Thanks for the pointer. However my test build still barfs in the final
> link phase because we (in t10p6) morphed drivers/pcmcia/cs.c::pcmcia_
> request_irq into (the static) cs_request_irq. The rename part
> broke the two other places in cs.c where pcmcia_request_irq was
> referenced and the static part made its usage in drivers/net/pcmcia/
> ray_cs.c a bit awkward.
It should be un-morphed back to the way it was. It was an error that
slipped into a patch I was preparing, because I was hand-editing the
"diff" output to accommodate some changes between the kernel tree and
the separate PCMCIA package.
-- Dave
ray_cs was imported to the kernel as one of the first test drivers by
Linus. At the time, he wanted to get rid of the CardServices(function...)
interface and replace it with pcmcia_function calls. It seems that
the correct fix would be to change pcmcia_request_irq to RequestIRQ
like all the other drivers use. Or, change all the other drivers. In
any case I know of no reason for ray_cs to be unique.
David Hinds <[email protected]> writes:
> On Sun, Oct 29, 2000 at 11:12:57PM +0100, Rasmus Andersen wrote:
> >
> > Thanks for the pointer. However my test build still barfs in the final
> > link phase because we (in t10p6) morphed drivers/pcmcia/cs.c::pcmcia_
> > request_irq into (the static) cs_request_irq. The rename part
> > broke the two other places in cs.c where pcmcia_request_irq was
> > referenced and the static part made its usage in drivers/net/pcmcia/
> > ray_cs.c a bit awkward.
>
> It should be un-morphed back to the way it was. It was an error that
> slipped into a patch I was preparing, because I was hand-editing the
> "diff" output to accommodate some changes between the kernel tree and
> the separate PCMCIA package.
>
> -- Dave