Re: Setting memory allocators for library functions.
* Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote: > > This is not what I am arguing. I gave a simple example of an xmalloc > function which does just print an error and exit. However, I've written > many large applications using this sort of scheme where when allocation > fails, all sorts of cleanup is performed before the process exits > (cleaning up & restoring terminal mode, gracefully closing files / > sockets / etc, syslogging the event, etc). It is hardly ever a simple > exit as soon as allocation fails. Here's exactly what's wrong with your idea: Some internal libc function that _can_ gracefully handle an out of memory return will not be able to do so if your malloc wrappers wrest control out from under them. Honestly, any code is somewhat flawed if it doesn't take extra care not to have sections where an abrupt shutdown can cause a lot of damage or inability to recover on restart. However... Some internal libc functions may attempt an allocation while in the midst of doing something evil to your program such as fiddling with signal masks or timers, if you get your "out of memory" callback and the libc function hasn't had time to restore your normal program context, you're going to have a world of pain to deal with. I can't provide any specific examples of this potentially happening, but I can imagine it being a problem, especially deep within something like the userland thread library or other complex library. If you need to deal with asprintf problems, then make an xasprinf that does the callback in your context, not from deep within libc. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Compaq e500, 3com cardbus card help
In message <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: : On Thu, Feb 22, 2001 at 10:32:13AM -0500, Justin McKnight wrote: : > I cant figure out to get freebsd 4.2 to recognize : > and enable my 3com cardbus card? : : FreeBSD currently doesn't support cardbus cards. FreeBSD -stable doesn't support cardbus cards. -current should recognize the 3com cards with the NEWCARD kernels. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
Alfred Perlstein wrote: > > * Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote: > > > > This is not what I am arguing. I gave a simple example of an xmalloc > > function which does just print an error and exit. However, I've written > > many large applications using this sort of scheme where when allocation > > fails, all sorts of cleanup is performed before the process exits > > (cleaning up & restoring terminal mode, gracefully closing files / > > sockets / etc, syslogging the event, etc). It is hardly ever a simple > > exit as soon as allocation fails. > > Here's exactly what's wrong with your idea: > > Some internal libc function that _can_ gracefully handle an out > of memory return will not be able to do so if your malloc wrappers > wrest control out from under them. > > Honestly, any code is somewhat flawed if it doesn't take extra care > not to have sections where an abrupt shutdown can cause a lot of > damage or inability to recover on restart. However... > > Some internal libc functions may attempt an allocation while in the > midst of doing something evil to your program such as fiddling with > signal masks or timers, if you get your "out of memory" callback > and the libc function hasn't had time to restore your normal program > context, you're going to have a world of pain to deal with. > > I can't provide any specific examples of this potentially happening, > but I can imagine it being a problem, especially deep within something > like the userland thread library or other complex library. > > If you need to deal with asprintf problems, then make an xasprinf > that does the callback in your context, not from deep within libc. I agree. Some instances of malloc failure can be / must be dealt with gracefully in libc. I am not saying that ALL usages of malloc would be replaced with calling the user-settable allocator. Only those that are not modifying, as you mentioned, the process' signal disposition and other such attributes, and *certainly* not from within the thread library. Anyway, doesnt seem like this idea is about to fly. I guess I'll shut up now. :-) -Farooq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
* Farooq Mela <[EMAIL PROTECTED]> [010223 00:22] wrote:
> Alfred Perlstein wrote:
> >
> > * Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote:
> > >
> > > This is not what I am arguing. I gave a simple example of an xmalloc
> > > function which does just print an error and exit. However, I've written
> > > many large applications using this sort of scheme where when allocation
> > > fails, all sorts of cleanup is performed before the process exits
> > > (cleaning up & restoring terminal mode, gracefully closing files /
> > > sockets / etc, syslogging the event, etc). It is hardly ever a simple
> > > exit as soon as allocation fails.
> >
> > Here's exactly what's wrong with your idea:
> >
> > Some internal libc function that _can_ gracefully handle an out
> > of memory return will not be able to do so if your malloc wrappers
> > wrest control out from under them.
> >
> > Honestly, any code is somewhat flawed if it doesn't take extra care
> > not to have sections where an abrupt shutdown can cause a lot of
> > damage or inability to recover on restart. However...
> >
> > Some internal libc functions may attempt an allocation while in the
> > midst of doing something evil to your program such as fiddling with
> > signal masks or timers, if you get your "out of memory" callback
> > and the libc function hasn't had time to restore your normal program
> > context, you're going to have a world of pain to deal with.
> >
> > I can't provide any specific examples of this potentially happening,
> > but I can imagine it being a problem, especially deep within something
> > like the userland thread library or other complex library.
> >
> > If you need to deal with asprintf problems, then make an xasprinf
> > that does the callback in your context, not from deep within libc.
>
> I agree. Some instances of malloc failure can be / must be dealt with
> gracefully in libc. I am not saying that ALL usages of malloc would be
> replaced with calling the user-settable allocator. Only those that are
> not modifying, as you mentioned, the process' signal disposition and
> other such attributes, and *certainly* not from within the thread
> library.
>
> Anyway, doesnt seem like this idea is about to fly. I guess I'll shut up
> now. :-)
Well, while looking at actually doing what you're saying, phk malloc
will call a function (from the manpage):
void
(*_malloc_message)(char *p1, char *p2, char *p3, char *p4)
you can set _malloc_message = your callback.
the only problem is that the failure codes don't seem to be
enumerated, they seem to be strings, if there was a way to test:
/*
* this is untested
*/
void (*saved_malloc_callback)(char *p1, char *p2, char *p3, char *p4);
void
my_malloc_callback(char *p1, char *p2, char *p3, char *p4)
{
if (p1 == malloc_out_of_memory_str) {
/* do out of memory handling */
} else {
saved_malloc_callback(p1, p2, p3, p4);
}
}
int
main (void) {
saved_malloc_callback = _malloc_message;
_malloc_message = my_malloc_callback;
more_main();
}
or something, you could then hijack _malloc_message for your
callback.
Of course this would be highly FreeBSD specific, but so would the
modification you wanted in the first place.
Poul-Henning, is there any way to do a valid test to determine that
the '_malloc_message' callback parameter means "out of memory"?
I'm pretty sure that we should discourage anyone wanting to abuse
the interface by doing this, but it does seem sort of interesting.
:)
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Windows 2000 pro & FreeBSD
On Fri, Feb 23, 2001 at 01:40:47AM -0500, Justin McKnight wrote: > To: FreeBSD-newbies <[EMAIL PROTECTED]> ^^^ ^^^ Something is wrong with this picture. Kris PGP signature
Re: Setting memory allocators for library functions.
Farooq Mela <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Usually when I write programs, I have functions such as the following:
>
> void *
> xmalloc(size_t size)
> {
>
> }
>
> void *
> xrealloc(void *ptr, size_t size)
> {
>
> }
>
> And then I use these instead of malloc and realloc throughout the
> program, and never have to worry about return values. Sometimes these
> functions also have additional cleanup they perform. Anyway, there are
> certain libc functions which also use malloc, such as getaddrinfo,
> vasprintf, etc. These may fail with errno = ENOMEM. In general, it is
> annoying to have to check the return values for these functions too.
> Would it not be convenient to set the memory allocator used by certain
> functions inside libc? I.E, be able to write:
>
> set_allocator(xmalloc);
> set_reallocator(xrealloc);
>
> >From then on, one would never have to worry about the functions running
> out of memory. I know that wrappers for functions which allocate memory
> can also be written, but I feel that my proposal would is in general a
> more convenient solution.
>
> How do you guys feel about this?
>
> -Farooq
This would have probably been an outstanding idea when the
C standard was being put together... (and, who knows, somethine
similar may very well have been proposed.)
But, let me point out that adding such a feature to the FreeBSD
library doesn't mean you can dispense with your checks and/or
wrapping functions. As soon as your code needs to run on another
platform, you'll need those checks...
Such is the way of the world - when you have a standard, that's
all you can expect from other systems...
- Dave Rivers -
--
[EMAIL PROTECTED] Work: (919) 676-0847
Get your mainframe (370) `C' compiler at http://www.dignus.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Wake on Lan
> > Can somebody clue me in on how Wake On Lan is supposed to work? > Does it require any support at all from the OS, or is it totally a > BIOS thing? I don't know how "Wake On Lan" is supposed to work, but the "Sony Vaio Slimtop" I have comes out of suspend mode when I ping it. I've had it idle for half an hour so I don't know of any other events that wake it up. You'd have to be sure nothing was going to talk to it and you'd need an ARP entry for once the arp cache timed out to use this in any way. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Windows 2000 pro & FreeBSD
Check out BootPart: http://www.winimage.com/bootpart.htm I used it to copy the boot sector of my FreeBSD partition and add it to the NT boot manager menu. It does all the work for you. Justin McKnight wrote: > i need help dual booting win200 and freebsd4.2. Win200 is > already installed casue i wanted to use its bootmanager for > loading each OS. I know win2k and load openbsd so figure > i wont have any trouble dual booting with freebsd. > Now I cant find any documentation on dual booting win2k > and freebsd. I need help! -- Paul Marquis [EMAIL PROTECTED] I believe five out of four people have trouble with fractions. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wake on Lan
Peter Dufault writes:
> >
> > Can somebody clue me in on how Wake On Lan is supposed to work?
> > Does it require any support at all from the OS, or is it totally a
> > BIOS thing?
>
> I don't know how "Wake On Lan" is supposed to work, but the "Sony Vaio
> Slimtop" I have comes out of suspend mode when I ping it. I've had
> it idle for half an hour so I don't know of any other events that
> wake it up.
>
> You'd have to be sure nothing was going to talk to it and you'd need
> an ARP entry for once the arp cache timed out to use this in any way.
It sounds like your Sony is doing something rather non-standard, and
which is not what I'm talking about. I'm talking about the AMD "magic
packet" protocol which sends a packet that looks like this (to wake up
a machine with MAC 01:23:45:67:89:ab):
09:25:36.230235 1234567.89:ab:01:23:45:67.89ab > .ff:ff:01:23:45:67.89ab:
ipx-#89ab 65505
0123 4567
89ab 0123 4567 89ab 0123 4567 89ab 0123
4567 89ab 0123 4567 89ab 0123 4567 89ab
0123 4567 89ab 0123 4567 89ab 0123 4567
89ab 0123 4567 89ab 0123 4567 89ab 0123
4567
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb and debugging Linux binaries
On Thursday, 22 February 2001 at 13:55:07 -0800, Jim Pirzyk wrote: > > I have a question on how to debug Linux binaries. I have a core > file from the linux binary, but if I use the FreeBSD gdb, it cannot > find the shared libraries in /compat/linux/ If I use the /compat/linux/ > /usr/bin/gdb, it says the core file is in the wrong format: > > Couldn't fetch registers from core file: File in wrong format > Couldn't fetch register set 2 from core file: File in wrong format > > So what is the correct procedure for debugging Linux binaries? Have you tried the Linux gdb? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
On Thu, 22 Feb 2001, mouss wrote: > At 18:37 22/02/01 +0200, diman wrote: > > >Open AF_UNIX socket to syslogd and then use err_set_file() > >to redirect all err/warn messages to syslogd instead of > >stdin/stdout. That should help you debug daemons. > > I agree, but one of the nice things about syslog interface is that it hides > all the socket/device stuff. so getting back to the socket api is > somewhat unsatisfactory. Yes, it's a bit dirty workaround. But openlog() returns void. Returning pointer to a structure from wich I can obtain file descriptor has more sense for several reasons. It would be nice to be able get current LogFile, LogTag, LogStat and LogFacility from openlog(). > > Also, I think having this directly in err() and warn() and friends would be > more elegant. and this doesn't seem hard to do. something like using > a function pointer to use fprintf or syslog, and an additionnal void* to use > either err_file or syslog priority. > > Does this sound ok or is it an unuseful complication of code? I see a sense in your words. Linking a daemon with a libs wich will break control connection by diagnostic messages is not a dream. Having that messages on the console and in the log file is helpful under debug time. There are some points: 1. If daemon want syslog, it should use syslog(). 2. If daemon want warn and exit, it should use warnx. 3. If it doesn't want stderr, it should use err_set_file. *4. If daemon doesn't want libc talking to remote end and breaking a control connection or daemon doesn't want remote end to know about internal fault, it should be able to redirect libc output. *5. Daemon feels good to syslog above libc messages *6. To do 5 it would be nice to have ERR_TO_SYSLOG reserved integer for the err_set_file(void* vfp). So, err_set_file ( ERR_TO_SYSLOG ) ; will say libc to use LogFile and current syslog context to write all err/warn messages instead of stderr. *7. Approach described above doesn't break any current app/daemons and nothing have to be rewritten because ERR_TO_SYSLOG is 0xfffa (for example). Approach is trivial to implement. 8. Not linked well to the speach but openlog() should not return void but pointer to the struct with LogFile, LogTag, LogStat and LogFacility fields. That is my view of the subject. Best Regards, diman. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IOmega ZIP problem
On Fri, 23 Feb 2001, Peter Pentchev wrote: > On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > > | the "cp" process eats 98% of the system resources. What's behind all this? > > | Is there a way to fix it? > > | > > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > > | > > | A 'renice' won't help. > > > > > > That's natural with "parallel". No way around it. > > To clarify a bit, parallel port hardware depends on the system processor > doing all the data transfers, every single byte, and spending even more > time checking if it's time for the next byte to go. There's no DMA, there's > not even a controller you can tell 'here's a 512-byte block, let it fly'. > > There's no way around it indeed. > > G'luck, > Peter So there doesn't exists any controllers (ISA/PCI) that can do the serialization of parallel data, and pass it to a serial interface (or UART), so we can use DMA and move Serial Data Units instead of single bytes? (Probably a feather-brained question..) Cheers, Torbjorn Kristoffersen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IOmega ZIP problem
Torbjorn Kristoffersen wrote: > > On Fri, 23 Feb 2001, Peter Pentchev wrote: > > > On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > > > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > > > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > > > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > > > | the "cp" process eats 98% of the system resources. What's behind all this? > > > | Is there a way to fix it? > > > | > > > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > > > | > > > | A 'renice' won't help. > > > > > > > > > That's natural with "parallel". No way around it. > > > > To clarify a bit, parallel port hardware depends on the system processor > > doing all the data transfers, every single byte, and spending even more > > time checking if it's time for the next byte to go. There's no DMA, there's > > not even a controller you can tell 'here's a 512-byte block, let it fly'. > > > > There's no way around it indeed. > > > > G'luck, > > Peter > > So there doesn't exists any controllers (ISA/PCI) that can do the > serialization of parallel data, and pass it to a serial interface (or > UART), so we can use DMA and move Serial Data Units instead of > single bytes? Not that I'm aware of, although someone could build one fairly easily. Of course if you are going to go to all the trouble to build a specialty card, you might as well just go out and buy a zip drive with a interface. Granted zip drives tend to only use the most minimal subset of whatever protocol they're speaking (ATAPI-floppy device and SCSI-I), but they do work, and are reasonably fast (for zip drives). -- _ __ ___ ___ __ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- [EMAIL PROTECTED] / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/\_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wake on Lan
To follow up on myself, it seems to work on older Asus P2B-LS motherboards (onboard fxp). But only after you shutdown FreeBSD via 'shutdown -p now'. I don't suppose anybody knows which machines support this well? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: portability sanity check
On Wed, Feb 21, 2001 at 05:28:31PM +0100, Poul-Henning Kamp wrote: > >Type-safety is a cruch for the weak-minded. ^ > As an old assembler programmer I couldn't agree more, but in a project > like FreeBSD we have to realize that not everybody is that. Heh, I was just cleaning out these message from my inbox, and I discovered that spell-checkers are a crutch for the weak-minded, too :-) Thanks for everyone's feedback. I decided that I'm quite happy to use type-punning for more-or-less primitive types when building comparison functions and the like. For more complex stuff, it seems simplest/clearest to use a `void *' for internal data, a la db. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Memory Alloation from kernel loadable driver
I have a pci driver which is loaded using kldload. It is allocating a no. of pages by calling vm_page_alloc_contig. This convention is used by other pci drivers, though not necessarily loadable ones. On machines without much memory, or ones with more memory but having done compilations prior to kldloading, contigmalloc1 gets stuck in a continuous loop looping from the first "goto again1." There is a comment above configmalloc1 which might imply that this contiguous allocation does not work after initialization. For locked-down memory, what allocation routines should loadable drivers be calling? Is there any source of documentation of memory allocation which could be of value? Thanks. Sue Wainer [EMAIL PROTECTED]
Re: gdb and debugging Linux binaries
Greg Lehey wrote: > > On Thursday, 22 February 2001 at 13:55:07 -0800, Jim Pirzyk wrote: > > > > I have a question on how to debug Linux binaries. I have a core > > file from the linux binary, but if I use the FreeBSD gdb, it cannot > > find the shared libraries in /compat/linux/ If I use the /compat/linux/ > > /usr/bin/gdb, it says the core file is in the wrong format: > > > > Couldn't fetch registers from core file: File in wrong format > > Couldn't fetch register set 2 from core file: File in wrong format > > > > So what is the correct procedure for debugging Linux binaries? > > Have you tried the Linux gdb? IIRC, the Linux gdb doesn't grok our core files. I started an implementation for our Linuxulator to dump Linux compatible core files so that you could use the Linux gdb. I guess I lost what I had back then. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Wake on Lan
> > > To follow up on myself, it seems to work on older Asus P2B-LS > motherboards (onboard fxp). But only after you shutdown FreeBSD via > 'shutdown -p now'. I don't suppose anybody knows which machines > support this well? The machine *should* support WOL from a cold power-on. However, I do get the impression that some adapters require some parting initialisation as well. You might want to check that eg. you've enabled it in the BIOS and plugged the cable in the right place. Apart from that, I can't really offer any help. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb and debugging Linux binaries
You may be able to force gdb to pick up the right files using the add-symbol-file command. Or the sharedlibrary command. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IOmega ZIP problem
On Fri, Feb 23, 2001 at 09:39:43AM +0200, Peter Pentchev wrote: > On Thu, Feb 22, 2001 at 01:19:33PM -0600, Michael C . Wu wrote: > > On Thu, Feb 22, 2001 at 07:40:16PM +0100, Torbjorn Kristoffersen scribbled: > > | Hi I'm using 4.2-RELEASE, with a parallel port ZIP drive (100M). > > | Whenever I copy a large file from the zip drive (for example /dev/da0s1), > > | the "cp" process eats 98% of the system resources. What's behind all this? > > | Is there a way to fix it? > > | > > | 711 root 54 0 280K 168K RUN 0:45 93.87% 93.21% cp > > | > > | A 'renice' won't help. > > > > > > That's natural with "parallel". No way around it. > > To clarify a bit, parallel port hardware depends on the system processor > doing all the data transfers, every single byte, and spending even more > time checking if it's time for the next byte to go. There's no DMA, there's > not even a controller you can tell 'here's a 512-byte block, let it fly'. > > There's no way around it indeed. AFAIK, ZIP drives support parallel ports in EPP mode (uncertain about ECP), which is much faster than conventional (either nibble or bidirectional) modes. According to imm(4), FreeBSD supports EPP mode for ZIP drives. You might want to check if you can enable EPP in your BIOS. Regards, -- Rafael Rodrigues Obelheiro [EMAIL PROTECTED] Florianopolis, SC, Brasil To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating BSD bootable CD
Murray Stokely wrote: > > On Thu, 22 Feb 2001, Julian Stacey [EMAIL PROTECTED] wrote: > % I hadn't heard of mkhybrid, so investigated: it's been merged into mkisofs: > > I still prefer old versions of mkhybrid over the new merged mkisofs > for some tricky environments. The new mkisofs will coredump with very > large hybrid discs for HFS / Joliet / RR. For making FreeBSD discs > however, mkisofs will do just fine. I think that the corruptions in the filesystems created by mkisofs were caused by the "exclude directories" option. That was the sole reason why I switched to mkhybrid. Last time I used it about a year ago. Maybe they have fixed it by now. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
dummynet as modules
Hi there, How do I compile a a kernel without ipfw, and a ipfw.ko module with dummynet support? I have to add some features to the dummynet code, so instead of rebooting every 5 mins I figured kldloading it would save me some time. I tried several combinations like 'options DUMMYNET' but no 'options IPFIREWALL', even defined DUMMYNET in the modules/ipfw/Makefile but it all resulted in undefined symbols when either building or kldloading... Any ideas? Michael Solan -- New to FreeBSD and less confused than a hamster on FreeBase -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dummynet as modules
> How do I compile a a kernel without ipfw, and a ipfw.ko module with > dummynet support? not sure how well is this supported -- i guess you should look at the makefile for the ipfw module to make sure it includes dummynet. But: > I have to add some features to the dummynet code, so instead of > rebooting every 5 mins I figured kldloading it would save me some time. yes it can be convenient, but if you are testing, chances are that you will be making mistakes which can result in crashes or leaks etc, so a separate test box (or a vmware system) will be convenient anyways... cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb and debugging Linux binaries
On 22-Feb-01 Greg Lehey wrote: > > /compat/linux/ > > /usr/bin/gdb, it says the core file is in the wrong format: > > > > Couldn't fetch registers from core file: File in wrong format > > Couldn't fetch register set 2 from core file: File in wrong format > > > > So what is the correct procedure for debugging Linux binaries? > > Have you tried the Linux gdb? He said he did. The problem is the binary is in linux format but the coredump is in FreeBSD format.. You can still attach to processes etc though I think. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: detecting a closing socket from a Lex/Yacc interpreter ?
Jordan DeLong wrote: > > I'm assuming right now you are just setting yyin to the fd for the socket. > What you're gonna want to do is define the macro YY_INPUT (see the man page for > details) so that it calls recv on your socket. and then if it errors you can > have YY_INPUT return as an EOF and your <> rule will work fine. > indeed, taking the very simple YY_INPUT code from the man page of lex did the trick (+ remembering to close the fd's associated to the socket ...) Thanks -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
