On Sun, Oct 31, 2004 at 03:08:36PM +0100, cube@cubidou.net wrote:
> 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.

But if they need padding to a different lenght ?

> > > 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.

Which just hides the problem: the driver is buggy. The author of the driver
obviously knows how the chip works, adding the code to do the padding
isn't that difficult for him.
Now, there is the case where a driver needs to be fixed by someone who didn't
write it. Adding a hack in the upper layers for this looks wrong.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--