> Just wondered if anyone could help me out here, Im trying to
> cvsup from
> 4.0-RELEASE to 4.1-STABLE and on a make depend on my kernel I get the
> following:
>
> ===> agp
> make: don't know how to make agp_if.c. Stop
> *** Error code 2
>
> Anyone else getting this error on a build?
Yup. I
Panic over, #include solved that. You learn something new every day.
No pun intended.
Apologies for offtopicness. 50 lines of "I will look on deja next time".
Dave :)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Possibly off topic, but here goes.
I'm trying to use placement new with gcc 2.95.2 on FBSD4.0-Release and can't
get it to go with an error:
:11: too many arguments to function `void * operator new(unsigned
int)'
Disclaimer: I've never tried to use placement new before, but I've RTFM'd
fairly he
> We're trying to create a high availability FreeBSD
> cluster with a standby machine being able to take over for a
> failed host
I'm about to be in a similar situation and was planning a gratuitous ARP. It
seems a lot easier than attempting to take over the MAC adddress. Any
comments?
Dave
> Don't some of the Gigabit FreeBSD drivers actually utilize
> the on-board
> checksum processing???
H, can't see anything specific Looking at if_wx.c we have a function
wx_start(ifp) where ifp is an ifnet pointer. ifnet has a member if_snd, of
type ifqueue (according to the man page). A
Apparently (http://developer.intel.com/design/network/82559.htm) the i82559
can offload TCP and UDP checksums. A quick peruse of
/usr/src/sys/pci/if_fxp.c shows we are not currently using this - which is
fair enough since the driver also has to work with 82557 and 82558.
It strikes me that due t
> I've run C++ code in the kernel. You couldn't easily use: templates,
> exceptions, global ctors, and sometimes you had to be careful with
> automatic instantiation of things.
Nothing too smart, OK. I tend to write fairly agricultural code anyway.
> I implemented only new and delete
> and was
I'm writing some C++ code that currently uses divert sockets off the
firewall and for performance reasons moving the code kernel mode is looking
like a (long term) good idea.
The question is: Should I bite the bullet and start writing in pure C now
(and therefore save pain later)? Can I just prov
> > Just learning about this: I can see the advantages but does
> anything use it?
>
> Sure, TCP uses it.
>
> TCP (at least in FreeBSD) sets the "don't frag" bit on all
> its outgoing
> packets.
Good lord, so it does. Mental note, packet sniff before posting in future.
So... thinking about
Just learning about this: I can see the advantages but does anything use it?
Dave :)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Julian,
Many thanks!
> If you reinsert the packet and use the same sockaddr that
> you received,
> it should insert the packet at the first rule number GREATER THAN the
> rule that diverted it. The rule number of diversion is stored in
> the 'port' field of the sockaddr.
Loud clang noise as
I'm having a go at writing a 'component' in the firewall chain. The
component may, or may not, readdress the packet and therefore I need to drop
it back into the chain at the next rule.
Should be simple.
So I've written some test code just to scoop up packets and drop them back
in unaltered usin
I'm trying to write a simple static NAT, and have got a bit stuck with the
new checksum in the IP header thing with me is that I'm not happy about
something till I understand it (and it appears that the IP stack is well
behaved and won't send something unless the IP checksum is right either).
13 matches
Mail list logo
