> I just scanned through the other code and this is _exactly_ what i had in
> mind. ccing the authors incase they are not in the list.
> Their scanning algorithm certainly needs improvement
I'm confused: You like their implementation better, though it needs
or it is wrong just as you expected?? If it is the former, could you enlighten
the discussion with what you like better about theirs? If unification ever
happens, it would be best if we took the best from both...
> > A VLAN should look just like an ethernet port. I **WANT** it to look
> > exactly like a device, so why not actually make it one?? I want to
> > use tcpdump on it,
> Modify tcpdump to do Vlan recognition (if it doesnt already).
Not so hard, but consider how much more friendly tcpdump -i vlan0005 is than
tcpdump -ben_hack_foo 5 eth0
The same holds true for every other program that interacts with (logical)
> > I want to route, firewall, bridge and do everything
> > else that a device would do.
> VLANs are primarily for switching. Fair enough that you want to route
> them. But you can certainly still do this with policy routing for example.
> The only place i see routing taking effect is in the boundary between
> VLANs and non-VLAN domains.
In applications that people are using my code for, I've heard of NO ONE
and everyone is using the interfaces for traffic management (ie routing,
firewalling, etc..) The truth is that dedicated hardware switches much
better (ie a 10/100 etherswitch). However, routing and other cool stuff
is handled better (or at least much cheaper) by Linux..
> Again from the above, you really dont need a device.
I think this is just a matter of taste at this point. I dissagree with your
assumption. I wrote VLAN because it could solve problems that I saw in
managing DSLAM (DSL) installations, and that definately needs the VLANs
to be able to firewall and route. I see no reason to limit what people
can do with VLANS, and I have little desire to patch 50 different tools
that work with interfaces to have special handling for VLANS.
> Use a table or whatever structure (radix tree etc); allow search by
> VLANid, priority etc;
I have an array of 4096 entries, one per VLAN ID. Wastes a little memory,
but gives constant time lookup. In the case of VLANs being able to be
across physical devices, there is one array per physical port.
> With these you are free to put whatever search schemes, naming conventions
> etc that you want instead of subjecting the rest of the kernel to
> something that you need for your feature.
What have I subjected the kernel too? The only part of my code that touches
the existing kernel is some in the eth.c to detect VLAN, and some other
structure changes to allow for bigger ethernet headers...
> 1) Fix pppd. Paulus is planning on a total re-write (i think you were
> copied on that email) 2) allow for multiple channels per device.
> With the new pppox architecture, you can then have a single socket
> selecting/polling for multiple circuits.
So, what about routing between circuits? Firewalling? People don't write
generalized code (ie making them all devices) for no good reason....
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)