On Sun, Oct 03, 2010 at 12:29:21AM +0100, Rui Paulo wrote:
> On 2 Oct 2010, at 21:35, Juli Mallett wrote:
> 
> > On Sat, Oct 2, 2010 at 12:07, Rui Paulo <rpa...@freebsd.org> wrote:
> >> On 2 Oct 2010, at 16:29, Robert Watson wrote:
> >>> On Thu, 30 Sep 2010, Julian Elischer wrote:
> >>>> On 9/30/10 10:49 AM, Ryan Stone wrote:
> >>>>> It's not a big thing but it would be nice to replace the m_next and 
> >>>>> m_nextpkt fields with queue.h macros.
> >>>> funny, I've never even thought of that..
> >>> 
> >>> I have, and it's a massive change touching code all over the kernel in 
> >>> vast quantities.  While in principle it's a good idea (consistently avoid 
> >>> hand-crafted linked lists), it's something I'd discourage on the basis 
> >>> that it probably won't significant reduce the kernel bug count, but will 
> >>> make it even harder for vendors with large local changes to the network 
> >>> stack to keep up.
> >> 
> >> I think it could also increase the kernel bug count. Unfortunately, we 
> >> can't do this incrementally.
> > 
> > Can't we?  What about a union, so that we can gradually convert things
> > but keep ABI and API compatibility?  I mean, as long as we use the
> > right queue.h type, anyway, it should be consistent?  STAILQ,
> > presumably.
> 
> Well, I don't have the layout of the mbuf struct offhand, but it's an idea 
> worth investigating.

what is the point of refactoring part of a struct that no new code is
touching ?

I'd like to keep this discussion on the original topics,
i.e. performance-related issues (make room to embed mtags and other
metadata such as FIB; have flexible per-socket initial padding so
we don't always waste 100+ bytes just because ipv6+ipsec is compiled
in; and so on).
Please open another thread if you want to propose cosmetics or
code refactoring or other unrelated changes

Cheers
luigi

_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to