On Mon, 12 Jun 2000, Gleb Natapov wrote:
> jamal wrote:
> >
> > On Sat, 10 Jun 2000, Gleb Natapov wrote:
> >
> > > >
> > jamal> > Gleb, I am afraid i didnt understand you. You mean broken
> > jamal> > programs like DHCP?
> > > >
> > >
> > Gleb > No, I mean IPV6, IPX, DECnet, appletalk etc.
> >
> > This is a very strong statement that you make above. You have
> > to provide justification. The protocol type is still available on the
> > header. how is any of the above protocols broken?
>
> I _never_ said they are broken! What I've said is that you will need to
> add explicit support of VLANs in each one of these protocols (if I
> understand correct you suggestion).
>
And this is what i was refering to as you saying "broken" ;->
small miscomunication ..
If you can uniquely distinguish each protocol from looking at the header,
how can the implementation be 'broken'? Thats was my question to you.
> Answer me this question: are you going to change something in net/ipv4/
> directory in your VLAN implementation?
The main requirement seems to be to be able to 'route' -- thats what about
90% of the arguements here seem to be saying. IP rules. Who cares about
IPX? Just encapsulate it (IPX) in the ether-packet and let it be
switched/routed somewhere. some policy maps it to some VLAN. Is this not
sufficient?
if you are asking whether i'll put files in net/ipv4/ or ipv6; yes
indeed, i might but not necessarily so. I see little or zero changes to
the current common case of routing IPV4/6 packets. Why would i wanna touch
IPX code?
>
> If answer is yes, you implementation is broken IMO.
> If answer is no, I really want to see your code.
I still dont understand why you make that claim; you'll have to wait for
the code then.
Hint:
We already have a very powerful modular routing architecture; use the
route flags and dst_in/out properly and you have yourself specific routing
code which does not touch the common path *at all*
>
> > On 11 Jun 2000, Jes Sorensen wrote:
> >
> > Jes> Broad support for as much as possible is good, but limiting support
> > Jes> for the mainstream in order to improve support for something broken
> > Jes> is wrong.
> >
>
> What's limited in current implementation? We have equally good support
> for all L3 protocols. Our code even doesn't depend on L3 protocol you
> uses. This is the way it should be IMO.
>
> > Jes just hit it on the head above. Infact i am begining to believe that
> > even if you could look up the device in one lookup, always, the
> > architecture being used is _wrong_.
> >
>
> Why? It seams to me that *you* don't provide any justification to your
> claims.
> Your only complain about existent implementation was theoretical
> performance hit. What's wrong with the architecture if we have no
> performance hit?
>
> "Interface" is a nice abstraction with well defined API and good support
> in user space (ifconfig, route, ipchains, etc). You want to create new
> abstraction for VLANs, new set of user tools new API just because you
> can. To have unique API for every little thing looks like Windows to me.
>
And this is based on the simple fact by trying to make all those tools a
swiss army knife is wrong. Trying to use them as _the_ excuse is wrong.
I dislike extending the kernel to 'help' a few things at the expense of
the common path. I would rather extend the user space tools or even
re-write them. I dont claim to be a purist, but certainly i think that a
VLAN should be abstracted on a device and is therefore not a device.
Perhaps the debate we are having here can be used to re-think what the
netdevice structure should look in 2.5; as it is right now, i will totaly
and _very strongly_ disagree with you
cheers,
jamal
|