The value of network debugging to me is not that I can
avoid buying a serial cable (big deal), it's that I can
do the debugging remotely.
Agreed.
If I'm going to ssh into a local machine and debug from
there, then I can use a serial cable.
The serial cable solution does not scale too well
On Mon, 25 Feb 2002, Bakul Shah wrote:
The value of network debugging to me is not that I can
avoid buying a serial cable (big deal), it's that I can
do the debugging remotely.
Agreed.
If I'm going to ssh into a local machine and debug from
there, then I can use a serial cable.
IP is so you can make it through a cisco, etc. to another
routable segment.
Oh I know that; but the cost of that convenience seems high.
For us, with a lab full of test machines (used for simulating
and testing various IP network clouds) a non-IP solution was
preferable.
But I can see
Without TCP, you have to implement your own version of
retry and ack (equivalent to negotiating a window size
of 1), and so you have to redo what's already there.
Would be nice to have a reliable channel but in our
experience not having this was not a big deal. The gdb
serial protocol is
On Sat, 23 Feb 2002, Bakul Shah wrote:
Without TCP, you have to implement your own version of
retry and ack (equivalent to negotiating a window size
of 1), and so you have to redo what's already there.
Would be nice to have a reliable channel but in our
experience not having this was
Julian Elischer wrote:
The other issue with TCP is that you can set up specific
flows in the company firewall, and also permit SSLeay
based tunnel encapsulation from outside via an intermediate
machine. This isn't really required for off-site debugging,
but it gives another
1) Easy to write a very minimal, outside the stack, IP/UDP layer.
One (very nasty) already exists in libstand. There was a very small
TCP/IP stack mentioned on /. the other day; it looked close to ideal for
this application.
--
To announce that there must be no criticism of the president,
Justin C.Walker writes:
On Wednesday, February 20, 2002, at 04:52 PM, Julian Elischer wrote:
yes but we might as well be protocol compatible if possible :-)
If only to re-use what they did in gdb :-)
The Darwin/Mac OS X scheme only deals with IOKit because that's where
the
This is cool.
As people talk about this it seems that more and more of the needed parts
are already available from one source or another..
On Thu, 21 Feb 2002, Michael Smith wrote:
1) Easy to write a very minimal, outside the stack, IP/UDP layer.
One (very nasty) already exists in
Julian Elischer wrote:
On Thu, 21 Feb 2002, Michael Smith wrote:
There was a very small TCP/IP stack mentioned on /. the other day; it
looked close to ideal for this application.
though I think it is probably better to use a UDP transport rther than
TCP it would be worth checking it out
Terry Lambert [EMAIL PROTECTED] wrote:
Julian Elischer wrote:
On Thu, 21 Feb 2002, Michael Smith wrote:
There was a very small TCP/IP stack mentioned on /. the other day; it
looked close to ideal for this application.
though I think it is probably better to use a UDP transport rther
Ok, so now George has so many choices to choose from
that I'm expecting 3 different implementations from him, with no common
components :-)
On Thu, 21 Feb 2002, Benedikt Schmidt wrote:
Terry Lambert [EMAIL PROTECTED] wrote:
Julian Elischer wrote:
On Thu, 21 Feb 2002, Michael Smith wrote:
Benedikt Schmidt wrote:
Look at http://slashdot.org/article.pl?sid=02/01/29/2115210mode=thread.
The TCP/IP stack mentioned in this article can be found at
http://dunkels.com/adam/uip/ and is licensed under the 4-clause BSD
license.
Thank you.
-- Terry
To Unsubscribe: send mail to [EMAIL
The Apple darwin site is:
http://www.opensource.apple.com
I've not looked through the source for this, so you may have to inquire
on the darwin-development mailing list for pointers into the source
repository.
Regards,
Justin
On Thursday, February 21, 2002, at 07:48 AM, Andrew Gallatin
Ok, so now George has so many choices to choose from
that I'm expecting 3 different implementations from him, with no common
components :-)
That's my exact plan, how did you know?
Actually this has all been pretty helpful, and I'll be considering the
options and playing as soon as I get that
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
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
On Tue, 19 Feb 2002, Julian Elischer wrote:
Hi George.
There was someone recently that posted that they had some sort of
remote debuging working over an ethernet (or at least that they ALMOST
had it working.). I remember thinking Cool. I have however had good
success with the
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
Folks,
Thanks for all the helpful hints. Depending on what I find when I look
at how DDB/GDB work now I will probably do the following:
A) Use UDP/IP as the transport.
Reasons:
1) Easy to write a very minimal, outside the stack, IP/UDP layer.
2) Allows debugging through routers,
On Wed, 20 Feb 2002, Bakul Shah wrote:
I may have forgotten a few things but this is the gist of how
it worked. Credit for all this work goes to someone else.
We had meant to give this back to the FreeBSD community but
didn't get around to it in time and now it is not possible.
Why
We had meant to give this back to the FreeBSD community but
didn't get around to it in time and now it is not possible.
Why not? (curiosity, not disbelief)
The company got sold before we could sort all this out and a
bunch of the original people no longer work there. Actually
anything is
Forgot to add: this is a pretty straight forward thing to do
and anyone can hack it together in a few days especially when
you have a functional spec of a sort!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
On Tuesday, 19 February 2002 at 21:36:25 -0800, George V. Neville-Neil wrote:
Hi Folks,
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
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I suppose
you'd like to take a look at it.
That depends on where they put it. If it depends on I/OKit then we
won't be able to use it easily I figure.
Thanks for
yes but we might as well be protocol compatible if possible :-)
If only to re-use what they did in gdb :-)
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote:
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I suppose
you'd like to take a look at
you mean they use the same protocol?
On Thu, 21 Feb 2002, Greg Lehey wrote:
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote:
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently
On Wednesday, 20 February 2002 at 17:03:38 -0800, Julian Elischer wrote:
On Thu, 21 Feb 2002, Greg Lehey wrote:
On Wednesday, 20 February 2002 at 16:52:48 -0800, Julian Elischer wrote:
On Wed, 20 Feb 2002, George V. Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the
On Wednesday, February 20, 2002, at 04:14 PM, George V.
Neville-Neil wrote:
I was talking to Louis Gerbarg about this topic at the BSDCon last
week. Apparently Darwin already has this functionality, so I suppose
you'd like to take a look at it.
That depends on where they put it. If it
On Wednesday, February 20, 2002, at 04:52 PM, Julian Elischer wrote:
yes but we might as well be protocol compatible if possible :-)
If only to re-use what they did in gdb :-)
The Darwin/Mac OS X scheme only deals with IOKit because that's where
the drivers live. The protocol
This all look great. I've got a Darwin 1.4 CD at home, I'll check it
out tonight or some time this week.
Later,
George
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Hi Folks,
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
Folks,
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
Hi George.
There was someone recently that posted that they had some sort of
remote debuging working over an ethernet (or at least that they ALMOST
had it working.). I remember thinking Cool. I have however had good
success with the serial crossover cables needed for the curren serial
On Tue, 19 Feb 2002, Julian Elischer wrote:
Hi George.
There was someone recently that posted that they had some sort of
remote debuging working over an ethernet (or at least that they ALMOST
had it working.). I remember thinking Cool. I have however had good
success with the serial
36 matches
Mail list logo
