Hi again Chris! Just a few quick comments before I run off to work...
On tor, 2009-03-19 at 23:21 -0400, Chris Dukes wrote: > On Thu, Mar 19, 2009 at 10:06:37PM +0100, Andreas Henriksson wrote: > > If we can truely replace vconfig, I think this option should not exist. > > We should simply Conflict with vlan package to make sure people remove > > it. I guess we're still missing the macvlan pieces though? > > The vlan bug indicated compatibility issues with sarge. I do not know if > they apply to lenny as well. Plus, the vlan package requires iproute2. > At this point in time the only thing I know about macvlan is what I learned > from from 'ip link add link type macvlan help' and a quick skim of the > comments at the start of the driver source code. >From some quick googling it seems to be some kind of "fake many interfaces on the same physical link by assigning several mac addresses" ... nothing the same as vlan with id's and stuff. > And what I do know is that at this point in time 'ip' does not appear to > support creating macvlan interfaces with arbitrary names, they > need to be renamed after the fact. The Kconfig help text for macvlan (first hit on goole for macvlan) has an example that seems to indicate that setting the name when adding the link is supported. I've also quickly looked at the ip/iplink.c source (iplink_modify()) and that seems like the "name" option should be supported for all new link types (if the kernel supports it) since things are being passed more or less straight into the kernel. I believe "ip link add link dev XXX name YYY type ZZZ" should generally work. Anyway, the macvlan module doesn't even seem to be shipped with debian kernels so we should probably not focus on it since it's not a supported configuration. Anyone who wants it can add support for it. > There would also need to be proper handling of > 1) veth > 2) dummy > 3) ifb > Plus tunctl functionality should probably be rolled into 'ip' as well. Thanks for summing these up... [..] > > On the other hand, Why don't we implement this straight in ifupdown? > > The ifupdown 0.7 package in experimental has been ported over to use > > iproute instead of net-tools (ifconfig). I'm willing to help out how to > > update ifupdown since I've done some work on it in the past.... It would > > be much nicer with "native" vlan support in ifupdown then using external > > scripts IMHO, what do you think? > > I would have to see what ifupdown is doing underneath the covers. Beware! Here be dragons! ;) It's using a "literate programming language". The (shipped) source files are all generated from ifupdown.nw with the "noweb" program. > I pretty much have two goals. > 1) Get things configured with the fewest forks possible. > 2) Keep underlying algorhythms transparent so it's easier to figure out > aren't working right. > > Then again, after looking through the inet.defn file for the current > version in 'sid', it looks like it could use a good mopping :-). Please look at the experimental (0.7) package instead! The *.defn part has changed much there.... all iproute. Also, beware that you should not modify the *.defn files since they are as I mentioned before generated files. (Might be easier to read them then wading through all the stuff in ifupdown.nw when you just want to look at what commands gets executed.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
