On 17/10/16 18:40, John Baldwin wrote:
I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can either
read() or mmap() to access the table would be very convenient and let you
keep the bits to parse the table in
On 17/10/16 21:23, Bruce Simpson wrote:
On 17/10/16 18:40, John Baldwin wrote:
I'm a bit hesitant to do all the type parsing in the kernel vs userland.
However, I think having smbios(4) export a /dev/smbios that you can
either
read() or mmap() to access the table would be very convenien
On 04/10/10 13:05, Bruce M Simpson wrote:
Log:
Fix a few issues related to the legacy 4.4 BSD multicast APIs.
IPv4 addresses can and do change during normal operation. Testing by
pfSense developers exposed an issue where OpenOSPFD was using the IPv4
address to leave the OSPF link-sco
On 04/16/10 09:23, Alexander Leidinger wrote:
IP multicast group membership is always scoped to physical links [1].
The 4.4BSD API originally used the "primary IP address" to identify
each link. Unfortunately this is not a persistent identifier,
especially so in the use-case which had problem
John,
That's news to me. I'm pretty sure I tested this code with and without
INET6 when I checked it in, given I was mostly testing without INET6.
This was a very long time ago, so I was surprised to receive your
message. Could something have changed to have broken mtest?
thanks
BMS
John Baldwi
On 03/04/17 15:12, Julian Elischer wrote:
> On 3/4/17 11:07 am, Andrey V. Elsukov wrote:
>> Author: ae
>> Date: Mon Apr 3 03:07:48 2017
>> New Revision: 316435
>> URL: https://svnweb.freebsd.org/changeset/base/316435
>
> it was always my intention to hook netgraph modules into ipfw in this way
I
This is a really good thing to have in. Thanks, Steven and others, for
optimizing for this big case.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr.
Hopefully, with packet mode DSL, none of this should be needed again.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
On 27/04/17 18:44, Bruce Simpson wrote:
> Hopefully, with packet mode DSL, none of this should be needed again.
>
JFYI I'm referring to ye olde Packet Transfer Mode (PTM) DSL, TR-009...
which dispenses with the need for ATM framing on DSL circuits.
Some US ISPs have been observed do
wrote:
On Sun, Aug 21, 2016 at 12:25:46AM +0100, Bruce Simpson wrote:
Whilst I agree with your concerns about multipoint, I support the
motivation behind Ryan's original change: optimize the common case.
Oh, common case...
I am have pmc profiling for TCP output and see on this SVG picture
On 03/10/16 20:02, Eric van Gyzen wrote:
Author: vangyzen
Date: Mon Oct 3 19:02:22 2016
New Revision: 306652
URL: https://svnweb.freebsd.org/changeset/base/306652
Log:
Update arp(4) to document the net.link.ether.inet.garp_rexmit_count sysctl.
Meh, acronym collision.
It's probably obvious
On 03/10/16 20:22, Eric van Gyzen wrote:
The collision is unfortunate, but I agree that the context should be enough.
Agreed -- other technical writers have also used this version of the
GARP acronym in doco.
However, that GARP -- 802.1ak -- is due to be replaced with MRP.
The "Mental-map
On 19/06/2014 21:05, Hans Petter Selasky wrote:
Are there any existing C++ kernel modules, or in ports? Even though,
C++ kernel modules can be compiled with C files aswell, containing the
sysctls.
The Click Modular Router is implemented in C++, I have occasionally
pitched in with keeping it
On 19/06/2014 06:28, Hans Petter Selasky wrote:
Author: hselasky
Date: Thu Jun 19 05:28:42 2014
New Revision: 267633
URL: http://svnweb.freebsd.org/changeset/base/267633
Log:
Initialize sysctl OID structure by record.
So, has there been any traction on rethinking / backing out this change
On 12/07/2014 12:34, Bruce Evans wrote:
This joke is bad. The C++ version is worse in every way.
I concur with everything you have said in your message. Moral of story:
it is very, very easy to introduce bloat using C++, and using a higher
level language does not automatically lead to bette
On 12/07/2014 16:31, Ian Lepore wrote:
It is in no way established that any kind of "mess" exists.
On the contrary, the metrics and analysis which bde@ has presented seem
pretty clear to me.
All we have
is some people who appear to hate C++ expressing their opinions about
how they hate C++
On 21/07/2014 16:22, Pedro F. Giffuni wrote:
]
Log:
Add re-entrant versions of the hash functions based on the GNU api.
What, if anything, can be done about qsort_r() API incompatibility?
___
svn-src-head@freebsd.org mailing list
http://lists.fr
On 03/08/2014 15:27, Warner Losh wrote:
What, if anything, can be done about qsort_r() API incompatibility?
qsort_r is non-standard and we did it first, plus we will want to stay
compatible with Apple :).
I guess we could do some ugly parameter swapping in the case where _GNU_SOURCE
is defined
On 06/08/2014 01:36, Marcel Moolenaar wrote:
Log:
Optionally include the install command as found on Juniper products
like EX and SRX. The install command uses pkgfs to extract a kernel,
zero or more modules and a root file system from the specified package
and boots the kernel. The n
On Sun, 19 Oct 2014, at 13:02, Andriy Gapon wrote:
> I think that on platforms where an optimized version of fls() is
> available that
> would work faster than this cool piece of bit magic.
This is a common enough idiom that perhaps a macro should be added:
sys/param.h:
#define roundup(x, y)
Hello,
This is a really inconvenient time for me (I am up against a deadline)
but I am not 100% comfortable with this change.
On Thu, 30 Oct 2014, at 10:59, Andrey V. Elsukov wrote:
> Log:
> Fix mbuf leak in IPv6 multicast code.
> When multicast capable interface goes away, it leaves multicas
On Mon, 3 Nov 2014, at 08:21, Julian Elischer wrote:
> I'm open to being persuaded but I think we need to have a discussion
> about stack usage. We used to say that anything greater that, say
> 64 bytes should probably be allocated.
I have to admit the level of stack usage in my current $DAYJOB pr
On 20/11/2014 21:10, Craig Rodrigues wrote:
Converting these (and other) utilities to use libxo will make it a lot
easier to write analysis tools like eagleeye.
It'll also make it easier for anyone doing systems-level study. Right
now I have a bunch of shell scripts which hoover up command o
Mark,
On 06/05/2014 19:07, Mark Johnston wrote:
Log:
Add a postinit debugger hook to rtld. This will be used by dtrace(1) to halt
the victim process before its entry point is called, at which point probes
and DOF data are registered with the kernel.
I recently had a situation where I
On 07/05/2014 18:31, Mark Johnston wrote:
The Linuxulator makes use of Linux's loader rather than rtld; this was
the source of the problem fixed in r254018, for example. Static
binaries are not invoked through rtld either, so I don't think this
change would have helped anyway.
I'm aware that
On 22/12/2014 21:26, Dmitry Morozovsky wrote:
Log:
Add VAMI (VMware Appliance Management Interface) port.
This is vApp / VMware Studio related; any plans to get FreeBSD guests
working?
___
svn-src-head@freebsd.org mailing list
http://lists.f
On 12/01/2015 08:33, Hiren Panchasara wrote:
Log:
DCTCP (Data Center TCP) implementation.
Right On Commander!
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn
Gleb,
Correct me if I'm wrong -- but doesn't this set of changes remove the
ability for the user to see the stack-wide membership filters on each
link? The implementation required KVM as it must inspect the SSM filters
themselves to obtain this information.
On 19/02/2015 22:42, Gleb Smirnoff
On 21/02/2015 00:50, Gleb Smirnoff wrote:
May be you refer to code that was always under #if 0, disabled due to
difficulty to go through RB-trees via kvm(3)?
My bad - yes - this code was unfinished as of SVN rev 192923, it seems I
ran into problems with RB-tree walks through KREAD().
To
On Thu, 18 Sep 2014, at 07:04, Kevin Lo wrote:
> Sorry, I overlooked that. Marcelo has a patch with 802.1p tagging
> support,
> I thought the patch was committed.
I agree the comment change should be reverted. I changed if_ethersubr.c
many years ago to decode 802.1p tags into the mbuf packet head
On 31/07/16 07:24, Adrian Chadd wrote:
[gpioled] add support for inverting the LED polarity.
No, this isn't a star trek science joke - sometimes LEDs are wired
up to be active low, so this is needed.
Actually, just about every bit of hardware I have interacted with on
that level recently
"Yes, I know it's not a typewriter. Why is this command not working?"
Perhaps this errno code should be aliased... and strerror() massaged in
places... assuming we strictly follow the POSIX.
___
svn-src-head@freebsd.org mailing list
https://lists.free
On 01/08/16 17:49, Ian Lepore wrote:
...
In addition, the strerror() output for ENOTTY says nothing about a
typewriter, the text is "Inappropriate ioctl for device."
If that semantic gap has already been plugged, ignore my message.
___
svn-src-head@f
DES,
I believe this breaks logging into various embedded network devices,
unfortunately. E.g. the Netonix WISP Switch, which uses an embedded
Linux variant with dropbear 0.51. It is expecting to use DSA not RSA for
the key exchange.g
Is there a way to revert this change, at least on an ongoi
On 07/08/16 11:58, Bruce Simpson wrote:
Is there a way to revert this change, at least on an ongoing operational
basis (e.g. configuration file) for those of us who use FreeBSD to
connect directly to such devices?
I was able to override this (somewhat unilateral, to my mind)
deprecation of
On 07/08/16 12:43, Oliver Pinter wrote:
I was able to override this (somewhat unilateral, to my mind)
deprecation of the DH key exchange by using this option:
-oKexAlgorithms=+diffie-hellman-group1-sha1
You can add this option to /etc/ssh/ssh.conf or ~/.ssh/config too.
Can this at least be ad
On 07/08/16 15:40, Warner Losh wrote:
That’s a cop-out answer. We, as a project, need to articulate to our
users, whom we care about, why this rather obnoxious hit to usability
was taken. The answer must be more complete than “We just disabled
it because upstream disabled it for reasons we’re too
On 07/08/16 18:34, Andrey Chernov wrote:
Alcatel-Lucent OmniSwitch 6800 login broken (pfSense 2.3.2 which
accepted the upstream change, workaround no-go)
[2.3.2-RELEASE][r...@gw.lab]/root: ssh -l admin
-oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.1.XXX
Fssh_ssh_dispatch_run_fatal: Connect
On 07/08/16 20:23, Peter Jeremy wrote:
On 08/07/16 05:48, Adrian Chadd wrote:
+#defineETHER_IS_BROADCAST(addr) \
...
IMHO, Adrian's code is clearer and micro-optimisations like this belong
in the complier, not the code.
*cough* *cough* 2007 wants its patch back.
https://people.freeb
On 08/08/16 11:36, Dag-Erling Smørgrav wrote:
Bruce Simpson writes:
Alcatel-Lucent OmniSwitch 6800 login broken
...
This patch did not remove weak DH groups. That happened in 7.0p1 back
in January.
So my reading of this is that PuTTy may be the best workaround for
end-users who have to
This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).
On 18/08/16 23:59, Ryan Stone wrote:
Author: rstone
Date: Thu Aug 18
On 20/08/16 12:33, Bruce Simpson wrote:
This potentially breaks reception of IPv4 broadcasts where FreeBSD is
the endpoint at the end of a P2P interface, or other forms of links,
where there is no guarantee that the link layer will set M_BCAST (or
indeed M_MCAST).
I appreciate it probably
On 20/08/16 15:52, Ryan Stone wrote:
It is perfectly legal for broadcast packets to be addressed to the
end of a P2P or non-Ethernet link, which may not set M_BCAST or
M_MCAST. The classic example is ATM (Non-Broadcast, Multiple Access
(NBMA)) but the situation may be readily obse
On 20/08/16 16:27, Ryan Stone wrote:
Can you send a broadcast packet through an L3 tunnel? I thought that a
L2 tunnel was required.
Yes. This is perfectly legal and necessary for forwarding of IPv4
broadcasts to work. (it is Internet Protocol after all, not
Infernal-ethernet-extension Protoc
On 20/08/16 16:42, Bruce Simpson wrote:
On 20/08/16 16:27, Ryan Stone wrote:
Can you send a broadcast packet through an L3 tunnel? I thought that a
L2 tunnel was required.
Yes. This is perfectly legal and necessary for forwarding of IPv4
broadcasts to work. (it is Internet Protocol after all
On 20/08/16 17:27, Bruce Simpson wrote:
Alternatively, the L2 destination MAC may be rewritten for that specific
address, to avoid the destination being interpreted by routers in the
Metro Ethernet core.
s/routers/switches/ -- in some views of the world, they are the same :)
PBB is also known
On 20/08/16 17:36, Ryan Stone wrote:
+ adrian@, who prompted me to look at UDP in the first place
I'm really not sure what my next step should be. I'm willing to revert
r304436, but I really don't want to revert r304437 because we've seen
crashes in the real world due to the missing locking. U
On 20/08/16 17:49, Bruce Simpson wrote:
- Providing a mechanism for ip_input() to signal to udp_input() that the
packet was addressed to an L3 broadcast address would require
rototilling the pr_input interface, and I'd have to carefully ensure
that if anything might interpose itself betwee
On 20/08/16 18:30, Slawa Olhovchenkov wrote:
Anyway, don't should relay on the L2 information, you can recive L3
unicast addressed packets (with alien dst IP address) in L2 broadcas
packet.
That is exactly what the egress routers in chapter 6 of my PhD do, but
in a very controlled way -- by se
On 20/08/16 19:09, Adrian Chadd wrote:
On 20 August 2016 at 11:02, Ryan Stone wrote:
On Sat, Aug 20, 2016 at 1:30 PM, Slawa Olhovchenkov wrote:
For host enought have [hidden] alias with broadcsts bits.
Anyway, don't should relay on the L2 information, you can recive L3
unicast addressed packe
On 20/08/16 19:57, Ryan Stone wrote:
On Sat, Aug 20, 2016 at 2:45 PM, Slawa Olhovchenkov mailto:s...@zxy.spb.ru>> wrote:
You also can recive this on ethernet too, IMHO, in case of /32.
Receiving L3 broadcst in L2 unicast is legitime (IMHO) and we must be
relaxed on this.
There is
On 20/08/16 21:05, Bruce Simpson wrote:
Unless I am missing something crucial here? As far as I can tell,
arpresolve() unconditionally resolves L2 next-hop to the value of
ifp->if_broadcastaddr. And that is always set to 'etherbroadcastaddr' by
default for Ethernet ifnets: FF:F
On 20/08/16 21:41, Slawa Olhovchenkov wrote:
On Sat, Aug 20, 2016 at 09:34:06PM +0100, Bruce Simpson wrote:
So, Ryan -- your original reading of how in_broadcast() behaves is
correct, modulo the all-ones bypassing it.
What purpose to analyse L2 header?
I was just checking for possible edge
On 20/08/16 22:17, Bruce Simpson wrote:
However, we still have to keep the FreeBSD-on-Ethernet ship sailing
smoothly. The intent of the original input path change is clearly for
performance, but perhaps slipping the M_BCAST tag in the stack is the
right way forward.
I would also suggest: we add
On 20/08/16 23:05, Slawa Olhovchenkov wrote:
I am think this substitution is very bad idea (by design).
Also, on transmit side this is must be irrelevant on received L2
header (and this in many cases this is will be L2 unicast packet). For
other cases packet will be created on host and don't have
On 21/08/16 00:25, Bruce Simpson wrote:
[Use a predicted branch in favour of Ethernet to optimize common case
comments snipped]
...we ensure that M_BCAST is cleared at all times before possible
re-entry, and use a separate M_BCASTL3 bit. Let the ethernet protocols
decide themselves if re
On 21/08/16 00:25, Bruce Simpson wrote:
On 20/08/16 23:05, Slawa Olhovchenkov wrote:
In router case receiving broadcast packet in any way need additional
check for dst IP address (host part is all zero or all one? what about
handling this broadcast type (RFC talk about conroling variation of
On 21/08/16 00:47, Adrian Chadd wrote:
[snip]
Just for everyone else on the list, would you mind distilling the
original versus now-from-ryan meaning of M_BCAST and M_MCAST ? And how
they're supposed to be used?
(With my best Liam Neeson 'Dad' voice from Fallout 3)
They stay as-is, but IP is
Ian,
To paraphrase what I said privately to the various dramatis personae in
January:
Changes like this need to be reviewed before they go in. As timing is
central to the entire OS, change review has to be meticulous, on par
with the virtual memory management. We have a VM tsar; we do not ha
Right On Commander!
Now here is hoping the random-write issues with OpenZFS are solved...
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebs
It's good to see this patch being aired out and going into mainline
finally. However, what about IP DS mapping and/or application layer
mapping? We may not need full-on MPLS style classification, unless we
plan to take that code later on. (I'm looking at you, NetBSD.)
__
On 06/06/16 13:48, Marcelo Araujo wrote:
We have on ipfw(8) support for DSCP[1], I'm not sure if this is the
same/similar case you mentioned for IP DS(DiffServices?).
Background: I introduced the code to process VLAN 0 tags inline as
normal traffic several years ago for 802.1p.
I'm referring
All,
The enhancements to the Linux runtime are probably of more interest to
folk porting server applications; I am particularly happy to see
recvmmsg() and sendmmsg() go in.
It might also be wise to emulate the getrandom() API, even if this is
only in terms of wrapping the relevant sysctl fo
On 07/06/2015 18:06, Garrett Cooper wrote:
This commit's explicitly polluting the ficl interpreter with code from x86 on
all platforms.
+1
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscrib
Marcel,
On Mon, 8 Jun 2015, at 04:23, Marcel Moolenaar wrote:
> Log:
> Add busdma_mem_alloc & busdma_mem_free.
Nice! Is there a man page or documentation for this anywhere?
Also: is it feasible to extend to build/attach to a VirtIO function?
(May be PCI, not MMIO).
cheers
Bruce
--
BMS (sent
Marcel,
(Cc: Will as he's expressed interest in this)
No problem... still tied up here...
On Mon, 8 Jun 2015, at 06:10, Marcel Moolenaar wrote:
> > On Jun 7, 2015, at 9:52 PM, Bruce Simpson wrote:
> > Nice! Is there a man page or documentation for this anywhere?
>
> N
On Mon, 8 Jun 2015, at 06:10, Marcel Moolenaar wrote:
> > Also: is it feasible to extend to build/attach to a VirtIO function?
> > (May be PCI, not MMIO).
>
> I think so. If there’s an easy environment for me to play
> with, I can take a look. I think qemu would do right?
I can't speak to the MM
On 13/06/2015 16:38, David Chisnall wrote:
On 13 Jun 2015, at 11:17, Ian Lepore wrote:
If you would have told me a year ago that you had a simple scheme that
could make 30 years of experience maintaining code for unix-like systems
completely worthless I would have been skeptical, but it seems
On 14/06/2015 11:00, Slawa Olhovchenkov wrote:
On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote:
The people I talk to use scripting languages like Python or Ruby,
and devops frameworks like Ansible, Saltstack, Puppet, and Chef.
They may do some quick prototyping and UI work with
On 14/06/2015 18:10, Steve Kargl wrote:
On Sun, Jun 14, 2015 at 11:22:03AM +0100, Bruce Simpson wrote:
But I have yet to see a coherent argument here -- size(1) numbers, RSS
figures etc. -- about how it allegedly adds bloat. Most of what I've
seen so far is POLA, NIH resistance, and
On 15/06/2015 19:49, Warner Losh wrote:
I’ve yet to see why ls —libxo is better than a separate program articulated
anywhere other than "libxo all the things.” Having a clear statement about
why it is needed, why changing it vs having a separate program, etc would
help. But is seems overly gratui
On 05/07/15 20:53, Oliver Pinter wrote:
Log:
Ensure all the required files get built when you include the IPSEC
option.
+1. IETF position these days is that IPSEC should be a "standard feature".
Key management is a separate issue, and support for newer ciphers like
ChaCha20 (see NaCL by D
All,
On 01/03/16 10:57, Svatopluk Kraus wrote:
Author: skra Date: Tue Mar 1 10:57:29 2016 New Revision: 296261 URL:
https://svnweb.freebsd.org/changeset/base/296261
Log: Mark other parts of interrupt framework as INTR_SOLO option
specific.
IMHO... The general rationalisation of the FreeBSD k
On 14/03/16 07:14, Wojciech Macek wrote:
Log:
Add support for USB3.0 on Armada38x
Very cool. Do you know if any Armada (or other embedded) XHCI
implementations like this support XHCI Debug Port 1.0 ?
___
svn-src-head@freebsd.org mailing list
htt
On 01/08/13 17:55, Rui Paulo wrote:
On 1 Aug 2013, at 09:27, Alexander V. Chernikov wrote:
Because thay aren't really interfaces. All they need is BPF.
There is a cleaner approach described here:
http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034031.html
I don't agree with this
On 24/07/13 05:24, Marcel Moolenaar wrote:
Log:
Decouple the UUID generator from network interfaces by having MAC
addresses added to the UUID generator using uuid_ether_add(). The
UUID generator keeps an arbitrary number of MAC addresses, under
the assumption that they are rarely remo
On 07/08/13 13:05, Gleb Smirnoff wrote:
Yes, lack of good management mechanism creates a temptation to create
a foo(4) interface for any new FOO protocol, with its own if_ioctl method
that will provide a clean entry into its management. I suspect that was one
of the reasons to implement carp(4) a
Hey Jason,
Have you looked at ? It is used by pf and the multicast code.
cheers
Bruce
On 02/28/10 22:57, Jason Evans wrote:
Author: jasone
Date: Sun Feb 28 22:57:13 2010
New Revision: 204493
URL: http://svn.freebsd.org/changeset/base/204493
Log:
Rewrite red-black trees to do lazy balance
On 03/08/10 15:01, Nathan Whitehorn wrote:
Log:
Enable tmpfs unconditionally on all platforms. No one I spoke to could
remember why it was x86 only, and it works just as well on at least powerpc
as on x86.
Thanks, What with 7.3 coming up and all, this would make for a nice MFC. :-)
Any objections to making AF_NETLINK Foundation proposal public?
Might help FreeBSD get out of the niche a bit more; energy quantum wells
are never great.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
On 03/13/10 13:53, Robert N. M. Watson wrote:
On Mar 13, 2010, at 1:50 PM, Randall Stewart wrote:
I could refactor that this way if you want... it would mean a few more de-ref's
and
looking to see if its a v4 or v6 packet and then doing the proper offset...
This is the sort of thing
81 matches
Mail list logo
