Jacques Fourie wrote: > I was wondering what the amount of effort involved would be to add > support for dumping on a remote machine via tftp, for example. This > would be extremely handy for devices with little or no hard disk space. > > Does anyone know of anything with this functionality?
This has been discussed several times in the past. The main issue is that the kernel is not stable enough to run the network stack and an interrupt driven network driver while it's dying (perhaps because of an error in the network stack and/or the network driver and/or the interrupt processing and/or the VM system and/or ... a ton of other places that would be involved in a remote dump. The closest anyone has come to this (to my knowledge) is the creation of a polled network driver and a tiny UDP stack to permit remote debugging over the network to a different machine on the same switch. This isn't very close to dumping. Normally, this type of thing is handled in firmware that gets called by the hardware reset vector, FWIW, which means you get a dump image of the system memory, and the OS is not really involved at all (in a clean shutdown it sets a bit in CMOS that's cleared on boot to ensure that a dump does *not* happen). If you are considering adding this functionality, then you should probably consider all the code that would be in the dump path, and figure out how you could run it without a kernel running. This will probably mean that any patches you do will be very specific to your network card, etc.. If you get to the point where you need a very small network stack, and you can't find the one in the FreeBSD -hackers list archive, let me know, and I'll try to dig up a reference for you (there was one posted about last year that fit in about 19K). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
