Date: Wed, 20 Feb 2002 01:50:39 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: "George V. Neville-Neil" <gnn@neville-neil.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel Debugging over the Ethernet? Message-ID: <20020220015039.A37037@iguana.icir.org> In-Reply-To: <3C736F92.12435B7D@mindspring.com> References: <200202200536.VAA258019@meer.meer.net> <3C736F92.12435B7D@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
The idea was basically what you sketch at the end: implement a very simple protocol which does the encapsulation (IP+UDP probably) and retransmissions etc by itself. This is meant to be run on a dedicated interface so we can neglect security issues. I think there is a standard API for "console" devices, something like CONS_DRIVER or the like. We were just trying to figure out what the API is and what it is supposed to do. cheers luigi On Wed, Feb 20, 2002 at 01:42:42AM -0800, Terry Lambert wrote: > "George V. Neville-Neil" wrote: > > Now that Luigi has put in polling support for some ethernet drivers > > I was wondering how much work it would be to make the remote kernel debugging > > run over the ethernet. I have worked on systems like this before (it's the > > reason > > I did polling network device drivers in Wind River's VxWorks) but it depends > > on a debugging system that has the ability to have its back end swapped out. > > > > Who would I talk to about how kernel debugging works at the > > lowest layers right now? Which source files should I look at first. > > You would need to also have J. Lemon's patch to get rid of NETISR, > or your TCP/IP stack will never run. Even so, his patch does not > run everything to completion (i.e. it is not the same as LRP), it > only runs it up so far, and then stops. > > You would also need to do the transmit processing manually, which, > even if you had implemented LRP, or used the LRP with the bad > license, still requires seperate processing. > > If you were to use raw ethernet datagrams, and do the retransmit > and encapsulation yourself, rather than relying on TCP for retransmit > or IP for encapsulation, then you might be able to do this (see xnet > in /etc/protocols). > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020220015039.A37037>