On 7 Jul 99 at 8:17, Craig Small wrote:
> I would hardly call changing a kernel with a different major
> number to be a "simple" change. It is significant.
Agreed. It is not trivial at all.
> Of course to do that the information has to go somewhere, it is
> now found in glibc headers, specifically glibc 2.1 While
> developing these libraries, it was found that there was some
> missing "stuff" from these headers; the short story is that the
> glibc 2.1 people transferred kernel 2.0.34 headers across,
> unfortunately there was a major change in the kernel at 2.0.36 (I
> think I got these version numbers right).
Ughhh ! So the source of the headaches is there. There was a change
at 2.0.35, that did away with patching to include ham stuff going,
namely, ax25-utils. 2.0.36 is better, and is what I use now. I am
getting ready to jump to 2.0.37, I have a patch for it now. It has
been impossible to download the whole new kernel for me. It is my
limited bandwidth link...
>I then let the GNU people know that there was a problem. They
>then put the changes in place, if you look in the glibc changelog,
>you should find something like:
> 1999-05-02 Ulrich Drepper <[EMAIL PROTECTED]>
>
> * sysdeps/unix/sysv/linux/netax25/ax25.h: Update from kernel header.
> * sysdeps/unix/sysv/linux/netrom/netrom.h: Likewise.
> * sysdeps/unix/sysv/linux/netrose/rose.h: Likewise.
> Patch by Craig Small <[EMAIL PROTECTED]>.
>
> The problem is now is that while Debian is fine, RedHat has yet to
> get their collective act together and get a more recent glibc 2.1
> There has been attempts by myself to accomodate this broken header
> set but it is made difficult with the fact my libraries are fine.
That is the key issue. Thank you, Craig, for pointing the details.
Frankly, all the problems I see discussed here scare me to go
straight ahead to the 2.2.x family. It is just too close to the blood
dripping edge, and I am no C guru. Its time to wait and keep on
watching.
>There is also some kernel 2.2.x issues, mainly about the packet
>type socket. The next release will use the "right" ioctl which
>should fix that.
>
> In summary, you should treat the new code as alpha, we are still
> trying to work the quirks out of the system. I believe the old
> utils work fine for kernels 2.0.34, you should probably stick with
> that unless your sure the new set is going to work for you.
The change came with 2.0.35. I believe it is the oldest kernel one
should use if you want to play with ax25-utils-2.1.42, if you are a
newcomer and you are setting up a new installation, it seems to me
it is the easier way.
I believe 2.0.36 is entirely safe and has many options included, less
one I need: Shared IRQ's. It worked with BPQ under DOS with a
modified four port MS-400 card, and doesn't work under Linux kernel
2.0.36, and is a very convenient solution for me. I was told once
that some 2.1.x has it solved. Does 2.2.x solve this ?
I began running into trouble with ax25-utils-2.1.42a when I switched
to Red Hat 5.1. The node did not compile. The simple and fast
solution for me was to get a precompiled rpm and that is what I am
using and working with, all works and it is configured much in the
look of my old MSDOS/BPQ stuff for incoming connections. And it works
fairly well.
At least I stand warned about the reason of all the problems many of
us are facing, and hopeful a solution is on the works.
Once again, thanks, Craig, for all the key issues you have put in the
clear. I would also like that the results of my experiences which I
have shown above saves some hair pulling and head banging for the
newcomers. It takes a lot of reading, a lot of asking and a some
decision making to go ahead with your particular solution. It is not
simple but results are very stable, and stability is a key issue
when delivering a service, like running a ham BBS. Also, thanks to
all that documented their work and responded my mails before I
configured the two BBS's I sysop, it made my life a lot simpler.
And thanks to linux-hams, without this list it would be incredibly
harder to get Linux to work with our stuff and interests.
73 de Jose, CO2JA
---
Ing. Jose A. Amador | Telf: (537) 20-7814
Depto de Telecomunicaciones | E-Mail: [EMAIL PROTECTED]
ISPJAE |
