for offload setup.
Others:
Mbuf initialization is unified through m_init() and m_pkthdr_init() to avoid
duplication. m_free_fast() is removed for lack of usage.
Patch is available here:
http://people.freebsd.org/~andre/mbuf-adjustments-20130821.diff
This work is sponsored by the FreeBSD Foundation
On 8/21/13 9:40 PM, Andre Oppermann wrote:
[ actual text removed.. ]
Patch is available here:
http://people.freebsd.org/~andre/mbuf-adjustments-20130821.diff
one small thing I noticed..
- u16 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR);
+ u64 type
Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime):
Hi,
I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
the way so there is not much of a resemblance left.
The driver is in good
I am working on linux epoll functionality for linuxlator. It implements
epoll through kqueue, but there is the need to overload fo_close
function in fileops to free some memory.
There is no generic mechanism defined in the kernel sources allowing to
do this, and it isn't desirable to do this
Hi,
While packaging my just-rebuilt ports today, I noticed a strange message
occurring during the package creation stage:
$ sudo make -C /usr/ports/ports-mgmt/pkg repackage
=== Building package for pkg-1.1.4_1
Creating package for pkg-1.1.4_1
Service unavailable$
In fact, *every* make
On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
On Mon, 19 Aug 2013, Adrian Chadd wrote:
Yes! Please file a PR!
This sorta implies that both are acceptable (although,
the Linux behavior seems more desirable).
http://austingroupbugs.net/view.php?id=369
No, that says
Please check in this patch:
http://www.freebsd.org/cgi/query-pr.cgi?pr=181459
Thank you,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Yuri wrote this message on Wed, Aug 21, 2013 at 11:37 -0700:
I am working on linux epoll functionality for linuxlator. It implements
epoll through kqueue, but there is the need to overload fo_close
function in fileops to free some memory.
How did this memory get allocated in the first place?
On 08/21/2013 16:21, John-Mark Gurney wrote:
How did this memory get allocated in the first place? Why does it need
to be free'd in fo_close and not another location?
It is allocated by the epoll module right after kqueue object is created
and is attached to the opaque field in the file
On Wed, Aug 21, 2013 at 04:53:06PM -0700, Yuri wrote:
On 08/21/2013 16:21, John-Mark Gurney wrote:
How did this memory get allocated in the first place? Why does it need
to be free'd in fo_close and not another location?
It is allocated by the epoll module right after kqueue object is
On 08/21/2013 17:10, Mateusz Guzik wrote:
Short answer is provide epollops with your own fo_close and the rest as
it is currently in kqueueops. All function are static, but this is not a
real problem since you have to modify kern_event.c anyway.
This is exactly what this code I am asking about
On Wed, Aug 21, 2013 at 05:30:05PM -0700, Yuri wrote:
On 08/21/2013 17:10, Mateusz Guzik wrote:
Short answer is provide epollops with your own fo_close and the rest as
it is currently in kqueueops. All function are static, but this is not a
real problem since you have to modify kern_event.c
I don't think there is a need to provide anything like this right now,
nor I have any good idea how to implement it.
This kinda leave it hanging in the same state.
To do this kqueue fileops need to be exposed. It is always possible to
create something like struct fileops* kqueue_fileops()
I've noticed that if you do a:
make buildworld WITHOUT_CLANG_IS_CC=YES
and then do a:
make buildkernel
(w/o the WITHOUT_CLANG_IS_CC=YES option)
that it fails... Apparently instead of letting buildkernel figure out
which compiler it will use, the src/Makefile.inc1 forces COMPILER_TYPE
to be what
14 matches
Mail list logo
