I was not responding to this for a while because Poul quite correctly
thwapped me for not being on point, but I couldn't let this go.
> The point should be clear, using proper string identifiers would
> make your program easier to understand and modify, as well as
> allow for greater extensibilit
On Wed, Mar 03, 1999 at 12:16:20PM -0800, Matthew Jacob wrote:
> Now I'll stir the other pot and say that performance isn't the issue- the
> issue is that there's nothing that says that strings and identifiers are
> always easier to use and/or understand than numbers.
Matthew Jacob wrote:
>
> >
> > Amen, brother! Get it said! People who claim that strings are
> > "too slow" would benefit greatly from spending a few days with the
> > profiler.
>
> Now I'll stir the other pot and say that performance isn't the issue- the
> issue is that there's nothing that sa
Matthew Jacob writes:
> > Amen, brother! Get it said! People who claim that strings are
> > "too slow" would benefit greatly from spending a few days with the
> > profiler.
>
> Now I'll stir the other pot and say that performance isn't the issue- the
> issue is that there's nothing that says tha
On Wed, 3 Mar 1999, John Polstra wrote:
> In article <18961.920316...@critter.freebsd.dk>,
> Poul-Henning Kamp wrote:
> >
> >
> > For some reason, some people around our camp-fire, have a hard time
> > understanding that compiletime enumeration of potential options
> > is a concept that died
> > Now I'll stir the other pot and say that performance isn't the
> > issue- the issue is that there's nothing that says that strings and
> > identifiers are always easier to use and/or understand than numbers.
> They are a lot more extensible, though. With strings, you generally
> have to modif
Matthew Jacob wrote:
> Now I'll stir the other pot and say that performance isn't the
> issue- the issue is that there's nothing that says that strings and
> identifiers are always easier to use and/or understand than numbers.
They are a lot more extensible, though. With strings, you generally
h
In message , Matthew Jacob w
rites:
>>
>> Amen, brother! Get it said! People who claim that strings are
>> "too slow" would benefit greatly from spending a few days with the
>> profiler.
>
>Now I'll stir the other pot and say that performance isn't the issue- the
>issue is that there's nothing t
>
> Amen, brother! Get it said! People who claim that strings are
> "too slow" would benefit greatly from spending a few days with the
> profiler.
Now I'll stir the other pot and say that performance isn't the issue- the
issue is that there's nothing that says that strings and identifiers are
a
In article <18961.920316...@critter.freebsd.dk>,
Poul-Henning Kamp wrote:
>
> It should have been done with a simple ascii string instead. The
> drivers are much better at chewing on it than the "generic" code,
> it would be simpler to understand, simpler to implement, you wouldn't
> need to re
On Mon, 1 Mar 1999, Poul-Henning Kamp wrote:
> Yes, but considering the low age of the interface, the fact that it
> was made so narrow-scope is a disgrace.
True. It appears that it was a fairly focused solution for a very
specific case of problem. (as you said)
> Try to implement a E1 line wit
Of all the gin joints in all the towns in all the world, Garrett Wollman
had to walk into mine and say:
> < said:
>
> > Interested persons should review the diffs and pipe up if they have
> > some passionate argument argument against them.
>
> Patches look mostly fine.
Okay. I noticed one oth
In message , "Matthe
w N. Dodd" writes:
>On Mon, 1 Mar 1999, Poul-Henning Kamp wrote:
>>
>> And some new PCI devices doesn't either because if_media is hopelessly
>> narrowtrack for real world devices :-(
>
>As much as if_media sucks, it does have the ability to be extended in a
>fariety of useful
On Mon, 1 Mar 1999, Poul-Henning Kamp wrote:
> In message <199903011751.kaa03...@mt.sri.com>, Nate Williams writes:
> >> > ! * If the LINK1 flag is set, it means the underlying
> >> > interface
> >> > ! * can do VLAN tag insertion itself and doesn't require
> >> >
In message <199903011751.kaa03...@mt.sri.com>, Nate Williams writes:
>> > ! * If the LINK1 flag is set, it means the underlying interface
>> > ! * can do VLAN tag insertion itself and doesn't require us to
>> > ! * create a special header for it. In this case, we just
> > !* If the LINK1 flag is set, it means the underlying interface
> > !* can do VLAN tag insertion itself and doesn't require us to
> > !* create a special header for it. In this case, we just pass
>
> Are we certain that all drivers are now doing if_media and
< said:
> Interested persons should review the diffs and pipe up if they have
> some passionate argument argument against them.
Patches look mostly fine.
> Also, I should point out that while if_vlan provides the necessary
> kernel hackery to implement VLANs, there isn't any user space utility
>
While trying to figure out a way to support VLANs with the Alteon
gigabit NIC, I stumled across /sys/net/if_vlan.c. It seems simple
enough: pseudo IP interfaces are created which interacts with an
underlying physical interface and fixes up frame headers to deal
with VLAN tag encapsulation and extra
18 matches
Mail list logo
