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
Hopefully, with packet mode DSL, none of this should be needed again.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
This is a really good thing to have in. Thanks, Steven and others, for
optimizing for this big case.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@
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
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 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 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 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
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 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
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: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 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 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 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 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 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 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 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 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 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: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 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 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 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 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
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 14/08/16 05:35, Glen Barber wrote:
Author: gjb
Date: Sun Aug 14 04:35:04 2016
New Revision: 304070
URL: https://svnweb.freebsd.org/changeset/base/304070
Log:
Do not include C function changes by default in svn commit
email.
Please back out -- this makes the diff output much less useful.
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
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 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 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 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 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
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 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-all@fr
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-all@freebsd.org mailing list
https://lists.freeb
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
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.)
__
Right On Commander!
Now here is hoping the random-write issues with OpenZFS are solved...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.o
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-all@freebsd.org mailing list
http
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
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
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
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 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 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 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 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
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
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
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe,
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 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
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 12/01/2015 08:33, Hiren Panchasara wrote:
Log:
DCTCP (Data Center TCP) implementation.
Right On Commander!
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-s
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-all@freebsd.org mailing list
http://lists.fr
rtadvd(8) has a few other bugs apart from this. It could probably stand
to use CLOCK_MONOTONIC where that's possible, also...
--
BMS (sent via webmail)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To uns
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
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
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 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)
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 Thu, 4 Sep 2014, at 10:05, Jean-Sébastien Pédron wrote:
> Unfortunately, reading from the video memory is very expensive. The new
> version of vt_vga never reads from the video memory. Instead, it uses
> the console history to know what those 8 pixels should look like and
> write one byte which
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 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 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-all@freebsd.org mailing list
http://lists.fre
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 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
Daichi-san,
Just FYI: I could not get IIC to work with the glxiic(4) driver in tree
on my PC Engines ALIX 6D2, although this driver [1] appears to work.
Tested with a Dallas Semiconductor DS1337 RTC module some time ago.
Bruce
[1] http://www.phisch.org/website/glxiic/
___
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 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 16/05/2014 08:46, Doug Ambrisko wrote:
mrsas(4) attaches disks to the CAM layer so it depends on CAM and devices
show up as /dev/daX. mfiutil(8) does not work with mrsas.
This is a big improvement. When using ZFS with mfi(4), mfiutil(8) can be
used to create an "un-RAID" configuratio
On 14/05/2014 16:57, Ian Lepore wrote:
TI Programmable Realtime Unit Subsystem.
OK, so PRUSS is one vowel change away from the name of a killer android
in a work by Philip K. Dick.
Are there applications for this driver? I'm just curious having skimmed
this document [1]:
"The PRU subsystem
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
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/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
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 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
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
Right On Commander!
On 04/16/10 16:43, Fabien Thomas wrote:
Log:
MFC r206089, r206684:
- Support for uncore counting events: one fixed PMC with the uncore
domain clock, 8 programmable PMC.
- Westmere based CPU (Xeon 5600, Corei7 980X) support.
- New man pages with events list
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
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 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
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To
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. :-)
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 07/02/2010 04:38, Doug Barton wrote:
Are all the port numbers that have been added recently things that
have been requested by users? IIUC there is a cost "albeit small" for
parsing the /etc/services file each time it's read, so traditionally
we've tried to keep it as small as possible whi
I just tested this patch in -STABLE right now, and it's looking fine so far.
Plugging the eSATA box in triggers:
ada1 at ahcich3 bus 0 scbus3 target 0 lun 0
ada1: ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)
ada1: Command Queueing enabled
ada1: 476940MB
On 04/01/2010 05:27, David Xu wrote:
Log:
Add user-level semaphore synchronous type...
Nice work! Will this be MFC-able to 8.x?
A lot of things could benefit from this, especially Boost.Interprocess.
cheers,
BMS
___
svn-src-all@freebsd.org ma
On 04/01/2010 22:23, Luigi Rizzo wrote:
I also think that the name of the new directory or the exact percentage of
ipv4-ness or netinet-ness of the sctp* and tcp* and multicast* stuff
is irrelevant. Moving directories with svn is so easy that we should not
worry even if we need a couple of attem
On 29/12/2009 15:58, Konstantin Belousov wrote:
Author: kib
Date: Tue Dec 29 15:58:10 2009
New Revision: 201204
URL: http://svn.freebsd.org/changeset/base/201204
Log:
Document _FAST and _PRECISE clocks.
I saw a speed increase with CLOCK_MONOTONIC_FAST vs CLOCK_MONOTONIC
during pmcstat
On 28/12/2009 20:08, Alexander Motin wrote:
Author: mav
Date: Mon Dec 28 20:08:01 2009
New Revision: 201139
URL: http://svn.freebsd.org/changeset/base/201139
Log:
Add BIO_DELETE support to ada(4):
- For SSDs use TRIM feature of DATA SET MANAGEMENT command, as defined by
ACS-2 specificat
On 12/22/09 20:19, Doug Barton wrote:
I know that there is a huge cultural bias towards shipping "a complete
system," and don't get me wrong, I am fully supportive of that. I am
NOT suggesting that we dike out the existing toolchain. Just that we
make it easier to use toolchains from ports.
Alexander Motin wrote:
Log:
MFC r200171, r200182, r200275, r200295, r200359:
Introduce ATA_CAM kernel option, turning ata(4) controller drivers into
cam(4) interface modules. When enabled, this option deprecates all ata(4)
peripheral drivers (ad, acd, ...) and interfaces and allows cam(4)
Nice fix.
Timing problems are the subtlest.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Robert Watson wrote:
For sysctls, explicit versioning doesn't help too much -- what I've
been pondering for another structure was including spares and having a
capabilities field in the structure where flags are set when fields
are known by the kernel. That way userspace can tell if the kernel
George V. Neville-Neil wrote:
Author: gnn
Date: Thu Sep 3 21:10:57 2009
New Revision: 196797
URL: http://svn.freebsd.org/changeset/base/196797
Log:
Add ARP statistics to the kernel and netstat.
Thanks very much for this change.
Any chance this struct can get explicitly versioned (i.e. as
Xin LI wrote:
Log:
Add a new rc.d script, static_arp, which enables the administrator to
statically bind IPv4 <-> MAC address at boot time.
Thanks for doing this -- users will love this!
___
svn-src-all@freebsd.org mailing list
http://lists.fr
1 - 100 of 141 matches
Mail list logo
