On Sun, Oct 31, 2004 at 07:51:37AM -0500, Greg Troxel wrote:
>   Now, I don't know if saving these extra CPU cycles is really important or
>   not. When I did the work on this padding problem, it was decided that the
>   best place to do this was in the drivers themselves, because it was the most
>   efficient.
> 
> So perhaps if_ethersubr.c could have a 
> 
> /*
>  * Given an mbuf and a length, return an mbuf that has all the
>  * original data, and that is at least length.  Any added data will be
>  * zero.  Returns NULL and frees the mbuf if allocation was needed and
>  * fails.
>  */
> struct mbuf *
> mbuf_ensure_length(struct mbuf *m, int length)
> {
> }
> 
> to be used by drivers that don't want to do something more
> complicated; this would get the benefit of abstraction in that case
> while not precluding efficiency for the cases you mention, and with

I can't see other cases than the ones I mentioned. If a driver cares to
call this mbuf_ensure_length(), it could as well pad the packet using
what's appropriate for this chip

> any luck decrease the odds that we'd leak kernel data or do dma from
> non-existent memory above the top mbuf  - I actually had a FreeBSD
> machine crash once in if_wl.c due to this.

It's a bug in the driver. ethernet driver should be able to deal with
mbufs shorter than the ethernet min len.

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