Andrey Savochkin wrote:
>
>
> The majority of the enumerated points is just a matter of saving time for
> adjusting user-level tools. The fact that something is able provide SNMP
> statistic doesn't make it a network device, it's ridiculous!
Saving time and keeping from having to adjust (the unwashed multitude of)
user-level programs are both very important goals. If you don't support things
like SNMP the easy way, then every piece of code that must walk all devices, now
has to **also** walk every VLAN, and every other new device-like-thing that is
put into it's own little abstraction. This will quickly bloat the kernel with
stuff that may give us no extra performance.
> Bridging between VLANs is not a problem, it's the question of who calls whom.
> The logic determining VLAN id may call bridge procedures instead of vice
> versa.
I started to write my own bridging for VLAN, but it really made no sense, since
I want to also be able to bridge a VLAN across a FR-PVC, ethernet, and/or an
ATM-PVC. For
that to work in any sane way, the entities must be of the same type/behavior
(ie net_device).
> I'm not against VLANs or even against their implementation as netdevices.
> But we should agree that it's an unnatural way to do things (from kernel
> perspective, certainly), and we decide to do it this way only because we
> follow the way of least resistance.
I don't agree it's unnatural, and I'm not alone.
Lets go back to the original arguments against many devices. (Performance, if
I remember
correctly.) I believe we can satisfy the performance, and it will mean the
least amount
of new code in the kernel, (and just as importantly, in user-space.)
>
> Regards
> Andrey V.
> Savochkin
--
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
|