ELKS kernel source

ELKS kernel source

[Riley Williams]

Hi Alan, Harry.

As per my recent email, I have now completed the important part of the
ELKS kernel ANSI'fication and lint-checking using the splint tool. Due
to other commitments, I won't get a chance to do any further development
on the ELKS source tree until Saturday 14th June 2002, so if you want to
hammer what I've done into some other shape, please go ahead.

With regard to the problem that currently prevents the ktcp tool from
working, my testing indicates that the problem is NOT in the tcpdev.c
source file, and I am currently at a loss as to precicely what the
problem is.

For those wishing to have a working ktcp under ELKS, I have assigned two
tags in the CVS repository:

 1. elks-0_1_1-pre1-last is the last kernel in the CVS repository
    for which the kctp tool works.

 2. elks-0_1_1-pre2 is the first kernel in the CVS repository for
    which the ktcp tool fails.

Somewhere between those two patchsets is the tweak that causes ktcp to
panic, but I have been unable to find it so far and, as stated above,
I'm not likely to get a chance to do any more testing until the 14th.
Any help sorting this out will be very much appreciated.

Best wishes from Riley.

Re: ELKS kernel source

[Harry Kalogirou]

Την Τετ, 05-06-2002 στις 19:51, ο/η Riley Williams έγραψε:
> Hi Alan, Harry.
> 
> As per my recent email, I have now completed the important part of the
> ELKS kernel ANSI'fication and lint-checking using the splint tool. Due
> to other commitments, I won't get a chance to do any further development
> on the ELKS source tree until Saturday 14th June 2002, so if you want to
> hammer what I've done into some other shape, please go ahead.
> 
> With regard to the problem that currently prevents the ktcp tool from
> working, my testing indicates that the problem is NOT in the tcpdev.c
> source file, and I am currently at a loss as to precicely what the
> problem is.
> 
> For those wishing to have a working ktcp under ELKS, I have assigned two
> tags in the CVS repository:
> 
>  1. elks-0_1_1-pre1-last is the last kernel in the CVS repository
>     for which the kctp tool works.
> 
>  2. elks-0_1_1-pre2 is the first kernel in the CVS repository for
>     which the ktcp tool fails.
> 
> Somewhere between those two patchsets is the tweak that causes ktcp to
> panic, but I have been unable to find it so far and, as stated above,
> I'm not likely to get a chance to do any more testing until the 14th.
> Any help sorting this out will be very much appreciated.
> 
> Best wishes from Riley.
> 

I will look in to it...

Harry


-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ELKS kernel source

[Riley Williams]

Hi Harry.

>> As per my recent email, I have now completed the important part of
>> the ELKS kernel ANSI'fication and lint-checking using the splint
>> tool. Due to other commitments, I won't get a chance to do any
>> further development on the ELKS source tree until Saturday 14th June
>> 2002, so if you want to hammer what I've done into some other shape,
>> please go ahead.
>> 
>> With regard to the problem that currently prevents the ktcp tool
>> from working, my testing indicates that the problem is NOT in the
>> tcpdev.c source file, and I am currently at a loss as to precicely
>> what the problem is.
>> 
>> For those wishing to have a working ktcp under ELKS, I have assigned
>> two tags in the CVS repository:
>> 
>>  1. elks-0_1_1-pre1-last is the last kernel in the CVS repository
>>     for which the kctp tool works.
>> 
>>  2. elks-0_1_1-pre2 is the first kernel in the CVS repository for
>>     which the ktcp tool fails.
>> 
>> Somewhere between those two patchsets is the tweak that causes ktcp
>> to panic, but I have been unable to find it so far and, as stated
>> above, I'm not likely to get a chance to do any more testing until
>> the 14th. Any help sorting this out will be very much appreciated.

> I will look in to it...

Many thanks, Harry. In theory, no tool should be able to panic the
kernel that easily, but with no real memory protection available,
there's not much we can do in ELKS to prevent it.

Best wishes from Riley.