From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <archer-return-2099-listarch-archer=sourceware.org@sourceware.org>
Received: (qmail 28469 invoked by alias); 3 Aug 2010 13:55:06 -0000
Mailing-List: contact archer-help@sourceware.org; run by ezmlm
Sender: <archer@sourceware.org>
Precedence: bulk
List-Post: <mailto:archer@sourceware.org>
List-Help: <mailto:archer-help@sourceware.org>
List-Subscribe: <mailto:archer-subscribe@sourceware.org>
List-Id: <archer.sourceware.org>
Received: (qmail 28455 invoked by uid 22791); 3 Aug 2010 13:55:05 -0000
X-SWARE-Spam-Status: No, hits=-5.9 required=5.0
	tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_KN,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Date: Tue, 03 Aug 2010 13:55:00 -0000
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, Roland McGrath <roland@redhat.com>,
        utrace-devel@redhat.com, archer@sourceware.org
Subject: Re: gdbstub initial code, another approach
Message-ID: <20100803135451.GA30848@host1.dyn.jankratochvil.net>
References: <20100721204203.D040C400B6@magilla.sf.frob.com>
 <20100723173134.GA29717@redhat.com>
 <20100726142759.GA17171@redhat.com>
 <20100728181702.GA26678@redhat.com>
 <y0m8w4uhsuc.fsf@fche.csb>
 <20100730125755.GA6438@redhat.com>
 <20100730132537.GA15448@host1.dyn.jankratochvil.net>
 <20100730144124.GA10396@redhat.com>
 <20100730152025.GA22951@host1.dyn.jankratochvil.net>
 <20100802125122.GA2267@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100802125122.GA2267@redhat.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
X-SW-Source: 2010-q3/txt/msg00082.txt.bz2

On Mon, 02 Aug 2010 14:51:22 +0200, Oleg Nesterov wrote:
> Yes, as I said I personally do not believe in in-kernel gdbstub too much.
> If nothing else, I bet it will be never merged upstream. Unless at least
> this code will also have the more "traditional" user-space API which is
> immediately clear to the reviewers on lkml.

I find knfsd is a precedent, isn't it?  It contains some compatibility-kludges
(such as the SUNRPC layer used only for nfs) and still the filesystem
operations are AFAIK fully kernel-side.

NFS is a well-established protocol such as the gdbserver one and both need
high performance of their server-side execution.


> Or remote debugging via tcp. We need the user-space helper anyway.

There is rpc.nfsd as the userland wrapper, I do not find a problem if such
program would exist for ugdb.


> Or two modes, all-stop and non-stop. Imho, the kernel shouldn't even
> know about this. Or register renumbering.

The NFS protocol also isn't perfect.


Thanks,
Jan