From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16368 invoked by alias); 23 Mar 2017 18:08:56 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 16347 invoked by uid 89); 23 Mar 2017 18:08:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=HX-HELO:sk:mail-wm, H*p:D*net, manageable, H*Ad:D*pl X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Mar 2017 18:08:54 +0000 Received: by mail-wm0-f48.google.com with SMTP id n11so3148591wma.0 for ; Thu, 23 Mar 2017 11:08:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RKcKE4mBE81szzU/qr8u9QZAEZZbOcWXvVmsrXe+uiQ=; b=mLkyJIY3VnLX9tU9hINWDmGwnxtTaIqiny/z+eEJ6cmfKZtCetrzc+yUV68EyB3T/6 O2GrqiXu8HM3HJ/utZ12y86k4tvFHTogB/xi7ryaXsGa5JdPkyNY3RVAbI3dl2ovJDJW Caj4p5QwUf2wh2k7/3dYd9gA3G1rGvatY0DFXUP0kO5Yj0F3uQo6Zia55tnVZZWuQBQ+ a2PEAgAyp4XBFIHZEYcAjDtnoSUn7Q6jxrt9FTNVj/V5j3ZTj4Tf4Hjz3vSpDlyjkKOZ Wd5A0+e7BwvNlP9wV0GfvosIegHR8zkmbo9tXGV5LWXu5uRmF4KVmJPKcBajLAKE3Od1 zZ9g== X-Gm-Message-State: AFeK/H1OpAA7e6dryb9M1Jy8SEQiaO/3FgycHrCd9i32YhchmsYH8JjODFbrn4u0XJqjWA== X-Received: by 10.28.109.147 with SMTP id b19mr9607804wmi.69.1490292533809; Thu, 23 Mar 2017 11:08:53 -0700 (PDT) Received: from [172.16.62.12] ([109.99.239.84]) by smtp.gmail.com with ESMTPSA id x127sm5341085wmf.31.2017.03.23.11.08.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Mar 2017 11:08:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: [OpenOCD-devel] Python API for supplying thread information? From: Liviu Ionescu In-Reply-To: <1490287804.1231.7.camel@op.pl> Date: Thu, 23 Mar 2017 18:08:00 -0000 Cc: Pierre-Marie de Rodat , gdb@sourceware.org, openocd-devel Content-Transfer-Encoding: quoted-printable Message-Id: References: <1490175792.1242.7.camel@op.pl> <8FB0BA0B-F013-48A6-965B-AEF4B69610EC@livius.net> <6b759808-b486-64c1-6624-c622cad8a46e@adacore.com> <1490205142.1410.5.camel@op.pl> <1490287804.1231.7.camel@op.pl> To: Freddie Chopin X-SW-Source: 2017-03/txt/msg00053.txt.bz2 > On 23 Mar 2017, at 18:50, Freddie Chopin wrote: >=20 > ... However me and Liviu had a discussion about describing RTOS structure > in a generic way and I'm still pretty certain that this is generally > not possible in a generic and agnostic way. In the end it would become > either extremely complex or you'd have to implement some kind of > scripting/code to actually deal with that. as I already mentioned, my next version of the DRTM library will use a comp= iled binary JSON, so everything that can be described in a JSON will be per= fectly acceptable. are JSONs generic enough? I would say they are. will I make the DRTM library 'absolutely generic and agnostic' from the ver= y beginning? definitely not realistic, I'll first define the data types and= memory structures that I need for my =C2=B5OS++. will this be expandable with more memory types? definitely yes! at the end,= the number of ways a list of threads is kept may be large, at the limit ea= ch RTOS may invent a different scheme, but the number is still finite. ;-) my assumption is that relatively low and manageable, so it should be easier= to add a new definition to an existing framework that is already fully fun= ctional, than to redo an implementation completely from scratch. and once y= ou do it, the result should be directly available to all servers that use t= he DRTM library (OpenOCD, J-Link, QEMU being on my TODO list). regards, Liviu