Build issues with 2.6.0-test3

[Tom Rini]

On Tue, Aug 12, 2003 at 09:40:20AM -0600, Gary Thomas wrote:
> On Tue, 2003-08-12 at 09:25, Tom Rini wrote:
> > On Tue, Aug 12, 2003 at 07:56:55AM -0600, Gary Thomas wrote:
> >
> > > * How best to handle optional support?  One of the patches fixes
> > >   a problem of a missing system call (sys_pciconfig_iobase).  In
> > >   this case, the platform I was building for has no PCI, so it's
> > >   not configured in.  The way I fixed it was to conditionalize
> > >   the syscall table.  An alternate way would be to have a module
> > >   which is compiled if CONFIG_PCI is *not* set (or alternately
> > >   have arch/ppc/kernel/pci.c always be compiled and export the
> > >   appropriate functions that just return -ENOSYS).  Comments?
> >
> > 'cond_syscall' is _supposed_ to work here.  But in this one case, it
> > does not.  I've tried tracking this down a little bit, and the 'weak'
> > asm bits make it as far as the pci.s file, but not the pci.o.  And to
> > make it all the more odd, if I threw the cond_syscall into a file in
> > kernel/ (just to try it out), it works.
>
> Which "pci.c"?  The one in arch/ppc/kernel isn't even being compiled
> in this case.  Are you saying that it should (and behave differently
> when CONFIG_PCI isn't set)?

Too early in the AM.  I meant arch/ppc/kernel/syscall.c (which is being
compiled) not arch/ppc/kernel/pci.c

> > > * Has anyone succeeded in building & running 2.6 (or late 2.5)
> > >   on any embedded boards (8xx/8260/405)?
> >
> > No / Yes / Yes.
>        ^^^ How?  These compile errors would prevent this.

'Late' 2.5.  Before DaveM broke 8260_io/enet.c, and before the serial
change.

> > > Index: arch/ppc/8260_io/uart.c
> > > ===================================================================
> > > RCS file: /home/gthomas/my_cvs/develop/linuxppc-2.5/arch/ppc/8260_io/uart.c,v
> > > retrieving revision 1.1
> > > diff -u -5 -p -r1.1 uart.c
> > > --- arch/ppc/8260_io/uart.c	12 Aug 2003 12:18:15 -0000	1.1
> > > +++ arch/ppc/8260_io/uart.c	12 Aug 2003 13:30:40 -0000
> > > @@ -2389,11 +2389,11 @@ void kgdb_map_scc(void)
> > >  	up->smc_mrblr = RX_BUF_SIZE;		/* receive buffer length */
> > >  	up->smc_maxidl = RX_BUF_SIZE;
> > >  }
> > >  #endif
> > >
> > > -static kdev_t serial_console_device(struct console *c)
> > > +static struct tty_driver *serial_console_device(struct console *c, int *index)
> > >  {
> > >  	*index = c->index;
> > >  	return serial_driver;
> > >  }
> >
> > After looking at the similar code in drivers/serial, I don't think this
> > is sufficient.  But I didn't dig too far into seee what c->data was
> > there.
>
> It seems to be [virtually] the same as in
>   arch/ppc/8xx_io/uart.c
>   drivers/char/amiserial.c
>   drivers/char/serial_tx3912.c
>   drivers/char/sh-sci.c
>   drivers/macintosh/macserial.c

Those are all of the obsolete, and probably broken drivers.
drivers/serial is where all of the 'new' and working serial drivers are.
If you've got some time, the 8260 serial driver really should be
re-written as a driver inside of drivers/serial. :)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/