Re: IFNAMSIZ/IF_NAMESIZE change proposal

2013-09-14 Thread Marcel Moolenaar
oughts/objections highly appreciated. > >56 or 64 would be better for alignment, wouldn't it? Yes, but then we need to change Junos' definition to match FreeBSD's and we're not sure yet if that's at all possible. Hence the suggestion to use what we ha

Abstracting struct ifnet

2012-02-16 Thread Marcel Moolenaar
e-)loadable modules so as to help with migration and validation. Thoughts, feedback and suggestion are welcome, -- Marcel Moolenaar mar...@xcllnt.net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsu

Re: Abstracting struct ifnet

2012-02-17 Thread Marcel Moolenaar
a define that either old or new drivers use to indicate whether they need full visibility or whether an abstract type works. This then drives what is defined/declared and how it's defined/declared. -- Marcel Moolenaar mar...@xcllnt.net ___ freeb

Re: Abstracting struct ifnet

2012-02-17 Thread Marcel Moolenaar
I think it's a good investment and an enabler for structural ifnet rework. FYI, -- Marcel Moolenaar mar...@xcllnt.net ___ 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"

Re: Abstracting struct ifnet

2012-02-21 Thread Marcel Moolenaar
s not a goal, but we do want to be able to pre-load the network stack that we want to use and not have to worry about matching the H/W network drivers with the stack of choice. Inlines for the kernel proper and a stable KBI for modules seems to match everyone's objecti

Re: Proposal for changes to network device drivers and network stack (RFC)

2012-08-31 Thread Marcel Moolenaar
driver that can work with different network stacks. It's definitely been on our minds to make it possible to use macros for performance reasons when ABI stability is not a concern, but wanted to focus on ABI stability first. FYI, -- Marcel Moolen

Re: Proposal for changes to network device drivers and network stack (RFC)

2012-11-03 Thread Marcel Moolenaar
27;d like to see is a discussion on the functions themselves. They're the result of looking at a single driver (or maybe 2 drivers), and as such may not be perfectly generic or logical. As said before: we'd like to focus on an ABI-stable interface, but a one based on macros should also be poss

Re: netstat output on a recent head

2015-02-25 Thread Marcel Moolenaar
> On Feb 25, 2015, at 8:42 AM, Marcel Moolenaar wrote: > > >> On Feb 24, 2015, at 3:00 PM, Navdeep Parhar wrote: >> >> I see a lot of literal "%s" in netstat's output on head. This on a >> freshly built system from today.. >> >>

Re: netstat output on a recent head

2015-02-25 Thread Marcel Moolenaar
(except not humanized). I’ll fix it today. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail

Re: HEAD UP: non-MPSAFE network drivers to be disabled

2008-05-27 Thread Marcel Moolenaar
been designed to allow different kernel interfaces. It currently supports TTYs and keyboards. It should not be too hard to have it hook into netgraph. FYI, -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebs

Re: HEAD UP: non-MPSAFE network drivers to be disabled

2008-05-27 Thread Marcel Moolenaar
On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people connected to the internet via dial up lines in places off the beaten track, and

Re: HEAD UP: non-MPSAFE network drivers to be disabled

2008-05-27 Thread Marcel Moolenaar
On May 27, 2008, at 1:49 PM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 10:50 AM, Julian Elischer wrote: Marcel Moolenaar wrote: On May 27, 2008, at 1:12 AM, Julian Elischer wrote: judging by the bug reports when things get broken there are still a lot of people

Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64

2005-05-24 Thread Marcel Moolenaar
Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-ia64->freebsd-net Responsible-Changed-By: marcel Responsible-Changed-When: Wed May 25 02:27:47 GMT 2005 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=81284 __

Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64

2005-05-24 Thread Marcel Moolenaar
The following reply was made to PR ia64/81284; it has been noted by GNATS. From: Marcel Moolenaar <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64 Date: Tue, 24 May 2005 19:45:37 -0700 The problem is not specific to ia64.

Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64

2005-06-13 Thread Marcel Moolenaar
Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: marcel Responsible-Changed-When: Mon Jun 13 21:22:54 GMT 2005 Responsible-Changed-Why: Move to a more pf-focussed responsible party. http://www.freebsd.org/cgi/query-pr.

Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64

2005-06-15 Thread Marcel Moolenaar
On Jun 15, 2005, at 1:42 PM, Daniel Hartmeier wrote: On Mon, Jun 13, 2005 at 09:23:50PM +, Marcel Moolenaar wrote: Synopsis: Unaligned Reference with pf on 5.4/IA64 Responsible-Changed-From-To: freebsd-net->freebsd-pf Responsible-Changed-By: marcel Responsible-Changed-When: Mon Jun 13

Re: ia64/81284: Unaligned Reference with pf on 5.4/IA64

2005-06-15 Thread Marcel Moolenaar
On Jun 15, 2005, at 3:34 PM, Daniel Hartmeier wrote: On Wed, Jun 15, 2005 at 02:23:24PM -0700, Marcel Moolenaar wrote: That entirely depends. If a struct ip pointer is constructed without any form of casting, then one can assume that alignment is guaranteed. The compiler guarantees to do so

Re: Byte counters reset at ~4GB

2004-03-15 Thread Marcel Moolenaar
if people make the statement that widening counters is not an option because it slows down some platforms, I must be missing the reason for it to be an all or none kind of issue. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAI