Re: [patch 1/2] m68k: runtime patching infrastructure
On Wed, May 30, 2007 at 01:19:45PM +0200, Geert Uytterhoeven wrote: > > > Actually, this is the only way to define circular referencing > > structures. > > No, you have forward declarations for that. These are missing here. I am no gcc expert, but might this be considred an implicit declaration? IIRC the compiler warns if later the type does noch match. Does it keep quiet when it matches? Bye, Joerg signature.asc Description: Digital signature
Re: [patch 1/2] m68k: runtime patching infrastructure
On Wed, May 30, 2007 at 09:06:08AM +0200, Geert Uytterhoeven wrote:
[...]
> > >
> > > I think it could be tightened up even if it happens not to warn?
> >
> >
> > struct a {
> > struct not_yet_defined *start, *end;
> > };
> >
> > struct not_yet_defined {
> > void *foo;
> > };
> >
> > Is a valid and gives no warnings.
>
> I was puzzled by this as well, as there were no compiler warnings...
Pointers are (at least on m68k) of known size, so the compiler knows how
much space the struct occupies.
Type checking is by definition futile with void * pointer, but for all
other cases the compiler has all types and sizes it needs at this point.
The actual dereferencing of the symbol table is done by the linker,
which also knows all locations and sizes it needs.
Actually, this is the only way to define circular referencing
structures.
A one-pass-compiler-linker would run into problems.
Joerg, trying to recall compiler construction lessons
signature.asc
Description: Digital signature
Re: [patch 1/2] m68k: runtime patching infrastructure
On Wed, May 30, 2007 at 09:06:08AM +0200, Geert Uytterhoeven wrote:
[...]
I think it could be tightened up even if it happens not to warn?
struct a {
struct not_yet_defined *start, *end;
};
struct not_yet_defined {
void *foo;
};
Is a valid and gives no warnings.
I was puzzled by this as well, as there were no compiler warnings...
Pointers are (at least on m68k) of known size, so the compiler knows how
much space the struct occupies.
Type checking is by definition futile with void * pointer, but for all
other cases the compiler has all types and sizes it needs at this point.
The actual dereferencing of the symbol table is done by the linker,
which also knows all locations and sizes it needs.
Actually, this is the only way to define circular referencing
structures.
A one-pass-compiler-linker would run into problems.
Joerg, trying to recall compiler construction lessons
signature.asc
Description: Digital signature
Re: [patch 1/2] m68k: runtime patching infrastructure
On Wed, May 30, 2007 at 01:19:45PM +0200, Geert Uytterhoeven wrote: Actually, this is the only way to define circular referencing structures. No, you have forward declarations for that. These are missing here. I am no gcc expert, but might this be considred an implicit declaration? IIRC the compiler warns if later the type does noch match. Does it keep quiet when it matches? Bye, Joerg signature.asc Description: Digital signature
[Patch] bug in gdth.c crashing machine
Hello Achim,
wrt to your mail to the lkml from 13 Oct 2006 Message-ID:
<[EMAIL PROTECTED]>,
I'd be pleased if you could integrate the derived patch into a bugfix
release of the driver asap.
This bug kept me busy for three days, endangering backup to tapes.
Patch is against vanilla 2.6.20.
Kind regards,
Joerg
Signed-off-by: Joerg Dorchain <[EMAIL PROTECTED]>
--- gdth.c.orig 2007-02-23 12:48:56.0 +0100
+++ gdth.c 2007-02-23 12:51:44.0 +0100
@@ -3092,6 +3092,7 @@
cmdp->u.raw64.direction =
gdth_direction_tab[scp->cmnd[0]]==DOU ?
GDTH_DATA_OUT:GDTH_DATA_IN;
memcpy(cmdp->u.raw64.cmd,scp->cmnd,16);
+cmdp->u.raw64.sg_ranz= 0;
} else {
cmdp->u.raw.reserved = 0;
cmdp->u.raw.mdisc_time = 0;
@@ -3108,6 +3109,7 @@
cmdp->u.raw.direction =
gdth_direction_tab[scp->cmnd[0]]==DOU ?
GDTH_DATA_OUT:GDTH_DATA_IN;
memcpy(cmdp->u.raw.cmd,scp->cmnd,12);
+cmdp->u.raw.sg_ranz= 0;
}
if (scp->use_sg) {
signature.asc
Description: Digital signature
[Patch] bug in gdth.c crashing machine
Hello Achim,
wrt to your mail to the lkml from 13 Oct 2006 Message-ID:
[EMAIL PROTECTED],
I'd be pleased if you could integrate the derived patch into a bugfix
release of the driver asap.
This bug kept me busy for three days, endangering backup to tapes.
Patch is against vanilla 2.6.20.
Kind regards,
Joerg
Signed-off-by: Joerg Dorchain [EMAIL PROTECTED]
--- gdth.c.orig 2007-02-23 12:48:56.0 +0100
+++ gdth.c 2007-02-23 12:51:44.0 +0100
@@ -3092,6 +3092,7 @@
cmdp-u.raw64.direction =
gdth_direction_tab[scp-cmnd[0]]==DOU ?
GDTH_DATA_OUT:GDTH_DATA_IN;
memcpy(cmdp-u.raw64.cmd,scp-cmnd,16);
+cmdp-u.raw64.sg_ranz= 0;
} else {
cmdp-u.raw.reserved = 0;
cmdp-u.raw.mdisc_time = 0;
@@ -3108,6 +3109,7 @@
cmdp-u.raw.direction =
gdth_direction_tab[scp-cmnd[0]]==DOU ?
GDTH_DATA_OUT:GDTH_DATA_IN;
memcpy(cmdp-u.raw.cmd,scp-cmnd,12);
+cmdp-u.raw.sg_ranz= 0;
}
if (scp-use_sg) {
signature.asc
Description: Digital signature
Re: Kbuild problem
On Tue, Feb 20, 2007 at 02:56:27PM +0100, Tilman Schmidt wrote: > > One disadvantage of this approach is that in a kernel with > > CONFIG_GIGASET_BASE=y, you can't later compile and load the usb_gigaset > > or ser_gigaset modules without rebooting since they require a change to > > the kernel image. > > You've got a point there. So linking asyncdata.o into the modules that > need it, as it is currently done, would perhaps be better after all? From the architectural point of view, what odds against making it a module of its own? Dependancies are resolved by modprobe, so users should be fine. There are other library-like parts in the kernel where an object is built statically when at least one needing driver is static, a module when all nedding drivers are modules, or not at all but appears are a config option when no in-kernel driver needs it. > > The alternative would be to always link asyncdata.o into the gigaset > module whether it's needed or not. "size asyncdata.o" says: >textdata bss dec hex filename >4200 0 042001068 asyncdata.o > which appears tolerable. Ugly. But I've seen worse. Bye, Joerg signature.asc Description: Digital signature
Re: Kbuild problem
On Tue, Feb 20, 2007 at 02:56:27PM +0100, Tilman Schmidt wrote: One disadvantage of this approach is that in a kernel with CONFIG_GIGASET_BASE=y, you can't later compile and load the usb_gigaset or ser_gigaset modules without rebooting since they require a change to the kernel image. You've got a point there. So linking asyncdata.o into the modules that need it, as it is currently done, would perhaps be better after all? From the architectural point of view, what odds against making it a module of its own? Dependancies are resolved by modprobe, so users should be fine. There are other library-like parts in the kernel where an object is built statically when at least one needing driver is static, a module when all nedding drivers are modules, or not at all but appears are a config option when no in-kernel driver needs it. The alternative would be to always link asyncdata.o into the gigaset module whether it's needed or not. size asyncdata.o says: textdata bss dec hex filename 4200 0 042001068 asyncdata.o which appears tolerable. Ugly. But I've seen worse. Bye, Joerg signature.asc Description: Digital signature
