> According to Thorsten Kranzkowski: While burning my CPU.
> > That's exactly the point: the 'user' essentially makes an outgoing call on an
> > interface, not on a 'port bound to a callsign' - he doesn't even use that
> > callsign!
No!
1) The user makes an outgoing call using the _port_ name. 2) The 'call'
(or whatever) application translates that to a callsign using the axports
file and then 3) asks the kernel to make a connection through the port
having that callsign as the hardware address.
At no point (except maybe at some point inside the kernel) is the
kernel interface name used!
> > again - I do know how to handle that in the present design - I do
> > complain about the design!
You complain about the wrong design. Which sort of takes the basis out of
your complaints...
> > Imagine:
> > /sbin/ifconfig bcsf0 hw ax25 dl8bcu up
> > /sbin/ifconfig bcsf0 inet 44.130.8.19 mtu 1500
> > /sbin/ifconfig bcsf1 hw ax25 dl8bcu up
> > /sbin/ifconfig bcsf1 inet 44.130.8.19 mtu 1500
> >
> > Now you have two interfaces with identical Hardwere addresses - which
> > is perfectly ok for tcpip. But anything that uses axports (e.g. 'call') now
> > gets confused because it cannot decide which interface to use. So it
> > stops with an error message.
No. As I already said it's the kernel that is very much confused at this
point, not the utils. The utils just save you from the trouble by barfing
early.
Besides I'm not at all sure the kernel would be ok if the hardware
addresses for other protocols were the same. And they won't be in general:
no two ethernet cards in the world have the same hw address, ppp and slip
(being point-to-point protocols) don't even have hw addresses and so on...
--
--... Tomi Manninen / [EMAIL PROTECTED] / OH2BNS @ OH2RBI.FIN.EU ...--
