Re: parport_pc tries to load parport_serial automatically
>- change parport_pc so that it doesn't request parport_serial at
> init. In this case, how will parport_serial get loaded at all?
> Perhaps with some recommended /etc/modules.conf lines (perhaps
> parport_lowlevel{1,2,3,...})?
This would be a bit bad, because it would require people to guess whether they
might have a card that parport_serial can drive and/or try loading the module
to see what happens.
I guess one option would be for parport_pc to somehow "know" what cards are
really multi-I/O ones, and only load parport_serial when it will be able to
find something to do. Doesn't seem all that appealing though.
>- parport_serial could be made to initialise successfully even if it
> doesn't see any devices that it can drive.
If you do that then the code will effectively be there all the time, even when
it's not needed. You might as well just compile it in to parport_pc. To be
honest, there isn't all that much of it so maybe this wouldn't be such a bad
idea.
p.
PGP signature
Re: parport_pc tries to load parport_serial automatically
- change parport_pc so that it doesn't request parport_serial at
init. In this case, how will parport_serial get loaded at all?
Perhaps with some recommended /etc/modules.conf lines (perhaps
parport_lowlevel{1,2,3,...})?
This would be a bit bad, because it would require people to guess whether they
might have a card that parport_serial can drive and/or try loading the module
to see what happens.
I guess one option would be for parport_pc to somehow know what cards are
really multi-I/O ones, and only load parport_serial when it will be able to
find something to do. Doesn't seem all that appealing though.
- parport_serial could be made to initialise successfully even if it
doesn't see any devices that it can drive.
If you do that then the code will effectively be there all the time, even when
it's not needed. You might as well just compile it in to parport_pc. To be
honest, there isn't all that much of it so maybe this wouldn't be such a bad
idea.
p.
PGP signature
Re: Linux 2.2.20-pre4
>> It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
>> insert calls to 'memcpy'
>
>IMHO omitting -fno-builtin when compiling the kernel was always a risky
>proposition... Since we provide our own copies of many of the builtins
>[which are used in the kernel] anyway... why not always -fno-builtin,
>and then call __builtin_foo when we really want the compiler's version..
>
>gcc 3.0 without -fno-builtin is perfectly allowed to assume it can
>insert calls to memcpy..
I don't think -fno-builtin has any bearing on whether gcc will emit calls to
memcpy; instead it prevents gcc from open-coding them when it thinks it
understands what's going on.
Try this with gcc -O2 -S, and again with -fno-builtin:
struct s { int a[200]; };
f(struct s *a, struct s *b)
{
*b = *a;
}
g(int *a, int *b)
{
memcpy(b, a, 4);
}
p.
PGP signature
Re: Linux 2.2.20-pre4
It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can
insert calls to 'memcpy'
IMHO omitting -fno-builtin when compiling the kernel was always a risky
proposition... Since we provide our own copies of many of the builtins
[which are used in the kernel] anyway... why not always -fno-builtin,
and then call __builtin_foo when we really want the compiler's version..
gcc 3.0 without -fno-builtin is perfectly allowed to assume it can
insert calls to memcpy..
I don't think -fno-builtin has any bearing on whether gcc will emit calls to
memcpy; instead it prevents gcc from open-coding them when it thinks it
understands what's going on.
Try this with gcc -O2 -S, and again with -fno-builtin:
struct s { int a[200]; };
f(struct s *a, struct s *b)
{
*b = *a;
}
g(int *a, int *b)
{
memcpy(b, a, 4);
}
p.
PGP signature
empeg-car serial-over-USB driver
Has anybody used this successfully in a recent kernel? With 2.4.5 it seems to detect the device successfully: empeg.c: v1.0.0 Greg Kroah-Hartman <[EMAIL PROTECTED]>, Gary Brubaker <[EMAIL PROTECTED]> empeg.c: USB Empeg Mark I/II Driver usbserial.c: Empeg converter detected usbserial.c: Empeg converter now attached to ttyUSB0 (or usb/tts/0 for devfs) but the machine locks up when I try to talk to it. This is on i386 using the usb-uhci driver. p. PGP signature
empeg-car serial-over-USB driver
Has anybody used this successfully in a recent kernel? With 2.4.5 it seems to detect the device successfully: empeg.c: v1.0.0 Greg Kroah-Hartman [EMAIL PROTECTED], Gary Brubaker [EMAIL PROTECTED] empeg.c: USB Empeg Mark I/II Driver usbserial.c: Empeg converter detected usbserial.c: Empeg converter now attached to ttyUSB0 (or usb/tts/0 for devfs) but the machine locks up when I try to talk to it. This is on i386 using the usb-uhci driver. p. PGP signature
Re: Potenitial security hole in the kernel
>Suppose the signal handler modifies this context frame for example by >storing into the PC slot address of the panic routine >then when handler will exit panic will be called with obvious results. You can't execute panic() - or any other kernel function - in user mode. The application can write what it likes into its sigcontext, and the worst that will hapenn is that it will crash itself. p. PGP signature
Re: Potenitial security hole in the kernel
Suppose the signal handler modifies this context frame for example by storing into the PC slot address of the panic routine then when handler will exit panic will be called with obvious results. You can't execute panic() - or any other kernel function - in user mode. The application can write what it likes into its sigcontext, and the worst that will hapenn is that it will crash itself. p. PGP signature
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
>--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001 >+++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001 >@@ -12,6 +12,7 @@ > * 13-04-1997 RMK Made functions atomic! > * 07-12-1997 RMK Upgraded for v2.1. > * 26-08-1998 PJB Added #ifdef __KERNEL__ >+ * 27-05-2001 APB Removed #ifdef __KERNEL__ > */ > #ifndef __ASM_ARM_ATOMIC_H > #define __ASM_ARM_ATOMIC_H >@@ -30,7 +31,6 @@ This is no good. The ARM kernel just doesn't provide any atomic primitives that will work in user space. If you want atomicity you have to use libpthread. p. PGP signature
Re: Inconsistent #ifdef __KERNEL__ on different architectures
--- include/asm-arm/atomic.h.old Sun May 27 22:30:58 2001 +++ include/asm-arm/atomic.h Sun May 27 22:58:20 2001 @@ -12,6 +12,7 @@ * 13-04-1997 RMK Made functions atomic! * 07-12-1997 RMK Upgraded for v2.1. * 26-08-1998 PJB Added #ifdef __KERNEL__ + * 27-05-2001 APB Removed #ifdef __KERNEL__ */ #ifndef __ASM_ARM_ATOMIC_H #define __ASM_ARM_ATOMIC_H @@ -30,7 +31,6 @@ This is no good. The ARM kernel just doesn't provide any atomic primitives that will work in user space. If you want atomicity you have to use libpthread. p. PGP signature
Re: Using Parallel Port to Receive Signals
>I am trying to use the data port of parallel port to receive data, so I= > set the bit 5 of the control port to enable the bi-directional port, b= >ut it doesn't work. My parallel supports SPP/EPP/ECP mode, does it sup= >port bi-directional mode? if yes, how can I config it? You might have to play with your BIOS settings. What mode does it think the port is in? p. - 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/
Re: Using Parallel Port to Receive Signals
I am trying to use the data port of parallel port to receive data, so I= set the bit 5 of the control port to enable the bi-directional port, b= ut it doesn't work. My parallel supports SPP/EPP/ECP mode, does it sup= port bi-directional mode? if yes, how can I config it? You might have to play with your BIOS settings. What mode does it think the port is in? p. - 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/
Re: parport problems with devfs
>I attached the problem occured with parport and devfs. >I don't exactly know where the problem in the parport source >is. If someone has a patch for it, I will test it. I don't think this is a bug. You need to load the `lp' module. p. - 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/
Re: parport problems with devfs
I attached the problem occured with parport and devfs. I don't exactly know where the problem in the parport source is. If someone has a patch for it, I will test it. I don't think this is a bug. You need to load the `lp' module. p. - 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/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
>And of course since much of the code in the kernel is built on the >copy a good example neglecting the locking without a big comment, >invites trouble elsewhere like in elf_load_library. Where we could >have multiple threads running. Out of interest: does anything, anywhere, actually use elf_load_library any more? p. - 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/
Re: [PATCH] Longstanding elf fix (2.4.3 fix)
And of course since much of the code in the kernel is built on the copy a good example neglecting the locking without a big comment, invites trouble elsewhere like in elf_load_library. Where we could have multiple threads running. Out of interest: does anything, anywhere, actually use elf_load_library any more? p. - 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/
Re: Linux 2.4.3-ac12
>There are no gcc 2.97 snapshots that compile the kernel correctly because >they have the broken bitfield packing ABI change. Oh right. I didn't know about that particular nicety. >My belief however is that several million people have gcc 2.96-69+, about 50 >are likely to have random cvs snapshots and none of them are going to build >kernels with them anyway, as they wont work __builtin_expect or otherwise. Fair enough. p. - 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/
Re: Linux 2.4.3-ac12
There are no gcc 2.97 snapshots that compile the kernel correctly because they have the broken bitfield packing ABI change. Oh right. I didn't know about that particular nicety. My belief however is that several million people have gcc 2.96-69+, about 50 are likely to have random cvs snapshots and none of them are going to build kernels with them anyway, as they wont work __builtin_expect or otherwise. Fair enough. p. - 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/
Re: 2.4.4-pre6 does not compile
>Its because you're using a version of gcc which doesn't have >__builtin_expect (eg, egcs 1.1.2, some versions of gcc 2.95). No 2.95.x has __builtin_expect. There might be some 2.95-derived GNUpro that supports it but I doubt anyone is using those to build kernels. p. - 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/
Re: 2.4.4-pre6 does not compile
Its because you're using a version of gcc which doesn't have __builtin_expect (eg, egcs 1.1.2, some versions of gcc 2.95). No 2.95.x has __builtin_expect. There might be some 2.95-derived GNUpro that supports it but I doubt anyone is using those to build kernels. p. - 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/
Re: Supplying missing entries for Configure.help, part 4
>+Support for Cobalt Micro Server >+CONFIG_COBALT_MICRO_SERVER >+ Support for ARM-based Cobalt boxes (they have been bought by Sun and >+ are now the "Server Appliance Business Unit") including the 2700 series Aren't those machines MIPS based? p. - 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/
Re: Supplying missing entries for Configure.help, part 4
+Support for Cobalt Micro Server +CONFIG_COBALT_MICRO_SERVER + Support for ARM-based Cobalt boxes (they have been bought by Sun and + are now the "Server Appliance Business Unit") including the 2700 series Aren't those machines MIPS based? p. - 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/
Re: why can't include /sys/types and /linux/fs.h in the same file
>#include
>#include
>int main ()
>{
>; // contains no C programs,
>}
>and give the command " cc -D__KERNEL__ -I/usr/src/linux/include to compiler
>the program .
You can't mix environments. Either you're building part of the kernel, in which
case you need to use -D__KERNEL__ and headers, or you're building an
application, in which case you need to use the headers from libc.
p.
-
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/
Re: why can't include /sys/types and /linux/fs.h in the same file
#include kernel/fs.h
#include sys/types.h
int main ()
{
; // contains no C programs,
}
and give the command " cc -D__KERNEL__ -I/usr/src/linux/include to compiler
the program .
You can't mix environments. Either you're building part of the kernel, in which
case you need to use -D__KERNEL__ and linux/* headers, or you're building an
application, in which case you need to use the headers from libc.
p.
-
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/
2.2.19: cross-compile patch for drivers/net/Makefile
Cross-compiles need to use the target linker here. p. --- linux/drivers/net/Makefile~ Sun Apr 8 17:48:31 2001 +++ linux/drivers/net/Makefile Sun Apr 8 19:31:29 2001 @@ -1445,7 +1445,7 @@ rm -f core *.o *.a *.s wanpipe.o: $(WANPIPE_OBJS) - ld -r -o $@ $(WANPIPE_OBJS) + $(LD) -r -o $@ $(WANPIPE_OBJS) rcpci.o: rcpci45.o rclanmtl.o $(LD) -r -o rcpci.o rcpci45.o rclanmtl.o - 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/
2.2.19: cross-compile patch for drivers/net/Makefile
Cross-compiles need to use the target linker here. p. --- linux/drivers/net/Makefile~ Sun Apr 8 17:48:31 2001 +++ linux/drivers/net/Makefile Sun Apr 8 19:31:29 2001 @@ -1445,7 +1445,7 @@ rm -f core *.o *.a *.s wanpipe.o: $(WANPIPE_OBJS) - ld -r -o $@ $(WANPIPE_OBJS) + $(LD) -r -o $@ $(WANPIPE_OBJS) rcpci.o: rcpci45.o rclanmtl.o $(LD) -r -o rcpci.o rcpci45.o rclanmtl.o - 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/
Re: syslog insmod please!
>I'm not wonderfully impressed with the way that you can't load the FPU >emulation module on ARM at the moment without having some form of FPU >emulation in your kernel already, either :) Floating point on ARM is indeed something of a crock, but that particular case used to work -- can you tell where it's going wrong? See entry-armv.S, about line 680, for the very bad hack that was supposed to facilitate this kind of thing. p. - 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/
Re: syslog insmod please!
I'm not wonderfully impressed with the way that you can't load the FPU emulation module on ARM at the moment without having some form of FPU emulation in your kernel already, either :) Floating point on ARM is indeed something of a crock, but that particular case used to work -- can you tell where it's going wrong? See entry-armv.S, about line 680, for the very bad hack that was supposed to facilitate this kind of thing. p. - 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/
Re: unistd.h and 'extern's and 'syscall' "standard(?)"
>of action to take. Seeing as you work for suse, would you know >where this 'syscall(3)' interface should be documented? Is it >supposed to be present in all distro's? It's documented in the glibc manual. Yes, it should be present in all glibc based distributions. p. - 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/
Re: unistd.h and 'extern's and 'syscall' standard(?)
of action to take. Seeing as you work for suse, would you know where this 'syscall(3)' interface should be documented? Is it supposed to be present in all distro's? It's documented in the glibc manual. Yes, it should be present in all glibc based distributions. p. - 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/
Re: CML1 cleanup patch, take 3
>if [ "$CONFIG_PRINTER" != "n" ]; then >- bool 'Support IEEE1284 status readback' CONFIG_PRINTER_READBACK >+ bool 'Support IEEE1284 status readback' CONFIG_PARPORT_1284 >fi This isn't really right. Although it's true that CONFIG_PARPORT_1284 enables the stuff that used to be controlled by CONFIG_PRINTER_READBACK, the two aren't synonymous. The m68k port ought to just use drivers/parport/Config.in like everybody else. p. - 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/
Re: CML1 cleanup patch, take 3
if [ "$CONFIG_PRINTER" != "n" ]; then - bool 'Support IEEE1284 status readback' CONFIG_PRINTER_READBACK + bool 'Support IEEE1284 status readback' CONFIG_PARPORT_1284 fi This isn't really right. Although it's true that CONFIG_PARPORT_1284 enables the stuff that used to be controlled by CONFIG_PRINTER_READBACK, the two aren't synonymous. The m68k port ought to just use drivers/parport/Config.in like everybody else. p. - 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/
small patch for unsigned char breakage in rtl8129 driver
--- linux/drivers/net/rtl8129.c Sat Nov 4 16:42:22 2000
+++ linux/drivers/net/rtl8129.c Sat Nov 4 16:48:21 2000
@@ -271,7 +271,7 @@ struct rtl8129_private {
unsigned char *tx_bufs; /* Tx bounce buffer region. */
dma_addr_t rx_ring_dma;
dma_addr_t tx_bufs_dma;
- char phys[4]; /* MII device
addresses. */
+ signed char phys[4];/* MII device addresses. */
char twistie, twist_cnt;/* Twister tune state. */
unsigned int tx_full:1; /* The Tx queue is full. */
unsigned int full_duplex:1; /* Full-duplex operation
requested. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.1, slhc as a module
The makefile in drivers/net goes like this: obj-$(CONFIG_SLIP) += slip.o ifeq ($(CONFIG_SLIP),y) obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o else ifeq ($(CONFIG_SLIP),m) obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o endif endif CONFIG_SLIP_COMPRESSED is a `bool' value. The way the makefile is written, selecting compression will always build slhc.o into the kernel, even if SLIP is a module. This doesn't seem like the way it ought to work. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1, slhc as a module
The makefile in drivers/net goes like this: obj-$(CONFIG_SLIP) += slip.o ifeq ($(CONFIG_SLIP),y) obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o else ifeq ($(CONFIG_SLIP),m) obj-$(CONFIG_SLIP_COMPRESSED) += slhc.o endif endif CONFIG_SLIP_COMPRESSED is a `bool' value. The way the makefile is written, selecting compression will always build slhc.o into the kernel, even if SLIP is a module. This doesn't seem like the way it ought to work. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
small patch for unsigned char breakage in rtl8129 driver
--- linux/drivers/net/rtl8129.c Sat Nov 4 16:42:22 2000
+++ linux/drivers/net/rtl8129.c Sat Nov 4 16:48:21 2000
@@ -271,7 +271,7 @@ struct rtl8129_private {
unsigned char *tx_bufs; /* Tx bounce buffer region. */
dma_addr_t rx_ring_dma;
dma_addr_t tx_bufs_dma;
- char phys[4]; /* MII device
addresses. */
+ signed char phys[4];/* MII device addresses. */
char twistie, twist_cnt;/* Twister tune state. */
unsigned int tx_full:1; /* The Tx queue is full. */
unsigned int full_duplex:1; /* Full-duplex operation
requested. */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
>Does it? At which point? To me it looks like it calls dev->do_ioctl
>or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev->set_config) {
if (!netif_device_present(dev))
return -ENODEV;
return dev->set_config(dev,>ifr_map);
}
return -EOPNOTSUPP;
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
Does it? At which point? To me it looks like it calls dev-do_ioctl
or am I missing something?
It uses SIOCSIFMAP, which (I think) winds up in dev.c here:
case SIOCSIFMAP:
if (dev-set_config) {
if (!netif_device_present(dev))
return -ENODEV;
return dev-set_config(dev,ifr-ifr_map);
}
return -EOPNOTSUPP;
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
>Does 'ifconfig eth0 media xxx' wind up calling dev->set_config? Yes. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
Does 'ifconfig eth0 media xxx' wind up calling dev-set_config? Yes. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
In message <[EMAIL PROTECTED]>, Russell King wri tes: >We already have a standard interface for this, but many drivers do not >support it. Its called "ifconfig eth0 media xxx": The Ethtool interface is rather better. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Configuring synchronous interfaces in Linux
In message [EMAIL PROTECTED], Russell King wri tes: We already have a standard interface for this, but many drivers do not support it. Its called "ifconfig eth0 media xxx": The Ethtool interface is rather better. p. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] pesky printf format warnings
Confusion between `int' and `long int'...
p.
Index: drivers/block/linear.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/block/linear.c,v
retrieving revision 1.7
diff -u -p -u -r1.7 linear.c
--- drivers/block/linear.c 2000/08/02 18:34:38 1.7
+++ drivers/block/linear.c 2000/09/03 21:52:36
@@ -144,7 +144,7 @@ static int linear_make_request (mddev_t
if (block >= (tmp_dev->size + tmp_dev->offset)
|| block < tmp_dev->offset) {
- printk ("linear_make_request: Block %ld out of bounds on dev %s size
%d offset %d\n", block, kdevname(tmp_dev->dev), tmp_dev->size, tmp_dev->offset);
+ printk ("linear_make_request: Block %ld out of bounds on dev %s size
+%ld offset %ld\n", block, kdevname(tmp_dev->dev), tmp_dev->size, tmp_dev->offset);
return -1;
}
bh->b_rdev = tmp_dev->dev;
Index: drivers/block/raid0.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/block/raid0.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 raid0.c
--- drivers/block/raid0.c 2000/08/27 19:24:57 1.8
+++ drivers/block/raid0.c 2000/09/03 21:52:39
@@ -103,7 +103,7 @@ static int create_strip_zones (mddev_t *
zone->nb_dev = c;
zone->size = (smallest->size - current_offset) * c;
- printk(" zone->nb_dev: %d, size: %d\n",zone->nb_dev,zone->size);
+ printk(" zone->nb_dev: %d, size: %ld\n",zone->nb_dev,zone->size);
if (!conf->smallest || (zone->size < conf->smallest->size))
conf->smallest = zone;
@@ -112,7 +112,7 @@ static int create_strip_zones (mddev_t *
curr_zone_offset += zone->size;
current_offset = smallest->size;
- printk("current zone offset: %d\n", current_offset);
+ printk("current zone offset: %ld\n", current_offset);
}
printk("done.\n");
return 0;
@@ -139,7 +139,7 @@ static int raid0_run (mddev_t *mddev)
goto out_free_conf;
printk("raid0 : md_size is %d blocks.\n", md_size[mdidx(mddev)]);
- printk("raid0 : conf->smallest->size is %d blocks.\n", conf->smallest->size);
+ printk("raid0 : conf->smallest->size is %ld blocks.\n", conf->smallest->size);
nb_zone = md_size[mdidx(mddev)]/conf->smallest->size +
(md_size[mdidx(mddev)] % conf->smallest->size ? 1 : 0);
printk("raid0 : nb_zone is %ld.\n", nb_zone);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch] today's "signed char" sin bin
Here's the latest collection of drivers that assumed "char" is always signed.
p.
Index: drivers/net/eepro100.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/net/eepro100.c,v
retrieving revision 1.15
diff -u -p -u -r1.15 eepro100.c
--- drivers/net/eepro100.c 2000/08/27 19:25:16 1.15
+++ drivers/net/eepro100.c 2000/09/03 21:54:12
@@ -528,7 +528,7 @@ struct speedo_private {
struct speedo_mc_block *mc_setup_tail;/* Multicast setup frame list tail. */
int in_interrupt; /* Word-aligned
dev->interrupt */
unsigned char acpi_pwr;
- char rx_mode; /* Current
PROMISC/ALLMULTI setting. */
+ signed char rx_mode;/* Current PROMISC/ALLMULTI
+setting. */
unsigned int tx_full:1; /* The Tx queue is full. */
unsigned int full_duplex:1; /* Full-duplex operation
requested. */
unsigned int flow_ctrl:1; /* Use 802.3x flow control. */
Index: drivers/net/rtl8129.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/net/rtl8129.c,v
retrieving revision 1.5
diff -u -p -u -r1.5 rtl8129.c
--- drivers/net/rtl8129.c 2000/08/02 19:38:07 1.5
+++ drivers/net/rtl8129.c 2000/09/03 21:54:17
@@ -271,7 +271,7 @@ struct rtl8129_private {
unsigned char *tx_bufs; /* Tx bounce buffer region. */
dma_addr_t rx_ring_dma;
dma_addr_t tx_bufs_dma;
- char phys[4]; /* MII device
addresses. */
+ signed char phys[4];/* MII device addresses. */
char twistie, twist_cnt;/* Twister tune state. */
unsigned int tx_full:1; /* The Tx queue is full. */
unsigned int full_duplex:1; /* Full-duplex operation
requested. */
Index: drivers/char/rio/rioctrl.c
===
RCS file: /cvsroot/pub/kernel/armlinux/drivers/char/rio/rioctrl.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 rioctrl.c
--- drivers/char/rio/rioctrl.c 2000/05/27 21:54:17 1.2
+++ drivers/char/rio/rioctrl.c 2000/09/03 21:53:01
@@ -1807,7 +1807,7 @@ uchar Cmd;
return RIO_FAIL;
}
- if (((int)((char)PortP->InUse) == -1) || ! (CmdBlkP = RIOGetCmdBlk()) ) {
+ if (((int)((signed char)PortP->InUse) == -1) || ! (CmdBlkP = RIOGetCmdBlk()) )
+{
rio_dprint(RIO_DEBUG_CTRL, ("Cannot allocate command block for command
%d on port %d\n",
Cmd, PortP->PortNum));
return RIO_FAIL;
@@ -1882,7 +1882,7 @@ uchar Cmd;
** allowed then we should not bother sending any more to the
** RTA.
*/
- if ((int)((char)PortP->WflushFlag) == (int)-1) {
+ if ((int)((signed char)PortP->WflushFlag) == (int)-1) {
rio_dprint(RIO_DEBUG_CTRL, ("Trashed WFLUSH,
WflushFlag about to wrap!"));
RIOFreeCmdBlk(CmdBlkP);
return(RIO_FAIL);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
