Hi Oliver, I moved this discussion to the networking list, now that we go into the details ;-) > > Actually, I don't like that too much, and for a number of reasons: > > 1) it hides that the device in /dev/net/ is actually used for this > > interface; it disconnects information for no good reason > > 2) it clashes with the use of the ":x" notation we intended to > > implement (to have more than one address per device) > > 3) ifconfig is not a tool you won't be using regularly anymore when > > we > > have a GUI, hence it will probably only used to change > > functionality > > that the GUI doesn't allow for. > > 4) the device module detection currently works using pattern > > matching, > > ie. the ethernet device module will accept anything that starts > > with "/ > > dev/net/", the loopback device will use anything that starts with > > "loop". > > 5) you can use tab completion to get the /dev/net/rtl8139/0 > > interface : > > -) > > > > What do you think? > Well, it was just an idea >;o) esp. argument 4) suggests to leave it > as is. Well, I don't want to convince you otherwise, but ifconfig could handle this, if it wanted to; when creating an interface, you can select a driver name independent from the actual interface name... > > BTW interfaces currently don't like to be taken down too much - as > > we > > reference them in the buffers (and probably elsewhere), we have to > > add > > reference counting to them as well, I think. > Yes, we should definitely do that, now that the destination interface > is put > into the buffer again. However, the reason why I temporarily disabled > that in > ipv4_reveive_data() was that I thought buffer->interface was > referring to the > source interface (the one through which the buffer came into the > stack). The > use in ipv4.cpp indicated that was the destination interface, though. > This is > in contrast with icmp.cpp, which (in receive_data()) treats buffer-> > interface > as the source interface. > I suppose it makes more sense to store the source interface into the > buffer, > but what do you think? There is no real difference, I think - the buffer entered the stack coming from a device, not an interface. Depending of its target address, IPv4 is able to assign an interface to that buffer - how else could that work? Am I missing something, again? :-) I am also not sure if it's absolutely needed to have this pointer - it just came in handy when doing the ICMP echo reply... > > When you say you wanted to work on ICMP, do you mean redirects, > > path > > MTU discovery and the like? :-) > Well, I intended to start with implementing 'port unreachable' and > other > error messages first >;o) When simple error messages are done, I > could then > proceed with redirects and MTU discovery, but I suppose it would be > better to > start working on DHCP and name resolution, what do you think? I had thought you'd need TCP for DNS, but then, I dunno if it's really required. But IIRC someone wrote a DHCP client for us, and we might want to have a look at it before porting something. I just have no idea where it is in the repository, though. Does anybody know this? Bye, Axel.