I thought I better first up say that I have not looked at the
implementation, is it better or not (though I totally agree that the way
things are done is suboptimal and would like to see sounthing like
iproute if ifup/ifdown scheme). My only problem is a migration
strategy. We are at X and we want to get to Y.
It sounds like you are re-writing an awful lot, that's fine too. If you
are removing ioctls, let's add the new ones in leave the old ones there
then remove the old ones. Look at what was done with ipchains/ipfwadm.
On Wed, Apr 26, 2000 at 11:17:52PM +0200, Jens David wrote:
> Joerg conviced me that keeping the old socket API for applications is
> mandatory. However, I do not see why new user space setup utilities
> need to work with (mostly) 3 years old kernel code? Do other tools such
> as the hdparms etc. work with old kernel drivers? I honestly don´t know,
> but I would not expect it to do so. The point why I am asking this is
> because it bloats tool source and IMO makes it unmaintainable, thus again
> causing potention error sources.
If you are radically changing a tool, then please change its name to
something different. Look at iproute, they didn't suddently change
ifconfig breaking pretty much everything, the made a new tool called
/sbin/ip
ip does pretty much what ifconfig does, but more. So if you want the new
feature Z, then you must use ip. I actually like ip a lot, other than
its name.
And yes there are plenty of tools that have different ioctls or other
functions depending on what kernel they are running on and *this is a
run-time check*.
The main idea is to stick all that sort of stuff into a library, then
all tools just use that library. If you only change the back end, you
bump the minor number, change the API you bumb up the major and have a
binary->library dependency.
> Remember we are talking about the future here, maybe one or 1.5 years.
Plenty of time to do a nice slow migration across, don't you think?
#ifdefs are a bad idea for reasons mentioned before. I mean if it comes
to it take the libax25 make two directories, put the old stuff in old/
your stuff in new/ and in the top directory a big bunch of
if (something to test) then new_func(); else old_func();
I believe any existing tools and apps would not need too much modification,
if there is a need what needs to be changed. Perhaps anything dependent
on the kernel should be shifted into the library, we can do that now.
Let's get the library ready for the new kernel (and its API) now, so
people will migrate over to the dual mode library so when the kernel
changes the tools suddenly die.
> What I really do not understand is why for example listen is part of
> ax25-apps while other low-level stuff is part of ax25-tools. Where´s the
> difference, why not one package for simplicity?
> Why not call the resulting package "ax25-utils" again, any refs on the
I think merging could be a good idea, let's see what others think.
I have strong objections to calling it ax25-utils; this would be a "new"
package and you have the choice of what to call it and you go for one of
the three words that can cause confusion when you could choose anything
except -utils -apps or -tools and there would be NO confusion at all.
> original 2.1.43 (or whatever it was) stuff will surely be erased by then,
> or at least nobody will have the bright idea to use 2.1.x-stuff with 2.5,
> right? So this should be enough to distinguish both packages?
Without causing offence to fellow hams, I think you have greatly
overestimated some peoples, hmm..., computer savvy. If the decision is
to merge the packages, I dont care about the name, but anything but not
those three!
--
Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.eye-net.com.au/ <[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
