Petr Vandrovec Ing. VTEI wrote:
>
> Hi,
> I have three (five) questions regarding IPX code in 2.3.13. I do not know,
> which parts are addressed in upcoming networking patch, but just in case
> that they are not...
> (1) Should not IPX spinlock around walking through ipx_interfaces
> and so on? For example, where ipxitf_find_using_phys (running from
> ipx_rcv) locks against removing interface in ipxitf_down (synchronize_bh()
> before kfree_s(intrfc,...) should be enough).
The kernel lock ensures only one user land process can be in this code
at once. The only other source of interference being the timer/net bh
code as far as I can see. Putting enable/disable_by_atomic() around the
list removal would be enough to fix this. It may not be worth doing
that now... the new net patch has a different way of doing things.
The new approach would be to have a read/write spinlock for the list.
> (2) IPX does not provide SIOCGIFCONF ioctl. I was using specific IPX code
> to implement SIOCGIFCONF on IPX sockets. Last week, when I found
> register_gifconf function, I rewrote it to use this function (so IPX
> interfaces are returned on any socket type SIOCGIFCONF). Should not be one
> of these ways included in kernel? And what's better? I did not find any
> problems with returning IPX interfaces through SIOCGIFCONF on IPX socket
> (ifconfig still works correctly), but maybe it is explicitly disallowed in
> some RFC/POSIX? Currently, DECnet and IPV4 register their gifconf handlers,
> econet and appletalk calls standard dev_ioctl() for SIOCGIFCONF, but do
> not register their interfaces (this brings question: What does IPV6?)
This question seems to come up regularly :-) The buffer provided for
SIOCGIFCONF is only large enough to fit in a standard sized sockaddr
in it. If the IPX sockaddr is that size, then it should work fine.
If like DECnet/IPv6 etc. the sockaddr size
is greater than the 16 bytes allowed, then you will break several programs
by doing this. The real solution (on Linux anyway) is to use the rtnetlink
interface to get this infomation. The reason for DECnet's compile time
option is that I thought that someone might want the call even if it meant
breaking various net programs. I'm starting to think that this is rather
unlikely and I'm considering removing it.
> (3) IPX's connect() now only says to kernel that send() should pick
> this address as other endpoint - it does not affect recv/recvfrom. Should
> not connect() also limit recv/recvfrom to receive data from connected
> endpoint only (currently I have patch which allows you to create multiple
> listeners on socket 12345 as long as each socket is connected to
> different endpoint (+ one socket can be unconnected to receive all
> packets from unknown endpoints).
That would appear to make sense. I'm probably not qualified to comment on
your last two points,
Steve.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
