On Jul 11, 2013, at 2:05 PM, Artem Belevich <a...@freebsd.org> wrote:
> It would probably work for most of the crashes, but will not work in few > interesting classes of failure. Using in-kernel stack implicitly assumes > that your memory allocator still works as both the stack and the interface > driver will need to get their mbufs and other data somewhere. Alas it's > those unusual cases that are hardest to debug and where you really do want > debugger or coredump to work. This is all true, though I think Julian was also suggesting that this "fall-back vimage" would be somehow preallocated, perhaps not from the kernel allocator pool, ahead of time. The mbufs needed for it a "connection time" would also presumably come from a special pool, though I don't know how much conditional logic in the existing stack would be necessary to make sure it didn't try to allocate any data from the generic allocator. It might indeed be easier to simply bake-in a much simpler, UDP-only stack and polled device driver combo. - Jordan _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
