From owner-freebsd-arch@FreeBSD.ORG Mon Oct 29 23:30:15 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4B816A417 for ; Mon, 29 Oct 2007 23:30:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD7E13C48E for ; Mon, 29 Oct 2007 23:30:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1506869rvb for ; Mon, 29 Oct 2007 16:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=NCKCbzsju5rZsbk60mUEFMqf07xpF19ZmOfIKOZGN3k=; b=gUXizJm8bKBoXBkJpqr8jRm/9D0sKXfZ8sCNvmF5VWOA3AggN5ZGuBr3BERLbnsefVEuLUIk5RQPMpI8pZkYDxPzgn7VaQ2Iq+aAqxDV993m1DV2cCGjhPOgHLm6TYT+PID05oUjPaOfM2JN6J3GskJvWHriXS8wDX5cfNGAbnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dW74YJYPnF0dJeF0E9YhkAF8jXi3p3Mo/YnTPR35tcy1oh4IfMco8NxO/Kwl7XrRcu5XeN24JpSsiq9EWC2j8G0Tb7W6LNcmQAFf/BuAhYI7dCKG9j2rbt3W/qPOulVXa6bWU3Y/bzs8ySkg3rb/5p+GGO10f0sC6ZR9vtTAxyU= Received: by 10.141.154.5 with SMTP id g5mr3062188rvo.1193698845129; Mon, 29 Oct 2007 16:00:45 -0700 (PDT) Received: by 10.141.194.16 with HTTP; Mon, 29 Oct 2007 16:00:45 -0700 (PDT) Message-ID: <9bbcef730710291600w607e46d8x8c893aa4e53b597d@mail.gmail.com> Date: Tue, 30 Oct 2007 00:00:45 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Poul-Henning Kamp" In-Reply-To: <33676.1193689342@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <33676.1193689342@critter.freebsd.dk> X-Google-Sender-Auth: 37672dd831a37668 Cc: freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2007 23:30:15 -0000 On 29/10/2007, Poul-Henning Kamp wrote: > For instance, the entire "dual-address space" dictomy og system > calls/copy{in,out} and the very concept of interrupts are very > tricky to sensibly express in anything but C. I don't see those example as something special or different - they are just "there" to implement with or around. Copyin/out can be implemented as-is, literally in C, or it can be abstracted (and C++ isn't a good candidate for this, AFAIK it lacks proper "properties" - members that cause function invocations in the form of getters/setters - see Object Pascal, C#, Python, etc.). On the lowest level, interrupts are just function invocations triggered externally, by hardware. Any language that can give you a pointer to a function can handle those. There is no reason not to implement the kernel in e.g. Pascal (if would even give us some of the features you want: string and array bounds checking) though C might be more efficient because it's closer to the metal. > So what I've been tinkering with, is not a new language, but a > C dialect enhanced to make kernel programming simpler. That's my point: another nonstandard dialect of C, no matter how useful, will only alienate new people from joining the project. A subset of C++ will not. >an option to check all function pointers for > non-null-ness before jumping through them. At compile time or at runtime? :) At compile time it's practically impossible in C, at runtime, the only thing you could reasonably do is panic, which doesn't gain you anything... I'd rather go for some kind of transparent debugging infrastructure (even if it means patches to the compiler), like malloc debuggers in userland or garbage collectors, which keep the language pretty much intact and standard. These are just my opinions, I haven't designed any OSes lately :)