On Tue, 25 Jan 2000, Joerg Reuter DL1BKE wrote:
> And not on dev-hams, either.
I haven't noticed open subscribtion to dev-hams .. there are people who
are interrested. Maybe just welcome message with BIG statement that one
should not reply to things he doesn't understand or something would do ..
> Nice thing to observe existing interfaces change with just a small
> notice ommiting _how_ this is going to happen.
>
> Could you please post it here?
Done .. see fwded mail.
> They have to, at least the applications. User has a 2.2.x based
> dist, upgrades to kernel 2.4.x. He's probably aware that he has to
> upgrade system utilities. If at all. But breaking applications is a
> different thing. Joe user will not understand why his formerly perfectly
> running application suddenly fails.
>
> This is bad, especially if it just for the sake of some useless
> statistical data. Furthermore it is a nightmare for distribution
> vendors and users and will put Linux into a bad light.
>
> The correct thing to do is slowly phasing it out. Keep it around for at
> least one unstable and stable kernel series and printk() a warning that it
> will go away. And take care that when it is gone old applications will
> die gracefully (_not_ randomly core dump).
I'm not a big fan of keeping old stuff. We now have development kernel.
When 2.4 comes out I suppose people to upgrade all their stuff.
On the other hand it is nice to be compatible.
> We should start phase out "struct sockaddr_ax25" now, BTW. We're
> carrying this thing with us for too long now and I doubt any application
> still uses it. I don't know if it even works nowadays.
sockaddr_ax25 ?
Programs use full_sockaddr_ax25 but sockaddr_ax25 is part of it. You mean
removing it as a separate struct ?
> > Well there are some parts in current kernel AX25 I'm wondering how they
> > got there :)
>
> Because a program is something that evolves. The code is designed after
> the SDL diagrams and glued to the rest of the networking code with an
> ever-changing interface. The worst thing is the transmition of IP
> datagrams through the arp mechanism, but it was the only possible solution
> to conform to the device driver model at the time it was written.
Now time has come for new better code :)
Jan
