>> 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
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 se
> 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
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
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
> 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 f
> 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 th
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 w
Benedikt Schmidt wrote:
> Look at http://slashdot.org/article.pl?sid=02/01/29/2115210&mode=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 [EMAI
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
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 t
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
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 l
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
> 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,
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
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 implementati
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.
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
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.
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
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
> 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
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
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
> > 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
anythi
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.
Wh
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, a
using tcp for this is I think wrong..
Use UDP or maybe even an special protocol on IP.
On Wed, 20 Feb 2002, 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 ma
> 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
> > succe
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" d
"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 netwo
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 se
> 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 ser
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
debugger
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 Rive
36 matches
Mail list logo
