On Sun, Oct 31, 2004 at 02:50:11PM +0100, Manuel Bouyer wrote:
> On Sun, Oct 31, 2004 at 02:24:54PM +0100, cube@cubidou.net wrote:
[...]
> > But it feels so much cleaner that way.
> 
> i don't think so. ether_output() doesn't always pass the mbuf to a real
> ethernet device (in which case padding may be inappropriate), or to a device
> which may have different padding restrictions (does wifi need padding
> to ETHER_MIN_LEN ?). Also, packets may come to the adapter's if_snd queue

Devices that don't need padding won't claim the contrary.

> from other places than ether_output() (if_vlan will do it, as does if_bridge).

Yeah.  I didn't think of vlan(4), and bridge(4) would need some more attention,
too.

> > When you told me to look at tl(4)
> > code, that's what I did.  But I wasn't able to adapt it to gem(4).  Almost,
> > but it simply made the interface fail.  I know that it's very important to
> 
> Well, something is wrong then. Either the chip is buggy, or you code wasn't
> right. Anyway, it doesn't look right to add bloat to a common piece of
> code because one driver in the tree can't handle it.

Sure, my code was wrong.  My point was more like comparing a single piece of
code that is very simple and whose function is unquestionable (as the way it
performs its task) to a few chunks of codes for which you need good knowledge
of how the chip works.  With a generic way of doing it, you just tag the
driver.

> > spend as little time as possible in the network stack, but drivers are
> > already very complicated pieces of code.
> 
> The code to add padding doesn't add only a few lines of code, really.

I know that.  That doesn't make it simpler.

Quentin Garnier.