KJD 2.3.9 patch on 2.5.29

KJD 2.3.9 patch on 2.5.29

[Iain Young - G7III]

Hi All,

With the AX25 status on 2.5/2.6 thread, and Tomi mentioning the
KJD patch, I decided to see how much work would be involved in
porting it to 2.5

(since the AX25 stack hasn't been touched much for a while, I
thought it would be easier than other subsystems, that have had
constant change).

The 2.3[4] version of the patch always lagged behind the 2.2, and
the latest version i could find was 2.3.9. This is known to be
roughly equivalent to the 2.2.17 patch.

It would seem there are around 74 files modified, or created in the
patch. Having applied it 'raw' to the pure 2.5.29 tree, I had 35
reject files created.

Two of those were the Makefile, and Config.in, so were expected to
break, but should be easy to fix. Another  eight were detected as
"Reverse or Previously Applied Patches", so I declined to apply them.

(I suspect that these are induvidual patches, that found their
way into later 2.3, or 2.4 - seaches of linux-kernel do find some
AX25 patches around 2.4.17 at least)

That should leave around 25 .rej's to work through, to bring it up
to the level of 2.3.9. Then of course the changes bewtween 2.2.17
and 2.2.20 need to be mixed in as well.

On a Hunk basis, 83 FAILED, while 73 succeeded, which is about right
when you look at the number of .rej's created (The 83 include the 8
reverse or previously applied patches).

Hopefully I'll get some time this weekend, and see what I can do
cut those rej's down. Then I get to see if it compiles.

Then I have a problem. IDE is dangerously broken in 2.5.x at the
moment. While I could grab the 2.4 IDE "forward port", that means
keeping track of two patches, and remembering to remove it before
running diff :)

Of course if anyone has a spare SCSI machine (all my SPARCs are dead
atm), then they are more than welcome to test anything I come up
with :)

[Note that you will need the modified libax25, ax25-apps, and
ax25-utils for anything I produce to even have half a chance of
working]

Anyway, I'll post later in the weekend, or early next week if I
have any meaningfull success.


All the Best

Iain

Re: KJD 2.3.9 patch on 2.5.29

[Hans-Peter Zorn]

Hi Iain,
have a look at http://ftp.ccac.rwth-aachen.de/pub/jr/newax25-devel/ .
Joerg started to port Jens' and Matzes  code to 2.4, but he didn't
complete it and he stopped developement at 2.4.3 (time constraints I
guess).

73s HP

Re: KJD 2.3.9 patch on 2.5.29

[Iain Young - G7III]

On Thu, Aug 01, 2002 at 11:33:37PM +0200, Hans-Peter Zorn wrote:

> have a look at http://ftp.ccac.rwth-aachen.de/pub/jr/newax25-devel/ .
> Joerg started to port Jens' and Matzes  code to 2.4, but he didn't
> complete it and he stopped developement at 2.4.3 (time constraints I
> guess).
 
Ah. thats where that got to :) Thanks very much for that, this one
has 59 hunks FAILED, while 109 succeeded, but with 40 reject files.

Guess I should go look at some of them, although at least some are
very simple, from a brief look at them.


All the Best

Iain.

Re: KJD 2.3.9 patch on 2.5.29

[Ralf Baechle DO1GRB]

On Thu, Aug 01, 2002 at 08:46:18PM +0100, Iain Young - G7III wrote:

> With the AX25 status on 2.5/2.6 thread, and Tomi mentioning the
> KJD patch, I decided to see how much work would be involved in
> porting it to 2.5
> 
> (since the AX25 stack hasn't been touched much for a while, I
> thought it would be easier than other subsystems, that have had
> constant change).

Definately not.  The whole AX.25, NET/ROM and ROSE code is suffering from
severe bitrot.  None of the internal data structures are properly locked
etc.  I'm currently working on that.

So you may find it easy to get old code into the current kerrnel - but
then it'll suffer from the same problems.  The fact is that the AX.25
code is looking like it was written for a 2.0 or 2.2 kernel ...

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: KJD 2.3.9 patch on 2.5.29

[Iain Young - G7III]

Hi Ralf,

You Wrote:
 
> > (since the AX25 stack hasn't been touched much for a while, I
> > thought it would be easier than other subsystems, that have had
> > constant change).
> 
> Definately not.  The whole AX.25, NET/ROM and ROSE code is suffering from
> severe bitrot.  None of the internal data structures are properly locked
> etc.  I'm currently working on that.

I meant easier as in easier to merge, as there would be few patches
that have been added to the mainline, thus less rejects.

Id actually be interested in your fixes, I may be able to integrate
them into any 2.5 version of the KJD AX25 stack that I manage to
produce.
 
> So you may find it easy to get old code into the current kerrnel - but
> then it'll suffer from the same problems.  The fact is that the AX.25
> code is looking like it was written for a 2.0 or 2.2 kernel ...

The KJD 'patch' is more like an entirely new AX25 stack - The Stack
in 2.4/2.5 currently predates it. The origional idea was to get the
KJD/FEF stack into 2.3, and thus 2.4 when it was released.

Unfortunatley Matt and Jens ran out of time, and priorties changed,
however a 2.4.x version was started by Jens, and was up to 2.4.9, but
is only a partial patch (there are a few .rej's actually in the patch).

Checkout http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25 for more
details, and why Jens gave it up.


All the Best

Iain.

Re: KJD 2.3.9 patch on 2.5.29

[Ralf Baechle DO1GRB]

On Fri, Aug 02, 2002 at 07:28:54PM +0100, Iain Young - G7III wrote:

> > > (since the AX25 stack hasn't been touched much for a while, I
> > > thought it would be easier than other subsystems, that have had
> > > constant change).
> > 
> > Definately not.  The whole AX.25, NET/ROM and ROSE code is suffering from
> > severe bitrot.  None of the internal data structures are properly locked
> > etc.  I'm currently working on that.
> 
> I meant easier as in easier to merge, as there would be few patches
> that have been added to the mainline, thus less rejects.
> 
> Id actually be interested in your fixes, I may be able to integrate
> them into any 2.5 version of the KJD AX25 stack that I manage to
> produce.

I'll make them available asap; I've still a huge number of loose ends to
solve, hours of typing ahead ...

> > So you may find it easy to get old code into the current kerrnel - but
> > then it'll suffer from the same problems.  The fact is that the AX.25
> > code is looking like it was written for a 2.0 or 2.2 kernel ...
> 
> The KJD 'patch' is more like an entirely new AX25 stack - The Stack
> in 2.4/2.5 currently predates it. The origional idea was to get the
> KJD/FEF stack into 2.3, and thus 2.4 when it was released.
> 
> Unfortunatley Matt and Jens ran out of time, and priorties changed,
> however a 2.4.x version was started by Jens, and was up to 2.4.9, but
> is only a partial patch (there are a few .rej's actually in the patch).
> 
> Checkout http://www.afthd.tu-darmstadt.de/~dg1kjd/linux-ax25 for more
> details, and why Jens gave it up.

Thanks for reminding me of that code again.  I'd not mind taking that
patch as a base to start with.  However the author doesn't even claim it
to be working and the patch only minimally deals with the problems that
the current code is suffering from.  I also had a conversation with
Alan Cox (GW4PTS) who originally wrote the code.  Alan wasn't fond at all
of newax25 because the oldcode despite it's problem is fairly stable in
practical use.  So I came to the conclusion the the best thing will be if
I first solve the problems of the current codebase and then later import
code from the DG1KJD.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: KJD 2.3.9 patch on 2.5.29

[Iain Young - G7III]

On Mon, Aug 05, 2002 at 02:28:24PM +0200, Ralf Baechle DO1GRB wrote:

> I'll make them available asap; I've still a huge number of loose ends to
> solve, hours of typing ahead ...

Heh, I know that feeling :) 
 
> Thanks for reminding me of that code again.  I'd not mind taking that
> patch as a base to start with.  However the author doesn't even claim it
> to be working and the patch only minimally deals with the problems that
> the current code is suffering from.  I also had a conversation with
> Alan Cox (GW4PTS) who originally wrote the code.  Alan wasn't fond at all
> of newax25 because the oldcode despite it's problem is fairly stable in
> practical use.  So I came to the conclusion the the best thing will be if
> I first solve the problems of the current codebase and then later import
> code from the DG1KJD.

Yeah, that is actually a good point from Alan. And there are things that
KJD code does that I consider 'wrong' - see my previous recent emails on
'network purity'. 

I believe it also changes the interface definitions, and needs a modified
libax25/apps/tools.

For what its worth, I did get quite far in getting it merged into a
2.5.29 tree. Got approximatley 50% of the rejects sorted, but most of
the remaining ones were the soundmodem, and scc drivers.

Unfortunatley, most of the remainder are in the core AX25 code, and
one reject in particular is 60K!


All the Best

Iain

Re: KJD 2.3.9 patch on 2.5.29

[Ralf Baechle DO1GRB]

On Mon, Aug 05, 2002 at 06:19:56PM +0100, Iain Young - G7III wrote:

> > I'll make them available asap; I've still a huge number of loose ends to
> > solve, hours of typing ahead ...
> 
> Heh, I know that feeling :) 

I've fixed many of them now and I'm just trying to setup a repository
on bkbits.net but keep running into problem

> > Thanks for reminding me of that code again.  I'd not mind taking that
> > patch as a base to start with.  However the author doesn't even claim it
> > to be working and the patch only minimally deals with the problems that
> > the current code is suffering from.  I also had a conversation with
> > Alan Cox (GW4PTS) who originally wrote the code.  Alan wasn't fond at all
> > of newax25 because the oldcode despite it's problem is fairly stable in
> > practical use.  So I came to the conclusion the the best thing will be if
> > I first solve the problems of the current codebase and then later import
> > code from the DG1KJD.
> 
> Yeah, that is actually a good point from Alan. And there are things that
> KJD code does that I consider 'wrong' - see my previous recent emails on
> 'network purity'. 
> 
> I believe it also changes the interface definitions, and needs a modified
> libax25/apps/tools.

Yuck.

> For what its worth, I did get quite far in getting it merged into a
> 2.5.29 tree. Got approximatley 50% of the rejects sorted, but most of
> the remaining ones were the soundmodem, and scc drivers.
> 
> Unfortunatley, most of the remainder are in the core AX25 code, and
> one reject in particular is 60K!

I've merged the DG1KJD code into 2.4-latest without major problems.  The
bitkeeper tools have helped me alot making that easier.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: KJD 2.3.9 patch on 2.5.29

[Ralf Baechle DO1GRB]

On Mon, Aug 05, 2002 at 08:16:01PM +0200, Ralf Baechle DO1GRB wrote:

> > > I'll make them available asap; I've still a huge number of loose ends to
> > > solve, hours of typing ahead ...
> > 
> > Heh, I know that feeling :) 
> 
> I've fixed many of them now and I'm just trying to setup a repository
> on bkbits.net but keep running into problem

You can get my stuff with bitkeeper from the following URL:

  http://linux-ham.bkbits.net/linux-2.5

Keep in mind that this is strictly work in progress.  An incomplete to do
list can be found in net/ax25/TODO.

Comments apreciated - patches even more :-)

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: KJD 2.3.9 patch on 2.5.29

[Joaquin Seoane]

Hi Ralph,

This URL do not work. The correct one is

http://linux-ham.bkbits.net:8080/linux-2.5

I guess it is a fork of the official kernel in order to merge it.

Sorry, I just discovered bitkeeper...

El lunes 05 de agosto de 2002 a las 21:16:48 (+0200), Ralf Baechle DO1GRB escribió:

> You can get my stuff with bitkeeper from the following URL:
> 
>   http://linux-ham.bkbits.net/linux-2.5


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

Re: KJD 2.3.9 patch on 2.5.29 (NOT FOUND)

[Joaquin Seoane]

Hi Ralf,

We tried to check Ralf's KJD patch to 2.5 in order to test it, but
it seems that it is not there. Perhaps you have discarded it after no
feedback from the list, or you have considered better to just patch the
original AX.25 code for 4.5.  ¿Could you say something about it?


On 05 Aug 2002, Ralf Baechle DO1GRB wrote:

> You can get my stuff with bitkeeper from the following URL:
> 
>   http://linux-ham.bkbits.net/linux-2.5
> 
> Keep in mind that this is strictly work in progress.  An incomplete to do
> list can be found in net/ax25/TODO.
> 
> Comments apreciated - patches even more :-)

On 12 Sep 2002, Joaquin Seoane wrote:

> This URL do not work. The correct one is
> 
> http://linux-ham.bkbits.net:8080/linux-2.5
> 
> I guess it is a fork of the official kernel in order to merge it.
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KJD 2.3.9 patch on 2.5.29

[Ray Heasman]

Hi Ralf,

On Mon, 2002-08-05 at 05:28, Ralf Baechle DO1GRB wrote:
> Thanks for reminding me of that code again.  I'd not mind taking that
> patch as a base to start with.  However the author doesn't even claim it
> to be working and the patch only minimally deals with the problems that
> the current code is suffering from.  I also had a conversation with
> Alan Cox (GW4PTS) who originally wrote the code.  Alan wasn't fond at all
> of newax25 because the oldcode despite it's problem is fairly stable in
> practical use.  So I came to the conclusion the the best thing will be if
> I first solve the problems of the current codebase and then later import
> code from the DG1KJD.

I am sad to hear you say this. As someone who has extensively used the
AX25 stack in different and weird ways on several machines with many (>8
ports/machine), I feel comfortable saying that:

1) The current stack is an anachronistic nightmare to actually use.
2) The current stack is terribly bug ridden and unpredictable.
3) The current stack has several misfeatures 

I think perhaps Alan doesn't really use his stack very much or perhaps
suffers a bit from parent's myopia. Yes, it doesn't kernel panic on 2.0
and 2.2 kernels (I have yet to get it to run for >24 hours on a 2.4
kernel without a kernel panic, with my Baycom scc card and all my other
ports). Yes, it nominally sends some packets around. No, it doesn't do
it correctly.

Just because it sits there and keys rigs without crashing doesn't mean
it does the right thing.

I am sorry if this comes across as rather extreme, but from the
perspective of someone who remote administers a complex station, it is
hard to say anything good about the current stack except "It doesn't
kernel panic my 2.2 kernel". If there was something else out there that
was as easy to connect to remotely over a low bandwidth link, I would
use it.

I think Jens suggestion to do most everything in userspace with a tiny
link into some useful kernel support is the right way to go.

I do see the point of making the current code worthy of being included
in a stable kernel, but I think the "next" ax25 stack should be mostly
in userspace and reimplemented from the ground up.

If anyone really cares, I am willing to sit down and try to remember and
list all the pathological behaviour I have seen in the last 4 years.

Cheers,
Ray
ZR6RAY

Re: KJD 2.3.9 patch on 2.5.29

[Ralf Baechle DO1GRB]

On Mon, Aug 05, 2002 at 11:02:06AM -0700, Ray Heasman wrote:

> On Mon, 2002-08-05 at 05:28, Ralf Baechle DO1GRB wrote:
> > Thanks for reminding me of that code again.  I'd not mind taking that
> > patch as a base to start with.  However the author doesn't even claim it
> > to be working and the patch only minimally deals with the problems that
> > the current code is suffering from.  I also had a conversation with
> > Alan Cox (GW4PTS) who originally wrote the code.  Alan wasn't fond at all
> > of newax25 because the oldcode despite it's problem is fairly stable in
> > practical use.  So I came to the conclusion the the best thing will be if
> > I first solve the problems of the current codebase and then later import
> > code from the DG1KJD.
> 
> I am sad to hear you say this. As someone who has extensively used the
> AX25 stack in different and weird ways on several machines with many (>8
> ports/machine), I feel comfortable saying that:
> 
> 1) The current stack is an anachronistic nightmare to actually use.
> 2) The current stack is terribly bug ridden and unpredictable.
> 3) The current stack has several misfeatures 
> 
> I think perhaps Alan doesn't really use his stack very much or perhaps
> suffers a bit from parent's myopia. Yes, it doesn't kernel panic on 2.0
> and 2.2 kernels (I have yet to get it to run for >24 hours on a 2.4
> kernel without a kernel panic, with my Baycom scc card and all my other
> ports). Yes, it nominally sends some packets around. No, it doesn't do
> it correctly.
> 
> Just because it sits there and keys rigs without crashing doesn't mean
> it does the right thing.
> 
> I am sorry if this comes across as rather extreme, but from the
> perspective of someone who remote administers a complex station, it is
> hard to say anything good about the current stack except "It doesn't
> kernel panic my 2.2 kernel". If there was something else out there that
> was as easy to connect to remotely over a low bandwidth link, I would
> use it.
> 
> I think Jens suggestion to do most everything in userspace with a tiny
> link into some useful kernel support is the right way to go.

Alan rejected that idea for performance reasons.  The code is also in use
with multimegabit link ...

> I do see the point of making the current code worthy of being included
> in a stable kernel, but I think the "next" ax25 stack should be mostly
> in userspace and reimplemented from the ground up.
> 
> If anyone really cares, I am willing to sit down and try to remember and
> list all the pathological behaviour I have seen in the last 4 years.

That would be very much appreciated.  I'm trying to cure the problems of
the existing code base from a kernel hackers perspective - I cannot claim
years of experience with it.

I'd also be interested in what hardware your system has and what bandwidth
all the interfaces are running at.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21

Re: KJD 2.3.9 patch on 2.5.29

[M Taylor]

On Mon, Aug 05, 2002 at 11:02:06AM -0700, Ray Heasman wrote:
> Hi Ralf,
> 
> and 2.2 kernels (I have yet to get it to run for >24 hours on a 2.4
> kernel without a kernel panic, with my Baycom scc card and all my other
> ports). Yes, it nominally sends some packets around. No, it doesn't do
> it correctly.

Do you have an decoded Oops from a 2.4 kernel panic?

> I think Jens suggestion to do most everything in userspace with a tiny
> link into some useful kernel support is the right way to go.
> 
> I do see the point of making the current code worthy of being included
> in a stable kernel, but I think the "next" ax25 stack should be mostly
> in userspace and reimplemented from the ground up.

I disagree with the idea of putting the AX.25 (and/or Net/ROM) network
protocol stacks into userspace. That would be a silly idea with no
benefit.

The idea of putting amateur radio device drivers (mkiss, BayCom, soundcard,
SCC, etc.) in userspace only makes sense for soundcard and perhaps BayCom,
because of the amount of CPU utilitization by these drivers. Since I don't
use BayCom I am not certain, but it may or may not use enough CPU to
make it sensible to put it into userspace. I suspect userspace soundcard
is safer. Why would you want mkiss, SCC or other drivers in userspace?

M Taylor

Re: KJD 2.3.9 patch on 2.5.29

[Ralf Baechle DO1GRB]

On Mon, Aug 05, 2002 at 08:35:20PM +0100, M Taylor wrote:

> > and 2.2 kernels (I have yet to get it to run for >24 hours on a 2.4
> > kernel without a kernel panic, with my Baycom scc card and all my other
> > ports). Yes, it nominally sends some packets around. No, it doesn't do
> > it correctly.
> 
> Do you have an decoded Oops from a 2.4 kernel panic?

I'd also interested just to see it the AX.25 stack or any of the ham radio
drivers was the culprit.

> I disagree with the idea of putting the AX.25 (and/or Net/ROM) network
> protocol stacks into userspace. That would be a silly idea with no
> benefit.

I'm not sure if we already can put a full network stack into userspace
while maintaining the socket API.  And anything but the standard socket
API is inacceptable.  In particular I consider apps that come with their
own stack builtin like TheNetNode heavily missdesigned.

> The idea of putting amateur radio device drivers (mkiss, BayCom, soundcard,
> SCC, etc.) in userspace only makes sense for soundcard and perhaps BayCom,
> because of the amount of CPU utilitization by these drivers. Since I don't
> use BayCom I am not certain, but it may or may not use enough CPU to
> make it sensible to put it into userspace. I suspect userspace soundcard
> is safer. Why would you want mkiss, SCC or other drivers in userspace?

Soundmodem is doing heavy numbercrunching.  That's a workload that doesn't
behave to nicely in there kernel where the driver cannot be preempted.  Once
the 2.5 scheduler redesign finally has finished I hope running a realtime
workload like soundmodem in userspace will be reliable.

73 de DO1GRB op Ralf

--
Loc. JN47BS / CQ 14 / ITU 28 / DOK A21