From owner-cvs-all Thu Jan 10 20:39: 1 2002 Delivered-To: cvs-all@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id E21F737B402; Thu, 10 Jan 2002 20:38:43 -0800 (PST) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g0B4chQ99874; Thu, 10 Jan 2002 20:38:43 -0800 (PST) (envelope-from marcel@kayak.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.11.6/8.11.6) id g0B4dIL00604; Thu, 10 Jan 2002 20:39:18 -0800 (PST) (envelope-from marcel) Date: Thu, 10 Jan 2002 20:39:18 -0800 From: Marcel Moolenaar To: Dag-Erling Smorgrav Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/compat/linux linux_ioctl.c Message-ID: <20020110203918.A440@dhcp01.pn.xcllnt.net> References: <200201100536.g0A5aao01807@freefall.freebsd.org> <20020110191209.A318@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.21i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Jan 11, 2002 at 04:35:30AM +0100, Dag-Erling Smorgrav wrote: > Marcel Moolenaar writes: > > It is correct WRT the translations done the opposite direction. If > > this is incorrect, the other fixes are also incorrect. Either they > > both go, or they all stay. Since you didn't object to the first > > round of fixes, I don't see how you can object to this one. > > I would have if I had noticed them, but I was too busy at the time. I > have already provided reasons why both sets of changes are incorrect. > > So please back revisions 1.77 and 1.79 out. This reintroduces the bugs reported by our users. How should those be fixed then? > > Thirdly, you did not consult me when you made the changes, as I was > > at that time the official *active* maintainer of the Linuxulator. > > Yes, I did. You reviewed my patch. Do you want a copy of my mail > archive? No, I believe you. Sorry about that. I obviously didn't pay that much attention then, because I can't even remember it... :-/ > > So, all considered, I urge you to be constructive and provide good > > explanations as to why you think it is broken and I'm sure we can > > sort it all out. In the mean time the only conclusive evidence I > > have is that it fixes a bug. I have yet to see a report that it > > breaks something else. > > 1) This numbering scheme allows interfaces to move. Correct. The current implementation numbers the eth interfaces in a relative fashion and as such will cause a name change only if their relative ordering is changed, not if their absolute position is changed. Provided that this does not happen in Linux, it's a flaw. However, I think it's a feature. With dynamic interfaces coming and going, we now know that the translation of the ethernet interfaces is unaffected most of the time. The only time the translation changes is when ethernet interfaces are inserted and removed between or prior to existing ethernet interfaces. I don't know the behaviour of Linux in that case, but consider it not a problem if it differs. In the original (ie your) implementation translation was dependent on the positional index (ie if_index) and as such could change more often than is the case now. Especially since non-ethernet interfaces could cause the translation of ethernet interfaces to change. On top of the dynamic behaviour of both implementations, there's also the semantic behaviour. With my changes the semantics are restored. Let me explain: In your implementation, interface eth0 is only a valid name if there's an ethernet interface with positional index is 0 (ie if_index = 0). In Linux, eth0 would be a valid name as long as there is at least 1 ethernet interface, independent of its positional index. The interface numbering for ethernet interfaces is therefore not positional, but relational. This is the exact behaviour we have now and as such is identical to Linux. Can you explain why the positional independence of eth interfaces is bad in your opinion? > > 2) Your commit breaks linprocfs. > This is a side issue. If the commits are reverted linprocfs works again. If the commits stay, then obviosly we think that it's correct and know that we need to fix linprocfs. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message